Thomas

Hi audiocommander! I do not...and I will not (that why I asked for a better place in the other thread, this will be buffered in future). AIN_NotifyChange() ->element_handlePoti() -> MIOS_MIDI_BeginStream(); -> MIOS_MIDI_TxBufferPut(0xbe); -> MIOS_MIDI_TxBufferPut(pin); -> MIOS_MIDI_TxBufferPut(value7bit); -> MIOS_MIDI_EndStream(); -> display_printElement() ->MIOS_LCD_CursorSet(0x00); ->MIOS_LCD_PrintCString("Fad "); ->MIOS_LCD_PrintBCD2(number); ->MIOS_LCD_PrintChar('/'); ->MIOS_LCD_PrintHex1(MIOS_MIDI_DeviceIDGet());

P.S: (@Thorsten) No other MIDI-event is send during upload.

Hallo Thorsten and Audiocommander! I have a zip-file on my homepage http://www.krachwerk.de/mb_thiele_c_20060524.zip I normally hate it to publish unfinished, partly bad or experimental style code that is really written from brain to editor and therefor historically grown... ;) I know there are a lot of uneffective or bad parts. But there should be no error...(but it is *grrr*) (Before you ask: no - the programm itself does not write to flash, the parts are comment out and are never called. Although they are there for experimental reasons. After these experiments the PIC was reprogrammed and loaded with new MIOS.)

Hi Thorsten! I'lll send you an email later, but a first question in public - maybe someone else has the same problem sometimes: How can a progamming error cause remaining problems during upload? I would unstand that a programm crashes during runtime. (what quick'n'dirty c(++) programm never crashed with a lovely "segmentation fault" at first trial?) I thought MIOS was destroyed because the copyright message was not printed correctly. Maybe it's earlier in the application than I thought, so that this message is overwritten by application garbage very soon, too fast to notice. I noticed that (it's getting very slowly when this happens, as well when it received a lot of messages sended by an open AIN-pin). But this would not explain the destroyed MIOS. Even when MIOS Studio should send garbage, MIOS' (secondary) bootloader wouldn't flash it, would it? I'm not completely sure but I think the problem was also when I used MidiOX for application upload. (btw. I found the errorcode in the meantime in the MIOS-sources)

Hi Thorsten! But I did! Always when I load my new software I got no checksum after block in the 3000-range. Not always 3B00-3BFF, sometimes 3F00 or 5xxx. MIOS upload and upload of examples work. That's why I doubt it's a MIDI-problem. I have newer a problem with uploading MIOS, except that once it was so corrupted that I had to re-burn the bootloader. I forgot to mention that I go the error string <sysex header> <device id> 0E 0B 00 7F. But you only decripted error messages up to 0A... After uploading my software MIOS is corrupted an sends only initial requeststrings. Display shows not "READY." but something like #######öp####### ################ I have some ideas at the moment: 1. wrong version of C-wrapper? (Can this be? They only differ in the upper code range in linker script I think) 2. bug in c-warpper(?) or SDCC(?) 2. bug in C-wrapper (I doubt it, I do not believe you publish wrong untestet code) 3. bug in SDCC or linker (possible, but then I have to debug it to a much lower level) 4. damaged PIC (but this would be the third, on two completely different boards) Can a PIC be destroyed by slight overvoltage (e.g. 6V)? But why does it work with other software then? 5. an error in my software. For me the most likely variant. But if so it's hard to find. Today I will go back to really simple versions of software, just to check the hardware. And verify that other software _really_ works. And then step by step add new functions and variables. Can I send you the hex-file that courses corruption? Just to verify if it is actually the hexfile and not a general problem on my side (e.g. overvoltage, MIDI-IO of soundcard, Win98-problem) Greetings Thomas

Forget what I wrote: even with the "normal" MIOS version, MIOS seems to be corrupted after uploading block 3B00-3BFF of my own software via sysex. (no "received checksum" any more)

Hi! Seems I have to step in every trap that can happen...murphy rules... Ok...I noticed that my board is wrong. The mux-lines for AIN-multiplexer are interchangend. A, B, C ist normally connected to pins RC0, RC1, RC3 On my board RC2, RC1, RC0. Don't know how this could happend. Maybe are writing error. :( No problem I thought and changed the ain EQU in the mios-sources, not more. (mios 1.9) BUT: the resulting hex-file differs from the original one (mios_update1.9/pic18f452/midi/mios_v1_9_pic18f452.hex) in five lines. (not only in two bytes as I expected). And after I loaded my software, mios stops working and sends the initial request sysex-string every 2s. I changed nothing in the C-wrapper file. Except that I added my own software files. Nor wrote I explicitely into RAM or flash. I only use global and local C-Variables and arrays. No dynamic memory allocation or write-operations via pointer. During compiling of MIOS (with MPLAP v7.31) I get the warning "operand of HIGH high operator was larger than H'FFFF'". (line 67 of macros.h) Any ideas what happed? Any ideas where to start debugging?

Thanks Thorsten, that's exactly what I wanted to know.

Hallo! I think you mean MIDI-Controller Messages. As internal (masked stream with f9,fe) stream this would be ok. But CC have only 3bytes. With some kind fo encoding this could would work. But I think I will use the timer function to trigger the "remote printing".

-verbose Don't understand what you mean.

Hallo! I need some input for the software design for a MidiBox-Chain. The first MB is for Motorfader(and menu-buttons) the second are for any other pots and display. When a fader is moved the first MB should send a message "fader X/1 moved" or something like that. Or other not time critical messages, debug messages. Don't know what will t be in the future. No problem until now, this works. BUT: those message are relatively long sysex-Strings. So they should not be sended at every call of AIN_NotifyChange. My idea was to buffer such messages and send them if there is "less traffic on the line"... Whats the best place to send those messages? Display_Tick()? Timer()? Tick()? Or somewhere else?

Thanks. It works now. :)

