ilmenator

Agreed. :) I will change the name tag in the Wiki as soon as I find the time. Or is there anybody else who cares to do this? Best regards, ilmenator

Alex, you might also want to look at this thread: http://www.midibox.org/forum/index.php?topic=7724.0 Of course, it does not help with your Novation issue, but might help in deciding to drop that thing ;D. Best regards, ilmenator

Maybe the rest is not used in your application? Best regards, ilmenator

Hi stryd, it is 2k when J5 is connected to the core and the SRAM card is inserted. It is 28k when J5 is not connected and the card inserted. I was thinking of maybe I have a "ground loop" problem or something like that, as I am using both the J5 and the J15 connectors from the core, both carrying +5V and ground. BUT in fact J15 only delivers to the LCD connected also to J15. Both 74HCT573 are supplied via J5. So I would suppose that if I disconnect J5 completely, then the +5V pin of that IC (pin 20) should have a potential of 0V, that means ground level - but indeed I measure 3.6V without the SRAM card inserted, possibly coming from where??? If I insert the SRAM card, that voltage drops to 3.0V, which is the backup battery voltage - if I remove the battery, strangely enough I still measure 1.35V. It's a real mess, and it's hard to come up with a drawing of the circuit, because I wonder how much of that battery backup circuit of the SRAM card is relevant here - and how that might look like. :-\ Yet, I was wondering why it works flawlessly using a DIN input pin then?? I will try to dig deeper (and hopefully to make more sense to all of you readers out there ;D). Thanks, ilmenator

Hi all, I have an application which uses an external SRAM card as memory extension. It is based on the schematic from TL - see this post: http://www.midibox.org/forum/index.php?topic=4140.msg27685#msg27685. For the CARD PRESENT status of the card (= is it connected to the core or is the card disconnected) I am currently using one DIN pin. The detection mechanism is very simple: there is one pin on the card connector that is connected to ground by the card whenever it is inserted, and which is connected to +5V via a pullup resistor whenever no card is inserted. This works well and gives me the correct status whenever the status changes, that means whenever I connect or disconnect the memory card. BUT the problem is that I am not interested in the change of the status, but in the status itself: upon powering up the core, I have no means of detecting whether the card is connected or not, because the DIN mechanism is checking for transitions. Now, I am trying to use pin A7 of J5 (that is RE2 of the core 18F452) in the same manner: I have a pullup of 100k against +5V, and whenever the card is inserted, the pin is drawn to ground. To my knowledge, the C code necessary to initialize the input of Port E is very simple: ///////////////////////////////////////////////////////////////////////////// // This function is called after startup to initialize the SRAM ///////////////////////////////////////////////////////////////////////////// void SRAM_Init(void) __wparam { // disable the ADC which allocates the analog pins // only needed if controls pins are connected to port A ADCON1 = 0x07; ... // configure RE2 as input for reading SRAM card status // Pin RE.2 = input TRISEbits.TRISE2 = 1; return; } Then I only have to check the status of that pin regularly, e.g. in [tt]Tick(void)[/tt], using something like: app_flags_t.SRAM_CARD_STATUS = PORTEbits.RE2; which could be defined the same way as the DISPLAY_UPDATE_REQ flag in the sdcc_skeleton demo code. So why did I put this into "Troubleshooting" and not "Programming in C"? Well, it does not work this way, and I tried to meter the potential of the RE2 pin using a multimeter. In fact, that pin is always at ground level, no matter if the card is connecting the pin to ground or not! So... is the pullup resistor too large (100 kOhm)? I also measured the resistance accross the resistor (with the circuit powered off, of course). It reads about only 20 kOhm when the "circuit" is connected to pin RE2. If I disonnect it from there (pulling the J5 plug), then the resistor value reads 100 kOhm as it should be. If I connect the card, then the resistance across the pullup drops further down to about 2 kOhm. J5 disconnected and card inserted gives me 28 kOhm across the 100 kOhm pullup. I am sure there is no short circuit, that is why I really don't get any further here. Any suggestions? Do I need to do something more to the core / the PORTE input? Do I need to change the pullup's resistor value to get to a decent potential at pin RE2? ??? ??? ??? Best regards, ilmenator SRAM_card_workbench.JPG

