Gertius

TK, you really rescued us! The strangest of bugs are gone with your suggestion, and now we can press on to get rid of the other, more obvious bugs :) Thanks!!!!!!!!!!!!!!!!!! Thanks again to the others who tried to help as well! Best regards, Christian

Hi Ilmenator, thanks for your quick answer! We had already found this code example in the assembler page in the wiki though, and we were still not able to figure it out together with the stack... Any other suggestions, anyone? Best regards, Christian

Hi, fellow MIDIboxers! We are building a relatively complex MIDIbox as a university project, programming it in C, and the due date is nearing very quickly (next monday). I have posted about the project two or three times already, and we will have a detailed wiki explaining everything very soon. Now that our code size has grown and grown (we already migrated to PIC18F4620) we encountered another strange problem yesterday, that we hope to find some help for here. The problem is that function parameters (data type "long" and others) are not transfered correctly into the functions since some days, which leads to very strange behaviour. It means that for example an address for a memory access function is correct before that function is called, but is corrupt inside the function, directly after the call (no calculations done yet in the function). We found out by reading out the values over MIDI before and after the function call. Now we assume that our stack might get an overflow by using too many local variables. Is that probable? How big is the stack exactly? We read about 31 items in the PIC18F4620 datasheet, could that be? How could we read out the stack pointer variable (STKPTR) through inline assembler code to determine if there was an overflow? We would really appreciate some lines of assembler code and how they could be inserted into our C code, as we have no idea of programming assembler. Thanks in advance, Christian

Hi George, we will create a page in the wiki for our app in about a week, when the project is done. It is a university project, and it will be called Midi Box GLCD, cause it has two cores where each drives one GLCD in vertical mode. Basically it will be a programmable controller that can display parameter names beside the knob you are tweaking and is designed specially for controlling synthesizers (although it is suitable for every other app as well). It has a special menu structure for accessing 16 devices and 1024 parameters for each device. Also it should read out the edit buffer of the synths, tweak it and send it back again to change the sound program, so it will have extended sysex capabilities. But we are having an "easy life" programming in C, and I have great respect of anyone trying to tame that Midi beast with assembler, so good luck with your app as well ;) Well, still a lot of debugging to be done in that following week, so I better get back to work :) Best regards, Christian

Hi George, thanks again for your long instructions! It was really helpful, nice and compact as it was! I spent half a day copying/pasting lines into the c skeleton and I really managed to get the midi out led working nicely! I was amazed :-) Anyhow, even after hours of trying, the midi in led still had a strange behaviour as it somehow interferes with our other shift registers, that we set in C (kinda complicated to explain fully), and was on all the time. I tried thousands of variants, but still no luck... so we decided in our project group that it is not worth the extra tryout time, ripped apart some old midi equipment (midisplitter of some sort) for the 74HC00 of the LTC Module and just build that anyway . Works fine now :) Anyhow, thanks again and good luck! Christian

Thanks for your answer, George! It already made it clear what number to use for the LEDs! It just occured to me, that I wasn´t exact enough in my first post, though, so let me specify my problem a little further: we are writing a relatively complex project from scratch, but we are actually writing in C, using the C skeleton. The hooks for the USER_MIDI_NotifyRx/Tx in the mios_wrapper.asm accept Assembler code only, though. The problem is that many of the files used in assembler apps (like MB64) are missing in the C skeleton, so I don´t even know, where to copy the appropriate lines to. As an example, in the file midi_rxtx.inc, some registers have to be located to app_defines.h, which doesn´t exist in the C skeleton. Also, the lines you posted are (understandably) nowhere to be found in the C skeleton. Should this question rather go into C programming then? Best regards, Christian

Hi everyone! Could someone please help me with setting up MIDI Monitor LEDs over DOUT Modules? I have found the USER_MIDI_NotifyRx and Tx functions, but I am completely lost with programming Assembler. I have also searched the source codes of the SID and LTC apps to copy something from there, but the code doesn´t make sense to me at all, so I cannot simply copy/paste it. Also, I don´t have time to build a LTC Module, as my project is a universtity project and due in one week :-\ Well if anyone could post some code for me, and tell me where to insert it I would be very very grateful! The MIDI Leds are connected to Pin 0 (OUT) and Pin 16 (IN) of the DOUT Module, and should flicker, when MIDI transfer is taking place. Thanks in advance, Best regards, Christian

Ok, thanks again Thorsten. And congratulations to your 5555th post ;D

Hi Thorsten, I will document both solutions in the Wiki then. However I didn´t completely understand the last paragraph you wrote... The thing you would change, does it refer to our or to your solution? And how could the base address be ex-/imported? Is it done in the project.lkr file? Would you have a code example? Oh, and by the way, are the font_big and icons_knobs fonts already part of the MIOS? I remember we always had trouble using those in C. Best Regards, Christian