Hallo Thorsten! That's my code in main.c: void DISPLAY_Init(void) __wparam { display_init(); MIOS_LCD_CursorSet(0x80); MIOS_LCD_PrintCString("hallo!"); MIOS_LCD_CursorSet(0xc0); MIOS_LCD_PrintCString("Thomas!"); } Where display_init() only calls MIOS_LCD_YAddressSet: /** initializes the display */ void display_init(){ MIOS_LCD_YAddressSet(0x00, 0x40, 0x80, 0xc0); } The second display is initialized but stays blank. What's wrong? Are the offsets ok?

Hi! As audiocommander said, it's better to use groups of <=256 arrays. On reason is that only a char (8-bit) is used instead of an 16bit int what would require at least the doubled number of assembler commands. (-> see the resulting *.asm file after compiling) Ways to access a database defined like mentioned above: 1.) Use the absolute address: unsigned char * ptr = 0x300; ptr[0] = 0x08; ptr[1] = 0x15; ... 2.) Use symbolic name, but I havn't tried this: (from Vangelis) Another way to define a symbol at a specific databank would be to use the 'udata' pragma. The usage would be: #pragma udata array_name gpr345_section This would 'array_name' at gpr345_section DATABANK (which would that be...) But then you would have to add one more line in the .lkr script file: SECTION NAME=gpr345_section RAM=gpr345

The problem is I haven't. But let us assume that I did. What would the following code produce? Will there be output on the second LCD? unsigned char i; for (i = 0; i < 256; i++){ MIOS_LCD_CursorSet(i); MIOS_LCD_PrintChar('T'); } Practically it didn't. My guess was that initialization for the seconde LCD is missing because it shows the black bar in the first line.

Thanks, Thorsten. I loaded MBSEQ V2 firmware and both LCDs work.

