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... ;)

Hallo, ich habe da noch eine Frage. Das Problem ist doch, dass ich MIDI-Daten sende bevor der Sysextring vollständig übertragen wurde. Was passiert denn jetzt mit normalen Fader-Events beim Bewegen der Fader? Die düfte man dann doch auch nicht direkt senden, oder? Kann doch dann auch sein, wenn ich an MIDI-Box2 einen Fader bewegen und dass entsprechende MIDI-Event senden will, dass gerade ein Event von MidBox1 herein kam, weil ich auch da einen Fader bewegte.

Hallo Thorsten! Gut, das du das sagst bevor ich es implementiere. Allerdings würde es auch den MIDI-Strom verringern. Das ist exakt die Frage. Denn laut Software wird von der MIDI-Box 1 erst der Sysex-String gesendent und dann die Fader-Events. Die MIDI-Box 2 parsed den Sysex-String, und sendet daraufhin selber ihre MIDI-Daten, nachdem die von EEPROM gelesen wurden. Und da kommt scheinbar was durcheinander, so dass MIDI-Box "3" den Sysex-String verscrampelt bekommt. Das ist natürlich eine Idee. Zumal es bei zeitunkritischen Sysex-Commandos schon so funktioniert. Ich habe aber noch ein großes Bedenken: Es kann passieren, dass meine Audio-Software >127 Controllerbefehle sendet. Und die müssen in jeder MIDI-Box geparsed und geforwarded werden. Mit den alten Midibox64 war das allerdings kein Problem. Ich zerbreche mit gerade noch über etwas anderes den Kopf: Ich habe noch nicht probiert ob mein Netzteil tatsächlich 32 Fader auf einmal bewältigt. Falls nicht müsste dieser nur im Initaliserungs-, Audiosoftware-Start- oder Snapshot-Fall vorkommende Fall entschäft werden.

Hallo Thorsten! Pro Snapshot werden 8-Events von Midibox 1 und 2 versandt. D.h. im In-buffer von MIDI-Box 2 stehen maximal 7 bytes vom Sysex-Befehl der von MB1 zuerst gesendet wird 40 bytes von den 8x5 Bytes "F9 B1 0n vv FE" der Events. Also 47. Abgesehen davon. Bei einer Taktrate von 40Mhz und MIDI-Datenrate von 32000Bytes/s sollten 1250 Takte pro MIDI-Byte zur Verfügung stehen. Sollte eigentlich reichen um alle reinkommenden MIDI-Bytes mit mehr als 1000 Befehlen zu verarbeiten und wieder zu senden. Wo soll da ein Bottleneck entstehen?

Vielleicht nochmal zum Verständnis: MIDI-Box 1: (MBLink-Forward) - verfügt über Button, generiert Befehle - sendet Befehl und sendet Events MIDI-Box 2: (MBLink-Forward) - hat weder Buttons, noch Display - wertet Befehl aus und generiert Snapshot-Events - leitert Befehl und Events von 1 weiter Nach MIDI-Box2 sieht der Strom wie oben beschrienen aus. Die Events von MB1 kommen ordentlich danach.

Hallo! Nachdem nun das akute Hardware-Problem beseitigt ist (hoffentlich...) treten jetzt die Softwarefehler wieder in den Vordergrund. Manche sind einfach Flüchtigkeitsfehler, manche andere Bugs, die man beseitigen oder Workarounden kann. Aber einer bleibt: Und zwar habe ich eine Snap-Shot-Funktionalität gebaut, bei dem bei drücken auf einen Button die Werte aus dem EEPROM gelesen werden und das komplette Event für alle Fader (z.B. b1 00 65) gesendet werden. (und natürlich werden die Fader auch auf Position gefahren. Soweit funktioniert es auch. Jetzt sende ich aber vorher noch einen kurzen Sysex-String (z.B) "F0 00 01 0f 20 73 F7" um die nachfolgenden MBs zu benachrichtigen "Hallo, Snapshot Nr. 1[2,3] ausgelöst") . Das funktioniert im Prinzip auch. Jedoch kommen die Bytes nach der zweiten Midibox u.U. durchmischt an. Laut MIDI-OX: F9 F0 00 01 0f 20 B2 01 00 FE F9 B2 02 00 FE ... F9 B2 07 00 FE B2 73 00 F7 Aufgedröselt: F9 ... häää? Warum jetzt schon. F0 00 01 0f 20 ... sollte kommen, aber bricht ab. B2 01 00 FE ... fast ok, Event von Midibox2, Fader01, welcher auf 00 steht. F9 B2 02 00 FE ... weitere Events wie erwartet, maskiert B2 73 00 F7 ... ein neues unterwartetes Event? wie kommt da sie verlorene 73 rein? Wenn ich MIDI-OX trauen kann. (Hatten wir schonmal das Thema) Das Problem ist dass die Sysex-Strings (==intercom-Befehle) nicht mehr von der letzten über Display verfügenden Midibox empfangen werden. Jedenfalls nicht immer. Kann das ein Problem mit dem MIDI-Merger sein? Konnte ich mich verständlich ausdrücken?