Pues, tendras que leer un poco más... Aquí pudes encontrar toda la información necesaria para construir los MIDIboxes, y las funciones de ellos ya están en los nombres. MIDIbox SID: un sintetizador basado en el sound chip de un Commodore 64 MIDIbox FM: otro sintetizador basado en FM de Yamaha MIDIbox SEQ: un secuencer para crear tracks MIDIbox 64: un controlador universal para MID; por ejemplo puedes manejar Plugins VST con este box, o cualquier otro equipo de MIDI. Si no sabes de que se trata, tendras que leer aquí. O es un indicador de que no necesitas nada de lo que está descrito en estas páginas ;D Saludos, ilmenator

You might want to look around at ebay a bit more. There are other offers for lots of 6 which are regularly selling cheaper than that. Best regards, ilmenator

I don't care about the name, it was chosen by the students who did this project. Now the project is over, I am left with what they have been programming, and I can do whatever I please with the 'name tag' ;D. So let's call it MIDIbox SynthEdit! Best regards, ilmenator After all, it's just a name :-* (sorry Artesia, just could'nt resist ;D)

Hi mess, your solution works okay, as long as I only want to display the memory content on the LCD at this very moment. void Print_CardName(unsigned char cursor) __wparam { unsigned char j; // counter variable unsigned char card_name_length = 15; card_l_addr = 0x06; MIOS_LCD_CursorSet(cursor); for(j=0; j<card_name_length; j++){ ram_byte = MIOS_BANKSTICK_Read(card_l_addr); card_name[j] = ram_byte; card_l_addr++; MIOS_LCD_PrintChar(ram_byte); } return; } What would I need to do to save it as a string for future use? I seem to be having difficulties with the const declaration required for the PreconfString. As the string will change rather often I am looking for something like the classic string type of C variable... how could I return this from my function? You notice that I have not been programming a lot... Best regards, ilmenator

Hi Alex, you could try the MIDIfilter / processor project to modify the data in such a way that it fits the SID's expectations. ;D Best regards, ilmenator

Thank you both, I will try out your suggestions tonight and keep you informed :). Best regards, ilmenator

Thanks mess, this should work for numbers, but unfortunately those characters to be displayed are stored in ASCII format. From what I understand from the MIOS Functions Reference your suggestion will give me the hex representation of the characters, right? So I guess it comes down to using [tt]MIOS_LCD_PrintPreconfString[/tt], but how do I preconfigure that string by reading the bytes from the Bankstick's memory? Thanks for your input, ilmenator

Hi all, I need to print 15 bytes stored in the Bankstick memory (starting at 0x0006) on the LCD. Unfortunately I do not fully understand which MIOS_LCD_Print... command to use. My idea was to store the bytes read from the Bankstick in an array [tt]unsigned char card_name[15][/tt], but then how can I display the content of that array on screen? The C functions description does not really get me there, because I get all kinds of "...from type...to type..." errors from the compiler. Can somebody help? Thanks, ilmenator

Beware, the seller does not even state whether the unit works or not... But hey stryd, you want me to buy that one for you? --> PM Best regards, ilmenator

Great to hear! In fact, most things in the MIDIbox GLCD itself are fairly well settled, a few minor things could use some improvements - but the overall functionality is there to cope with its primary goal, the editing of synth patches. What is still in a state that needs some overhauling is the JAVA setup program. The main problem with this is that the conglomeration of parameters into one Sysex file for transmission into the MIDIbox GLCD is still kind of buggy. Therefore at the moment it is very difficult to create fully functional devices for the box. The basic structures are there, the concept and the protocol are fully described in the documentation, but some more work needs to be invested. As already said I am in the process of setting up an SVN repository, but my university administrators are a little worried about security issues with their servers. I need a little more time, but when it's done hopefully we can coordinate the work on the editor in some way. Also, I am currently trying to form a new project group dealing with the editor software. Best regards, ilmenator

You might want to look at www.reichelt.de, they have nearly everything you need for building any MIDIbox. Their prices are quite good, the only drawback is that they have a minimum order fee for orders from abroad that is around 150 Euros, I believe. But if you arder all components that you need from them, you might get as high as this anyway. Regards, ilmenator

Where are you located? Getting parts is mainly a question of where you live. Best regards, ilmenator

Thank you thank you thank you !! ;D That's exactly what's going on, mess! Now that I know my code works okay, I will try to make it faster using the block read commands. Thanks also to Audiocommander who reminded me of this. Best regards, ilmenator

