mess

Hi You could use the sid_random example for generating random signals it does require a small external circuit...

hehe nice one stryd :)

Hi Jackchaos, thank you for the tip, it could come handy sometime :) I always looked at the bottom of the .asm file of the module I was changing, but this only gives you a general code size (of the source file) Michaël

You could use a midibox ltc module for the wiring.. it takes care of all level convertions just replace the rx and tx connections the the pic with the rx and tx from the FT232R...

If I remember correctly there is no real string variable in C since a string is nothing more then a (null terminated) array of chars So if you want to store the string you can just save the array, and to print them afterwards you iterate through the array with PrintChar maybe there's a better solution, but that's how I would do it Michaël

@Stryd I really should work on my ASM skills, I understand what's going on but to write it from scratch :( If you want to give it a try here's the C code: if (app_flags.IDLE) { if (idle_counter==0) { idle_counter = IDLE_TIME; //turn off display MIOS_LCD_Cmd(LCD_OFF); app_flags.LCD_DISABLE = 1; //turn off backlight PORTDbits.RD4 = 0; } //GP counter is incremented every mS if (!MIOS_GPCounterGet()) { idle_counter--; } } else { //only enable if display was disabled if (app_flags.LCD_DISABLE) { //turn on display (with cursor) MIOS_LCD_Cmd(LCD_ON_CURSOR); app_flags.LCD_DISABLE = 0; //turn on backlight PORTDbits.RD4 = 1; } //reload counter, turn IDLE flag back on idle_counter = IDLE_TIME; app_flags.IDLE = 1; } I will PM you the asm output @dcer10 If you upload unmodified firmware to a modified core the lcd will work but the backlight won't... It's just a few lines of code the switch it on if you don't use the standby feature Turning this feature on/off in code at compile-time should be no problem. It could be done in a menu but this would require more effort the modify the CS code I don't know how a software PWM is going to affect performance... I will look into it after we get the standby working without fadeout... Thanks, projects like this one are the perfect distraction when I'm stuck with the seq :-) Michaël

If you look at the code there's a routine called init() this is called after MIOS is running, before program execution in this routine the display is turned on after that the application is started with a counter that increments every millisecond if the counter is not reset before the counter reaches it's max value the display is turned off when a control is moved the display is turned on again and the counter starts again from 0 I've just compiled a new version that can handle such long delay times, you can change the delay time in main.h, there's a constant named IDLE_TIME the delay time is IDLE_TIME * 256mS so it's possible to adjust this for the application I will look into translating the code into assembler this week, it's impossible for me to tell wich applications will work with this. This is my first asm hacking so we will have to see... the standby code works already nicely with my DSEQ32 project ;D

Hi Ilmenator, I didn't know what kind of output you needed so I guessed hex :) for display ascii replace the print hex with this function: void MIOS_LCD_PrintChar(unsigned char c) bye Michaël

Hi, maybe you could use this for displaying the contents: unsigned int index; unsigned char value; //print first 8 numbers MIOS_LCD_CursorSet(0x00); for (index = 0x06; index < 0x06 + 8; index++) { value = MIOS_BANKSTICK_Read(index); MIOS_LCD_PrintHex2(value); } //print the other values on the second line MIOS_LCD_CursorSet(0x40); for (index = 0x06 + 8; index < 0x06 + 15; index++) { value = MIOS_BANKSTICK_Read(index); MIOS_LCD_PrintHex2(value); } it uses no array, but it seems to work all values are printed in hex without any spaces, otherwise it wouldn't fit on the lcd... About those errors, maybe you tried something like this? MIOS_LCD_PrintHex2(card_name); since the functions only accept a single byte, you have to right a little loop to print your array: unsigned char cnt; for(cnt = 0; cnt < 15; cnt++) { MIOS_LCD_PrintHex2(card_name[cnt]); } hope it helps Michaël

Hi AC, could you post the objective-C code? maybe we can get around the limitations somehow It would also illustrate how your system works as I don't get it completely right now ::) Michaël

OK mystery solved, I did remove my bankstick module to test the IIC_midi module and the core just hanged because of some bankstick code in Init() ::) I disabled this code and everything worked fine...

Yup, it works just fine :) make sure to use the latest version, the older one didn't initialise the backlight on startup It would depent on the application: If it's a user C application you could add the lines from the example project and it should work If you want to add this to an existing application like MBSEQ it would be a more difficult the code should be translated in ASM and you should be sure that the code doesn't conflict with the application code (use of J14) I could rewrite this in ASM if necessary, let me know I wouldn't want to modify MIOS myself, because every time a new release comes out, the release should be modified for the backlight code If you really want this you should ask TK... Michaël

would a circular buffer do the job? you could implement this without using pointers, just arrays don't now about the performance difference between using pointers and arrays... Michaël

I think this would be doable in C you could use the clockbox application as an example if you need help with the coding let me know... Michaël

I've made some pictures of the core pcb mod: !!!! make sure that your backlight doesn't light when you disconnect the backlight connections, if the display still works when disconnecting these pins you will have to mod the lcd, I will post more on this later !!!! #1 Cut two traces to isolate the trimpot from Vcc: #2 Bypass the connections to the trimpot #3 Connect the trimpot to J14 of the core (see the core schematic for the pin number I will look into the PWM later :) Michaël