Guten Abend Thorsten! Kurzes Update: Wichtigste Erkenntnis: wenn zwei benachbarte Fehler gleichzeitgi auftreten, dann haben sie meist gar nichts miteinander zu tun. Erstens: Fader 2 (Also No. 01) hatte keinen Wackler - alles bombenfest - sondern der TC4427 war defekt. (Spannungen an ihm haben nicht gestimmt.) Er wurde durch einen MIC4427 ersetzt. -> geht wieder. (Vermutlich war er von anfang an Defekt und hat die Latchups am 74HC595 verursacht.) Zweitens: Fader 4 (also No. 03) funktionierte auch nicht ordentlich, wenn ich ihn mit einem anderen elektrisch getauscht hatte. Ich stellte auch fest, dass beim tiefsten Punkt nicht immer 0x00 (7bit value) erreicht wurde. Manchmal war es 0x01. Ich habe ihn gegen einen anderen Fader, den ich praktisch nicht benötige und der auch (noch?) nicht motorisiert ist getausch: und siehe da, es geht. Kurioserweise liess sich per Hand kaum ein Unterschied in der Schwergängkeit feststellen.

Hi Thorsten! Ich habe auf einem Board massive Probleme. Es ist mir dauernd das eine Schiftregister für die Ansteuerung der TC4427 abgeraucht. Mittlerweile bin ich überall (bis auf diese Board) zu MIC4427 gewechselt und habe diverse Kondensatoren (100n nahe der MICs) über die 9V-Leitung gelötet. Keine Probleme *klopf auf Holz*. (Bis auf dass 12V-Netzteil jetzt nicht mehr ausreicht. Aber das ist weniger das Problem.) Dann habe ich den Effekt, dass diese Board kurz "stillzustehen" schein. Ein Reboot ist unwahrscheinlich, da die entsprechende (MIDI-Sysex-)Meldung ausbleibt. Oder eben verloren geht. Deine Antworten helfen mir aber ungemeint! Denn sie schliessen einiges aus. Angeregt durch den Thread habe ich nochmal eine simple MF-Application geladen. Bis auf Motorfader Nr. 01, der wohl einen Wackler hat, bewegen sich alle 7. Allerdings geht Motorfader Nr. 03 sehr langsam. 4s(!) von 0 bis max. Wohingegen alle anderen <1s brauchen. Manchmal - aber nicht immer(!*) - schaltet Nr. 03 gar nicht ab wenn max oder min erreicht! Sondern "brummt" noch 10s oder so auf der Extremstellung. MIDI-Values werden von Nr. 03 korrekt erzeugt. Also der AD sollte gehen. *wirklich nichtderterministisch zufälllig, mal neu booten dann gehts, dann wieder nicht. Ich habe langsame einen Verdacht, dass meine ALPS-Fader (nicht alle, aber einige) vergleichsweise schwergängig sind! Das würde einiges erklären.

Hallo Thorsten und alle anderen! (diesmal auf Deutsch, geht schneller...) Ohne jetzt intensiv die Motorfaderroutinen durch arbeiten zu müssen: Was passiert, wenn ein Motorfader nicht (genug) bewegt werden kann? Wann gibt die Routine auf? Beinflusst das die anderen Fader? Blockiert die Fader-Anfahr-Routine die Midibox? Können MIDI-Events dabei verloren gehen? Ab wann kann man Motorfader bewegen? (Schon in der init-funktion?) (wie man sich denken kann, habe ich da noch in paar Probleme)

Hallo! I have a problem with the shiftregister of one PIC. The DIN-shiftregister does not work. When I press button 8 on the first shiftregister it is like pressing all 40 buttons, but pressing onother button has no effect. (The DOUT register do not work, too.) I have no scope, so I messured the voltage on pins D3 and D2 with a multimeter. I get 0.16V and 2.55V. BUT on the other pic that works I messure 0.08V and 3.5V. I changed the EQU of the pins in the MIOS-src, compiled a new MIOS with interchanged D2 and D3 and I messured 2.55V and 0.16V as expected. The pins have changed. All connections seems ok, and even worse, it had worked last week! Something must be broken and I could find it. I replaced the 165, too.

Hi Thorsten! First of all it works! :) But I though it didn't work because of another midi trouble of MIOS Studio and even MIDIOX (win98). Both seems to have problems with F9...FE MIDI-Events. They are to intelligent... So that if a F9-event came, they do not show the real input for a moment! Even worse if tis happens in a MIDI-loop it can crash (freeze) both programs. (ok, sometimes this happens with normal MIDI-events, but you would see the neverending input stream before and know what happend). So I have two questions: 1.) is there a MIDIanalysing tool what simply shows the incoming bytes without any "intelligence"? 2.) Motorfader-Modul: Sometimes I have the problem that moving fader 0 by hand, MIDI events for this Fader will be sent (a simple MIDI-Generation depending on pin and value in AIN_NotifyChange) like expected. Just in time. But moving all other faders the MIDI-values will be sent only if I move the fader completely up and down. It seemed that the fader must find a special postion (the one that's saved in MIOS-Fader-RAM) and only after that it will work like expected. It looks like the MIDI-Box are waiting for something (a motorfader that cannot be moved, incoming midi etc.pp., but ther are no explicit moving function call!) or resets (without initial request strings). Can this be? Or is this a similar effect to that mentioned above?