Hi Thorsten! Thanks for your reply! We actually found another solution in the last 5 minutes, which I was just typing up here. What do you think of this: The linker script in project.lkr had to be modified. In the wiki it was described like this: But what really had to be done was to create another additional page and modify the first one, so you´d have these two lines: CODEPAGE NAME=page0 START=0x3000 END=0x7BFF CODEPAGE NAME=page1 START=0x8000 END=0xFFFF This is to leave out exactly the space in the PIC, where MIOS is written to (the GLCD Font I guess). Which one would be the more recommendable solution? Can anyone change that in the wiki? Can/should we do it? Best Regards, Christian

Hello audiocommander, thank you for your quick reply! Just to clarify again: we use two cores that communicate over MIDI and each is connected to one of the GLCDs. Maybe something was missed indeed in the wiki page, good to know that GLCDs are not that common, and might have been missed... -> good hint, we will look into that -> we checked the wirings, they are working correctly. The displays actually do work fine (even with PIC18F4620), as long as the code size doesn´t exceed 0x7BFF. This is true both for ucapps example apps as well as our own app. -> we took the original, precompiled MIOS v1.9c for PIC18F4620 (and the corresponding Bootloader as well) -> we have already set the conversion flag -mem_64k. It did not work at all before. If there are any other ideas or suggestions, we would be very grateful... Best Regards, Christian

Hi everyone! Our university project is nearing it´s completion, which is good, as our given time runs out in two weeks ;D We are building a MIDI Controller based on MIOS with two cores and two 240x64 Pixel GLCDs that show parameter names and values. The box is being programmed with a Java software for 16 devices with up to 1024 parameters per device. More about this in a User-Wiki, in two or three weeks, after we´ve finished... Our big problem: we have migrated to a PIC18F4620 (including the IIC workaround) two days ago as our code size exceeds the limits of the PIC18f452 by far. We have made all the adjustments from the PIC18F4620 Wiki (http://www.midibox.org/dokuwiki/doku.php?id=using_pic18f4620), and we are using the special 18F4620 versions of MIOS 1.9c and the bootstrap loader. The chip´s got the ID 0 and the display type in the header is set to 7. Now we get a strange error, that the display only shows scrambled stuff. Our guess is that our code size overwrites the GLCD font from MIOS, as it does not happen when we strip our code to fit into the 0x7BFF range (everything works fine again!). Also we noticed that during upload of the MIOS, it is writing MIDI data to the space of 0x7C00-... (or similar), space that should now be reserved for our code, no??? Is our code only overwriting the GLCD font (we could include it "custom-made" in our code again) or is any other part of the MIOS also overwritten? Do we need to make other adjustments to the MIOS files for it to work correctly? Sorry if I was missing something in the forums, but we searched them and the websites for half a day yesterday, and we cannot afford to lose much more time.... Best regards, Christian

Doh, finally I found out what was going wrong. In my main program I used counting variables which were "int" and "char", and added them in various locations to my "long" variables to determine the adress. But: that way the small 2 bytes of the "long" adress variable changed, but not the third one in which the bankstick was stored, even when it should. Changed everything to "long" and now it works perfectly. Just thought I´d let you know. I´m a programming noob, and now I see why calculating with different data types can give you strange results :) Greetings, Gertius

Hi Thorsten, thanks for the fast response, maybe that is also the answer for some other problems, I was having. I think I will go back to smaller data types, and see if those work better for me. Sorry for choosing the wrong forum by the way, makes sense to put that into C programming... Have a good night, Gertius

Hi everyone! Did anybody already gather experiences with the "long" datatype while programming the PIC18F452 in C? I wanted to realize a function for continous adressation of the bankstick, which would automatically switch the chip on an 8-chip board. The "long" variable mem_adress would store the bankchip in nibble 5 (counting from the right), triggering the "MIOS_Bankstick_CtrlSet" Function, and the adress (for the "MIOS_Bankstick_Write" Function) in nibbles 1-4. But somehow it doesn´t seem to work! The nibble in which the chip is stored is always 0, I get the value through "mem_adress>>16". Here's the code if you're interested: void writeBank(unsigned long mem_adress,unsigned char value) { if (mem_adress >= 0x80000) return; if (bankchip != mem_adress >> 16) // select BankChip MIOS_BANKSTICK_CtrlSet(bankchip=mem_adress>>16); MIOS_BANKSTICK_Write(mem_adress%0x10000, value); } I searched the forums, but didn't fing anything on this subject, so I just wanted to know if it's generally a bad idea to use "long" variables with MIOS in C and the PIC18F425... Greetings, Gertius