Thomas

Hi! For your interest: http://www.krachwerk.de/midibox/midibox.html I redesigned the hardware of my midibox. The software needs some correction. If it running that way I want, I will publish the software, too. It's written in C. Greetings Thomas

You tried to call SetLed_NoDump with 4 parameter but it has 5. ->There must be something wrong. Where does stored_pin come from? (stored_pin) == pin; inside SetLed_NoDump does not change stored_pin outside! stored_pin in SetLed_NoDump is a completey different variable! Use a globel variable for stored_pin or call it via reference or return it unsigned char SetLed_NoDump(...){ ... return stored_pin; } stored_pin = SetLed_NoDump(...);

No he shouldn't. He should use "unsigned char" as loang as he don't need neagtive numbers (then he should use "(signed) char") or values > 255 (>127, <128). to use a 16bit with SDCC and PIC is a very bad idea! This could increase the code to more than doubled size! (the pic is only 8bit and has only 8bit registers)

Noch ein paar Tips: 1. Schau dir machmal das erzeugte *.asm-File im output-Folder an. Es ist gut kommentiert und du findest für jede Programmzeile den entsprechenden Code. Du musst nicht verstehen, was da im einzelnen passiert, aber es gibt ein Gefühl für die Größe des Codes. Dieser kann sich u.U. mächtig aufblähen. 1a) benutze wenn möglich keine Intervariablen int, sondern char. Erspart ca. die Hälfte an Code. 1b) benutze falls möglich unsigned char statt char bei Vergleichen, der Code wird u.U. nochmals kleiner 1c) Vermeide Zugriff über Pointer! 1d) Vermeide Multiplikationen wenn möglich. c = a; for (i = 0; i < b; i++) a+=a; macht deutlich kleineren Code als c = a * b; vorallem wenn a ein Integer (z.B. eine Flash-Adresse ist). Ist auch für kleine b nicht langsamer. 2. Vermeide Arrays über 256 Elemente. Wenn du es dennoch willst: liess die entsprechenden Threads 3. Verzichte auf dynamischen Speicher, nimm ein fixes Array was lang genug ist. 4. SDCC-BUG1: Setze immer Klammern in Ausdrücken wie myarray[a+b]; -> myarray[(a+b)]; 5. SDCC-BUG2: Vermeide Vergleiche von unsigned char mit 0. z.B. unsigned char i; for (i = 0; i < 0; i+ü) { //body } Auch wenn das vielleicht komisch aussieht warum man sowas machen sollte. Aber die 0 könnte eine Konstante sein, die mit #define definiert wurde. Z.B. sie Anzahl der Motorfader. Und du hast gerade keine Motorfader. Richtig fies an den Bugs ist (was der eigentliche Bug ist) dass der Code davon abhängt was du sonst noch so drumrum, vorher oder im Schleifen-Body machts. So kann der Code erst was völlig richtiges machen, bevor du auf die Nase fälltst... 6. SDCC-Bug3: Manchmal klappt die Übergabe von Array (im anderen Modul) nicht richtig. Z.B. //in Datei 1 unsigned char MIDIValues[8]; //in Datei 2 MIOS_MIDI_TxBufferPut(MIDIValues[1]); Da muss man dann sowas stattdessen machen: unsigend char value = MIDIValues[1]; //explicite temp variable MIOS_MIDI_TxBufferPut(value); Warum die Bugs auftreten und ob sie wirklich welche sind, habe ich noch nicht weiter recherchiert. Vermutlich liegt es an diversen Optimierungen des Compilers. Man möge mich korrigeren und/oder die Liste an Tipps ergänzen.

Hi Audiocommander! I will check this next week. Have no time at the moment. But even if it works: SDCC shouldn't produce different code then. Thats the problem, thats why debugging is so hard and thats why I have to ask Thorsten every time how MIOS react to exclude a MIOS bug or unexpected MIOS behaviour. I contacted Vangelis but no replay until now. See the other Thread: In a for-loop SDCC produced different code dependig if I use only constant values in its body or not. Thorsten meant unsigend char i; for (i = 0; i < 0; i++) ... is undefined and therefor the compiler is free to create the code which it wants. I don't think so. I asks in the german C(++) newsgroups because I'm very courious and unsure now. But it seems I'm right: it is defined! The loop is never executet. i < 0 is always false for unsigned i. The problem with signed loop variables are: the code is bigger! There are more asm-statements. Too many in my case, I'm on the upper limit... So it became a #if - orgie... Greetings Thomas

If I use another variable it works: unsigend char index; ... index = i + offset; elements_group = elements_groups[index]; insteadt of elements_group = elements_groups[i + offset];

Hi, debugging and no end. My code in short form (in reality there are code that does something with the values): data unsigned char elements_groups[8]; ..... void f1(){ char i; for (i = 0; i < 8; i++){ MIOS_MIDI_TxBufferPut(0xbd); //only debug print MIOS_MIDI_TxBufferPut((elements_groups >> 4) & 0x0f); //only debug print MIOS_MIDI_TxBufferPut(elements_groups & 0x0f); //only debug print } f2(8, 0); } void f2(unsigned char size, unsigned char offset){ unsigned char i; unsigned char elements_group; for (i = 0; i < size; i++){ elements_group = elements_groups[i + offset]; MIOS_MIDI_TxBufferPut(0xbc); //only debug print MIOS_MIDI_TxBufferPut((elements_groups[i+offset] >> 4) & 0x0f); MIOS_MIDI_TxBufferPut(elements_groups[i+offset] & 0x0f); //only debug print MIOS_MIDI_TxBufferPut(0xba); //only debug print MIOS_MIDI_TxBufferPut((elements_group >> 4) & 0x0f); MIOS_MIDI_TxBufferPut(elements_group & 0x0f); //only debug print } } The array elements_groups has the following values: {0x81, 0x01, 0x01, 0x09, 0x01, 0x01, 0x01, 0x01, 0x01} The first for loop in f1 prints out (via midi) BD 08 01 BD 00 01 BD 00 01 BD 00 09 BD 00 01 BD 00 01 BD 00 01 BD 00 01 All is ok. From funktion f2 I get the following output: BC 08 00 //wrong: must be BC 08 01 BA 08 01 //ok BC 00 00 //wrong: must be BC 00 01 BA 00 01 //ok BC 00 05 //wrong: must be BC 00 01 BA 00 01 //ok BC 00 01 //wrong: must be BC 00 09 BA 00 09 //ok BC 00 0F //wrong: must be BC 00 01 BA 00 01 //ok BC 00 00 //wrong: must be BC 00 01 BA 00 01 //ok BC 00 00 //wrong: must be BC 00 01 BA 00 01 //ok BC 00 00 //wrong: must be BC 00 01 BA 00 01 //ok Ok. I though this it what I noticed as a rule "use a temporare variable not the array itself". It seemed that the version with BA is ok. BUT: If I remove the BC-part I get: BA 00 00 BA 00 00 BA 00 01 BA 0E 01 BA 00 0F BA 00 00 BA 00 00 BA 00 00 >:( What happens here? I haven't checked the produced asm output yet. It's a simliar problem like the other: SDCC produced different behaviour depending from the surrounding code. By the way: this is code that works perfectly with the other software version. It cannot be wrong. The differences between the software versions are controled by #ifdefs and #if But this is a common part of all software versions! Am I the only one who have these problems? It seems all other program successfully with SDCC? Is it a problem of code size? (my code goes up to 7d00)

Hallo! Uuuaaaa...is mir das peinlich :-\ Irgendwo im Code war noch ein MIOS_LCD_CursorSet von einer Ururur-alten-Debug-Message übrig geblieben. Und zwar so dumm weit nach rechts gerutscht, dass man sie im Editor nicht gesehen hat. Jetzt klappen auch die Messages für die nachträgliche Faderkorretur. "corrected 1/2" oder so. Aber gute Idee mit dem UserLCD.

Hi Thorsten! Nein, dass kann nicht sein. intercom_count wird in intercom_scan() immer hochgezählt. Ich habe Debug-MIDI-Strings (analog dem anderen Thread) ausgeben lassen und der if-Zweig mit dem Cursor-setzen wird immer genau einmal ausgeführt. Ich habe es auch auf anderen Cursorpositionen (0x00, 0x40) probiert: das selbe Verhalten. Ich habe auch MIOS_LCD_CursorSet(MIOS_LCD_CursorGet()+1); eingefügt. Immer ist das Verhalten genauso als ob vor jedem Durchlauf ein MIOS_LCD_CursorSet(0xc0); (bzw. 0x00, 0x40) aufgerufen wird. P.S. anderes Thema - aber fällt mir grad ein: Ich habe - da meine Fader schwergängig zu sein scheinen - eine zusätzliche Routine für Motorfader eingebaut. Und zwar wird sich der Zielwert gemerkt und dann im Timer-Aufruf immer genau ein Fader untersucht ob er denn wirklich am Zielwert steht (bzw. größer als Epsilon entfernt), falls nicht wird er erneut angefahren. Das wird n-mal versucht. Vielleicht eine Idee fürs MIOS-Core?

Hallo Thorsten, ich denke du bist der einzige der das beantworten kann. Ich habe gestern was programmiert und bin auf einen Effekt gestossen, den ich mir nicht erklären kann. Szenario: es kommt ein Sysex-String herein: F0 00 01 0F 12 41 42 43 44 7F Dieser wird durch Verschachtelte Funktionaufrufe innerhalb void MPROC_NotifyReceivedByte(unsigned char byte) __wparam gepased: Innerhalb MPROC_NotifyReceivedByte wird die eigene Funktion intercom_scan(byte) aufgerufen, welche den "Befehl" 0x12 == debug printing erkennt und ab dem 6.byte display_scan(byte) aufruft. ("Befehl" 0x13 ist debug printing fortsetzen) void display_scan(unsigned char byte){ switch (intercom_command){ case 0x12: //bei ersten Mal Cursor setzen und Display löschen if (intercom_count == 6) { MIOS_LCD_CursorSet(0xc0); MIOS_LCD_PrintCString(" "); MIOS_LCD_CursorSet(0xc0); } case 0x13: MIOS_LCD_PrintChar(byte); MIOS_LCD_MessageStart(255); } } Was das soll, sollte ersichtlich sein: Ich möchte eine Debugausgabe in Zeile 0xc0 starten und über mehrere Sysex-Strings fortsetzen. Und jedesmal wenn ein weiteres Byte ankommt den MIOS_MESSAGE_CTR zurücksetzen. Das klappt aber so nicht. Denn es wird immer nur genau auf die erste Stelle geprintet, so als ob vor jedem Aufruf von MIOS_LCD_PrintChar(byte); immer ein MIOS_LCD_CursorSet(0xc0); aufgerufen wird. Im Display steht dann in der letzten Zeile immer ein "D". (das letzte zu druckende Byte aus dem Sysexstring) und nicht wie erwartet "ABCD". Wenn ich aber direkt zweimal MIOS_LCD_PrintChar(byte); hintereinander aufrufe erhalte ich "DD". Wie ein Workaround auszusehen hat ist trivial, aber könntest du mir bestätigen dass dieses Verhalten so ok ist? MIOS_LCD_PrintChar(byte); macht ja nicht viel. Ich erkenne nirgends im MIOS-Code, dass der Cusor implizit gesetzt wird. Gruß Thomas, die letzten Feinheiten programmierend.

Hi! FYI: Weil mich das jetzt sehr interessiert hat und ich (auf die Schnelle) darüber nichts finden konnte, habe ich die Frage in den einschlägigen Newsgroups gestellt. Einhellige Meinung: die Bedingung müsste immer falsch sein, die Schleife nie durchlaufen werden. SDCC macht also hier sein eigenes Ding. (was aber nicht so schlimm ist, da es eh kein ANSI-C ist. Nur man muss es halt wissen.)

Hi Thorsten! I find it strange. :-\ Your right. But the warning always says something like this: "test.cpp:8: warning: comparison is always false due to limited range of data typ e" (gcc, g++) I will check this with Visual C++ later. I always thought this statement was clear (always false) and is not undefined. Maybe. But I knew that there must be brackets. I simply forgot them because I normally program JAVA (at work) and C++ and Python (at Home). So I never use preprocessor-directives for constants anymore (I read my Scott Meyers well... ;)) . And all other variants don't need brackets...

Hi Thorsten! I'm using 2.5.0 #1020 (8.Mai 2005). But I could solve the problem. The main problem was that in reality the 8 in the for-statement was no a 8, but a defined constant. for (i = 0; i < (NO_OF_BUTTONS - POS_OF_SPECIAL_LEDS); i++) ... where #define NO_OF_BUTTONS 40 #define POS_OF_SPECIAL_LEDS NO_OF_BUTTONS - 8 I forgot the brackets - changing it to: #define POS_OF_SPECIAL_LEDS (NO_OF_BUTTONS - 8) seems to work. That my mistake. BUT: 1. during debugging I changed it to "8" sometimes - no result. 2. The resulting *asm depend if there are only constants or a variable parameter in the for-block. Assuming that in th upper case POS_OF_SPECIAL_LEDS is defined as NO_OF_BUTTONS so (NO_OF_BUTTONS - POS_OF_SPECIAL_LEDS) == 0. I would assume the for-statement is executed never. As it is. But it is executed 8 times if ther are only constants in the body. Seems that the preprocessor calculates the values differently, depending on the body. I changed your examble so that every time a complete MIDI-controller valus was sent. Summary: VERSION 1: ------------- in Header file ------------- #define NO_OF_BUTTONS 40 #define POSOFSPECIALLEDS NO_OF_BUTTONS - 8 ---------------------------------------- ------------- in function file ------------- void switchLEDs(unsigned char pattern, unsigned char and){ unsigned char i; unsigned char pos; MIOS_MIDI_BeginStream(); MIOS_MIDI_TxBufferPut(0xbb); MIOS_MIDI_TxBufferPut(0x00); MIOS_MIDI_TxBufferPut(0x11); for (i = 0; i < (NO_OF_BUTTONS - POS_OF_SPECIAL_LEDS); i++){ MIOS_MIDI_TxBufferPut(0xbb); MIOS_MIDI_TxBufferPut(32); //constant! MIOS_MIDI_TxBufferPut(0x22); MIOS_DOUT_PinSet1(32); //constant! MIOS_MIDI_TxBufferPut(0xbb); MIOS_MIDI_TxBufferPut(MIOS_DOUT_PinGet(32)); //constant! MIOS_MIDI_TxBufferPut(0x33); } MIOS_MIDI_TxBufferPut(0xbb); MIOS_MIDI_TxBufferPut(0x00); MIOS_MIDI_TxBufferPut(0x44); MIOS_MIDI_EndStream(); } ---------------------------------------- I got: BB 00 11 BB 20 22... 90 times in sum!* BB 01 33... 102 times in sum!* BB 00 44 * the order is mismatched: BB 20 22 BB 01 33 BB 20 22 BB 20 22 BB 01 33 BB 01 33 BB 01 33 BB 20 22 .... VERSION 2: ------------- in Header file ------------- #define NO_OF_BUTTONS 40 #define POSOFSPECIALLEDS NO_OF_BUTTONS - 8 ---------------------------------------- ------------- in function file ------------- void switchLEDs(unsigned char pattern, unsigned char and){ unsigned char i; unsigned char pos; MIOS_MIDI_BeginStream(); MIOS_MIDI_TxBufferPut(0xbb); MIOS_MIDI_TxBufferPut(0x00); MIOS_MIDI_TxBufferPut(0x11); for (i = 0; i < (NO_OF_BUTTONS - POS_OF_SPECIAL_LEDS); i++){ MIOS_MIDI_TxBufferPut(0xbb); MIOS_MIDI_TxBufferPut(32+i); MIOS_MIDI_TxBufferPut(0x22); MIOS_DOUT_PinSet1(32+i); MIOS_MIDI_TxBufferPut(0xbb); MIOS_MIDI_TxBufferPut(MIOS_DOUT_PinGet(32+i)); MIOS_MIDI_TxBufferPut(0x33); } MIOS_MIDI_TxBufferPut(0xbb); MIOS_MIDI_TxBufferPut(0x00); MIOS_MIDI_TxBufferPut(0x44); MIOS_MIDI_EndStream(); } ---------------------------------------- I only got: (as you would expect) BB 00 11 BB 00 44 VERSION 3: (The right one) ------------- in Header file ------------- #define NO_OF_BUTTONS 40 #define POSOFSPECIALLEDS (NO_OF_BUTTONS - 8) ---------------------------------------- ------------- in function file ------------- void switchLEDs(unsigned char pattern, unsigned char and){ unsigned char i; unsigned char pos; MIOS_MIDI_BeginStream(); MIOS_MIDI_TxBufferPut(0xbb); MIOS_MIDI_TxBufferPut(0x00); MIOS_MIDI_TxBufferPut(0x11); for (i = 0; i < (NO_OF_BUTTONS - POS_OF_SPECIAL_LEDS); i++){ MIOS_MIDI_TxBufferPut(0xbb); MIOS_MIDI_TxBufferPut(32+i); MIOS_MIDI_TxBufferPut(0x22); MIOS_DOUT_PinSet1(32+i); MIOS_MIDI_TxBufferPut(0xbb); MIOS_MIDI_TxBufferPut(MIOS_DOUT_PinGet(32+i)); MIOS_MIDI_TxBufferPut(0x33); } MIOS_MIDI_TxBufferPut(0xbb); MIOS_MIDI_TxBufferPut(0x00); MIOS_MIDI_TxBufferPut(0x44); MIOS_MIDI_EndStream(); } ---------------------------------------- I got what I want... BB 00 11 BB 20 22 BB 01 33 BB 21 22 BB 01 33 BB 22 22 BB 01 33 BB 23 22 BB 01 33 BB 24 22 BB 01 33 BB 25 22 BB 01 33 BB 26 22 BB 01 33 BB 27 22 BB 01 33 BB 00 44 Strange, isn't it?

Hallo! I wrote something like: ----------------------- VERSION that works --------------------- void switchLEDs(unsigned char pattern, unsigned char and){ unsigned char i; unsigned char pos; for (i = 0; i < 8; i++){ MIOS_DOUT_PinSet1(32); MIOS_DOUT_PinSet1(33); MIOS_DOUT_PinSet1(34); MIOS_DOUT_PinSet1(35); MIOS_DOUT_PinSet1(36); MIOS_DOUT_PinSet1(37); } } ---------------------------------------------------------------- This works. BUT: all trials to make the pin setting dynamically depending on i failed! ----------------------- VERSION 1 that does not work --------------------- void switchLEDs(unsigned char pattern, unsigned char and){ unsigned char i; unsigned char pos; for (i = 0; i < 8; i++){ MIOS_DOUT_PinSet1(32 + i); } } ---------------------------------------------------------------- This do not work, even if I use the temporär variable pos to store the result of 32 + i. I thougth: ok, if it is a compiler bug and MIOS_DOUT_PinSet1 needs a contant parameter I reprogrammed it: ----------------------- VERSION 2 that does not work --------------------- void switchLEDs(unsigned char pattern, unsigned char and){ unsigned char i; unsigned char pos; MIOS_DOUT_PinSet1(37); //see below! for (i = 0; i < 8; i++){ switch(i){ case 0: MIOS_DOUT_PinSet1(32); break; case 1: MIOS_DOUT_PinSet1(33); break; case 2: MIOS_DOUT_PinSet1(34); break; case 3: MIOS_DOUT_PinSet1(35); break; case 4: MIOS_DOUT_PinSet1(36); break; case 5: MIOS_DOUT_PinSet1(37); break; } } } ---------------------------------------------------------------- This didn't work, too. No pin is set, except pin 37. This was to indicate the function itselfs is called. I tried another version, with ifs: ----------------------- VERSION that works --------------------- void switchLEDs(unsigned char pattern, unsigned char and){ unsigned char i; unsigned char pos; MIOS_DOUT_PinSet1(37); for (i = 0; i < 8; i++){ if (i == 0) MIOS_DOUT_PinSet1(32); else if (i == 1) MIOS_DOUT_PinSet1(33); else if (i == 2) MIOS_DOUT_PinSet1(34); else if (i == 3) MIOS_DOUT_PinSet1(35); else if (i == 4) MIOS_DOUT_PinSet1(36); else if (i == 5) MIOS_DOUT_PinSet1(37); } } ---------------------------------------------------------------- Even this did not work! Only LED 37 ligths. If I look at the *.asm the call of MIOS_DOUT_PinSet1(constant) is always the same. Independently if there are switches or ifs around it. But only the "pure" constant method above works. I have no ideas. The *.asm seem to be ok. As you can guess, the parameter "pattern" is the bit-pattern which of the LEDs 32-37 shall lit. But this is future...even the primitive varants do not work. I have no idea.

Hallo, danke für die Infos. Morgen ist wieder Basteltag... ;)