Hi Stryd, thanks for your time, here's my linker script: // linker script for a MIOS project // Thorsten Klose (tk@midibox.org), 2004-07-10 LIBPATH . FILES lib/libsdcc.lib CODEPAGE NAME=vectors START=0x2C00 END=0x2FFF PROTECTED CODEPAGE NAME=page0 START=0x3000 END=0x7BFF CODEPAGE NAME=page1 START=0x8000 END=0xFFFF CODEPAGE NAME=idlocs START=0x200000 END=0x200007 PROTECTED CODEPAGE NAME=config START=0x300000 END=0x30000D PROTECTED CODEPAGE NAME=devid START=0x3FFFFE END=0x3FFFFF PROTECTED CODEPAGE NAME=eedata START=0xF00000 END=0xF000FF PROTECTED DATABANK NAME=miosvars START=0x000 END=0x00f ACCESSBANK NAME=accessram START=0x010 END=0x07F DATABANK NAME=gpr0 START=0x080 END=0x0FF DATABANK NAME=gpr1 START=0x100 END=0x1FF DATABANK NAME=gpr2 START=0x200 END=0x2FF DATABANK NAME=stack START=0x300 END=0x37F PROTECTED DATABANK NAME=miosram_u START=0x380 END=0x5FF PROTECTED //enable the use of the new ram DATABANK NAME=gpr6 START=0x600 END=0x6FF DATABANK NAME=gpr7 START=0x700 END=0x7FF DATABANK NAME=gpr8 START=0x800 END=0x8FF DATABANK NAME=gpr9 START=0x900 END=0x9FF DATABANK NAME=gpr10 START=0xA00 END=0xAFF DATABANK NAME=gpr11 START=0xB00 END=0xBFF DATABANK NAME=gpr12 START=0xC00 END=0xCFF DATABANK NAME=gpr13 START=0xD00 END=0xDFF DATABANK NAME=gpr14 START=0xE00 END=0xEFF DATABANK NAME=gpr15 START=0xF00 END=0xF7F ACCESSBANK NAME=accesssfr START=0xF80 END=0xFFF PROTECTED SECTION NAME=CONFIG ROM=config //main buffer wich contains the active pattern SECTION NAME=BUFFER RAM=gpr6 //edit buffer SECTION NAME=EBUFFER RAM=gpr7

I can see the advantages of implementing this in MIOS: lower overhead, official support... The problem is that it is difficult to provide a generic solution for this... Most pins of the core are allready allocated for the official applications I don't think that TK will reserve a µC pin for this simple feature also it could confuse newbies if their display would turn off without knowing what happened... I will add some pictures of the mod, any suggestions for the documentation are appreciated... Michaël

Hi, I've tried to upload my application to a 18f4620 core All modifications as described on the wiki page were executed When I upload my code with MIOS studio v7.4 all goes well (code from 0x3000->0x6EFF) but after upload MIOS reboots and hangs while displaying: the only way to get rid off this is to upload MIOS v1.9 again... the previous version of my code works OK (code from 0x3000->0x6BFF) this version was not modified for 18f4620 any clues? Michaël

Hi, I tried out this mod today and it works :-) There was a problem with the switching because the backlight got it's power from the lcd power supply After I removed the resistors on the lcd everything worked OK I also fixed a small software bug, the backlight wasn't switched on at startup the new version is available here: http://webs.hogent.be/~032573mh/lcd_standby061102.zip Maybe we should make a seperate board for this so that no traces need to be cut on the core pcb (like I did ::)) Michaël

as always, really nice design artesia, I wish that I had your graphical skills for my CS design :D a core with the v2 SID firmware will be able to control 2 SIDs from one core module see http://www.ucapps.de/midibox_sid_v2_wishlist.html Michaël

yay, discrete logic survival!!! ;D I would like to see the wiring mess at the other side :)

Hi Ilmenator, I think the watchdog timer is causing this behaviour, if the code inside tick() takes to long the watchdogtimer will not be cleared so the core resets itself quote from TK from another topic: if it's not possible to speed up your code you can clear the watchdog timer yourself: __asm clrwdt __endasm;

Small code update: after 10 seconds the display is disabled and the backlight turns off (J14 goes low): lcd_standby Since both displays are connected to the same backlightterminal no additional changes should be required for two displays... I will document the modifications to the core as soon as I can verify them Michaël *edit: link didn't work

Maybe we could switch of the backlight by the transistor on the core board: if we replace this: (sorry for crappy ascii schem, see core schematic) [tt] ^ +5v ^ + 5v | | -------| | + | | | |BL | > 10K | _ | < | -------| __ | \ | | \ | |------\/\/\-----\/\/\---- v | _\_ | 1K 10K _|_ [tt] with this: [/tt] ^ +5v | -------| + | | | BL | > 10K - | < -------| __ \ | | \ |------\/\/\-----\/\/\----- J14 of core v | _\_ | 1K 10K _|_ [/tt] not shure if this will work... I will try this tomorrow when I have access to my midibox I never used two displays for a midibox project, how are they connected?

What about porting to the dsPICs? (I think there was a thread about this in the past) seems like an interesting port if you use the dsp features :-) also it's a 16 bit architecture so maybe it could give some extra performance... the alternative could be a pic18f4620 for control surface and a dsPIC for the signal stuff