Hallo! Just to verifiy this, before start debugging on lower level. (electrical connections seems to be ok). There is nothing to do (additional programming) when connecting two 2*16 LCD displays? Only to set the cursor to 0x80 (first line of second LCD) or 0xC0 (seconde line of second LCD)? The enable line of the second LCD is connected to PIC-Pin RC4. All other connections are parallel. LCD one works, LCD two do not. Greetings Thomas

Ok. (Hoping that it's ok to publish private mail) Vangelis Rokas wrote: 1.) For example, when declaring functions with pointer arguments that you already know they point at RAM memory, do not declare them like this: void f(char *str); but like this: void f(__data char *str); The __data specifier uses only 2 bytes for the 'str' pointer, when it would need 3 bytes (and more instructions to handle read/writing, etc...) This is just the tip of the iceberg(!) but I don't have everything on hand right now... 2.) (large arrays) This can be solved by tweaking the .lkr script. Concatenate some DATABANK entries for example: //DATABANK NAME=gpr3 START=0x300 END=0x3FF //DATABANK NAME=gpr4 START=0x400 END=0x4FF //DATABANK NAME=gpr5 START=0x500 END=0x5FF DATABANK NAME=gpr345 START=0x300 END=0x5FF // this creates a segment 3 * 256 bytes This way you could allocate the whole data ram of a pic in a single DATABANK and allocate as much of it you can afford!!!! :-) Greetings Thomas

No, this is no handicap. I just wanted to know this. I contacted the programmer who wrote the PIC16 part of the sdcc project. Sadly there is no complete documentation avaiable. Especially not for code optimization. (How to programm, what to avoid etc.pp.) Btw. large arrays can be created in the linker script.

Hallo! It seems not possible to create large char-arrays with more than 256 elements. Is this correct? unsigned char myArray[256]; //ok unsigned char myArray[257]; //I'll get "no more memory" compiler error But: unsigned char myArray0[256]; unsigned char myArray1[256]; work. It seems it's not a problem of too less remainig memory (registers) but the addressing with only a 8bit.

Ok, I thought they can be "miss-used" for such things since FA, FB etc. are system messages like midiclock, midi control etc. pp. if I remember right. I'll use "boring" normal system messages instead...

Hallo! MPROC_NotifyReceivedByte seems to be called more times than expected when sending Sysex-Midibytes. For debug-issues I scaled down the body of MPROC_NotifyReceivedByte(unsigned char byte) to simply debug the received byte by printing it to the display. I noticed that during receiving the test-midi streams "FX 01 02" (where X goes from 0 to F) MPROC_NotifyReceivedByteis called to receive the bytes: FX 01 02 (->ok, as expected, MPROC_NotifyReceivedByte is called three times) FX 00 01 02 (->with additional 00 byte, MPROC_NotifyReceivedByte is called four times) FX 01 00 02 (->with additional 00 byte, MPROC_NotifyReceivedByte is called four times) I don't remember for what value of the first byte what behaviour occurs. I wrote it on a sheet of paper but I forgot it. (have no Inet at home at the moment) I think from F0 to F6 is all ok. And the "FA 01 02"-Stream will be received as "FA 00 01 02". At a first look at the MIOS-Src I cannot explain this. What happens here? Is this a bug or a feature? ;) Background: I want to create own "Intercom"-Sysex-Messages for chained Midiboxes. (e.g. display messages) Maybe there's a better way to do this. Thomas

FYI: I changed the PIC. And it works now. I assume the PIC was damaged like the Optocoupler. (perhaps a short cut to the 12V).

Hallo audiocommander! I just want to check it with a new PIC. There are some other issues, too. Sometime I got no reply during code upload. And I remember that the optocoupler was damaged and I had to replace it. And even if it's not the PIC it is worth to check the board again and resoldering the PIC. We will see next week.

Thorstens writes explicitely reichelt's order number LCD 162C LED. And LCD 162C LED and LCD 162C is what I have. Is KS0070b not compatible?