Now, I tried to leave out all the SRAM_Read and MIOS_BANKSTICK_Write function calls inside the loop. The result is still the same, after a certain period of time the core resets itself. I can almost definitely tell that it's time dependent, because if I send out MIDI events inside of the FOR loops, then the counter does not get as far as if I just count and display... I tried with this code: for(card_h_addr=0x00; card_h_addr<0x7F; ++card_h_addr){ // inner loop increments the address lowbyte for(card_l_addr=0x00; card_l_addr<0x7F; ++card_l_addr){ MIOS_MIDI_TxBufferPut(0x91); MIOS_MIDI_TxBufferPut(0x00); MIOS_MIDI_TxBufferPut(card_l_addr); } MIOS_MIDI_TxBufferPut(0x92); MIOS_MIDI_TxBufferPut(0x00); MIOS_MIDI_TxBufferPut(card_h_addr); } So, after around 2 seconds or so the problem arises. Does this ring any bells? Any OS things happening periodically every 2 seconds or so? I am not saying that it's an OS thing, I am just trying to find some cause for this strange behavior... :( Can somebody verify this behaviour? Best regards, ilmenator

Okay, I think there is some misunderstanding about the "new line". Actually, the // comments out the whole line following. There is a ; in the middle of these lines, which is the "comment" identifier for asm code. It should not be considered as "end of line" or "new line" by the C compiler, I think? So: //bsf _LATA, SRAM_PIN_LATCH1_LE ; bsf SRAM_LAT_LATCH1_LE, SRAM_PIN_LATCH1_LE actually was assembler code like this: bsf SRAM_LAT_LATCH1_LE, SRAM_PIN_LATCH1_LE It was then changed to asm inline code in my C code like this: bsf _LATA, SRAM_PIN_LATCH1_LE ; bsf SRAM_LAT_LATCH1_LE, SRAM_PIN_LATCH1_LE with everything after the ; being a comment. When used as a comment in my C code it was completely commented out with the two // - at least I think so. If it was not this way, the compiler should report an error, shouldn't it? I will try erasing the whole line to see what gives. Best regards, ilmenator

Ahem, I'm not sure what you are talking about? As far as I can see, although the asm code is twice in there, it is not active and should only serve as documentation. In the asm lines, the first entry was the modified asm code for use as inline asm in C, the second entry after the ";" was the original code. Is there actually any "setting of vars over and over again" that I have overlooked? I would really like to know where so I can improve my skills! :) I will try your suggestions tonight and will report back. Thanks, ilmenator

Thanks Audiocommander, SRAM_Read(); calls this function: void SRAM_Read(void) __wparam { // first latch // Write the low byte of the address of the data you want to read to PORTB // (the whole port, not just a single pin, so you write 8 bits long) //movff SRAM_ADDR_2, _PORTB PORTB = card_l_addr; //bsf _LATA, SRAM_PIN_LATCH1_LE ; bsf SRAM_LAT_LATCH1_LE, SRAM_PIN_LATCH1_LE PORTAbits.RA0 = 1; //bcf _LATA, SRAM_PIN_LATCH1_LE ; bcf SRAM_LAT_LATCH1_LE, SRAM_PIN_LATCH1_LE PORTAbits.RA0 = 0; // second latch // Write the high byte of the address of the data you want to read to PORTB // (the whole port, not just a single pin, so you write 8 bits long) //movff SRAM_ADDR_1, _PORTB PORTB = card_h_addr; //bsf _LATA, SRAM_PIN_LATCH2_LE ; bsf SRAM_LAT_LATCH2_LE, SRAM_PIN_LATCH2_LE PORTAbits.RA1 = 1; //bcf _LATA, SRAM_PIN_LATCH2_LE ; bcf SRAM_LAT_LATCH2_LE, SRAM_PIN_LATCH2_LE PORTAbits.RA1 = 0; // remaining address lines //movff SRAM_ADDR, _PORTE // nothing to do at this moment; maybe later more memory will be addressed // enable port read mode: // set PORTB as input to enable SRAM contents to be written to the port //setf _TRISB TRISB = 0xFF; // Enable chip select (CS1) and Output Enable (OE) pins to read the data from // the ram and put it on the PORTB pins. CS an OE are active LOW, so you clear // them to start the read //bcf _LATA, SRAM_PIN_CS ; bcf SRAM_LAT_CS, SRAM_PIN_CS PORTAbits.RA2 = 0; //bcf _LATA, SRAM_PIN_OE ; bcf SRAM_LAT_OE, SRAM_PIN_OE PORTAbits.RA5 = 0; // wait while lines are low for the sram to put the data on the I/O0 - I/O7 pins // (as per the SRAM datasheet) __asm nop __endasm; // read data // read PORTB (which now has the contents of your SRAM at the address given) // into a variable //movff _PORTB, _MIOS_PARAMETER1 ram_byte = PORTB; // Disable OE (go HIGH) //bsf _LATA, SRAM_PIN_OE ; bsf SRAM_LAT_OE, SRAM_PIN_OE PORTAbits.RA5 = 1; // Disable CS (go HIGH) //bsf _LATA, SRAM_PIN_CS ; bsf SRAM_LAT_CS, SRAM_PIN_CS PORTAbits.RA2 = 1; // disable port read mode //clrf _TRISB TRISB = 0x00; //movf _MIOS_PARAMETER1, W */ return; } This contains all the original assembler source code as comments, it might be a bit confusing. I have tried declaring the variables volatile, but to no avail. They are also declared "extern" in main.h, of course. It should have read: ...will get modified at various places... Up to now, the above piece of code is the only place where they get changed. It is triggered by pressing a button - other button presses might also change the variables, but not at the same time! There is no timer at all in my code, except the DISPLAY_Tick routine which reads the values in order to display them on the LCD. I have not yet looked at the .asm file, but will do so. Thanks for your hints. Could it be that I somehow overwrite parts of my code? The strange thing is that the final counter value (bankstick_addr) varies quite a lot, so I have also situations where I can only transfer about 1400 bytes and then the app resets. Then again it copies around 1700 bytes before resetting. Thanks, ilmenator

Hi all, I am having a problem with a nested FOR loop in C which causes the PIC to reset itself. I am trying to copy the content of an SRAM card (32kB) to a bankstick. If I use only the inner loop for reading/writing 256 bytes, everything is smooth. As soon as I activate the outer loop, the app increases the [tt]bankstick_addr[/tt] counter to around 1736 -1741 (that is 0x06C8 to 0x06CD) and then crashes. The counter varies, but the crash is always there, and the core resets itself. This is my code: // read whole SRAM card and copy to Bankstick else if (pin == 0x14){ // SRAM_Read_Page(); bankstick_addr = 0x0000; MIOS_LCD_PrintCString("Copy Card to Bankstick "); // outer loop increments the address highbyte for(card_h_addr=0x00; card_h_addr<0x7F; ++card_h_addr){ // inner loop increments the address lowbyte for(card_l_addr=0x00; card_l_addr<0xFF; ++card_l_addr){ SRAM_Read(); error |= MIOS_BANKSTICK_Write(bankstick_addr, ram_byte); ++bankstick_addr; if( error ) { // here you could do some error handling MIOS_LCD_CursorSet(0x00); MIOS_LCD_PrintCString("Bankstick write Error "); } // print current address MIOS_LCD_CursorSet(0x19); MIOS_LCD_PrintCString("Address: "); MIOS_LCD_PrintBCD5(bankstick_addr); //app_flags.DISPLAY_UPDATE_REQ = 1; } } [tt]bankstick_addr[/tt] is a counter that determines the address in the bankstick where the byte shall be put; it's of type unsigned int [tt]card_l_addr[/tt] determines the low byte of the 16bit SRAM address; type unsigned char [tt]card_h_addr[/tt] is the high byte of the 16bit SRAM address; also unsigned char All three are global variables because they will get modified at various places. The LCD output is mainly for debugging. Any thoughts on this? Best regards, ilmenator PS: Thanks stryd, you see your explanations about that assembler code actually got me here...

10 pieces 18F452-I/P for 25,- Euros from Ireland. http://cgi.ebay.de/PIC18F452-I-P-x-10-pieces-40-pin-DIL-Package_W0QQitemZ300042793801QQihZ020QQcategoryZ4663QQrdZ1QQssPageNameZWD2VQQcmdZViewItem

Great, now I can burn two PICs at a time ;D Best regards, ilmenator