MIOS_LCD_MessageStart

[Thomas]

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.

[TK.]

Hallo Thomas,

Ich erkenne nirgends im MIOS-Code, dass der Cusor implizit gesetzt wird.

das ist auch nicht so... von aussen betrachtet (ich kenne Deinen restlichen Code nicht), verhaelt sich die Routine so, wie wenn intercom_count auf 6 stehen bleiben wuerde, kann das sein? Wann wird die Variable hochgezaehlt?

Gruss,

        Thorsten.

[Thomas]

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?

[TK.]

Hallo Thomas,

Immer ist das Verhalten genauso als ob vor jedem Durchlauf ein MIOS_LCD_CursorSet(0xc0); (bzw. 0x00, 0x40) aufgerufen wird.

es wuerde mich wirklich sehr wundern, das wuerde die Performance von MIOS Applikationen ziemlich beeintraechtigen, und ich muesste das E Signal wackeln sehen, wenn ich es mir mit dem Scope anschaue - tut es aber nicht.

Du koenntest ja mal spasseshalber auf MIOS_LCD_TypeSet(7, 0, 0) umschalten, und dann in mios_wrapper/app_lcd.inc die Debugmeldungen einbauen. Dann muesste man sehr genau sehen, wann der Cursor gesetzt wird

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?

Eine clevere Loesung! Ich wuerde so etwas jedoch lieber auf Applikationsseite belassen - ganz unter dem Motto "Never change a running system". So kann man den Retryalgorithmus anpassen, ohne dass MIOS noch weitere Parameter zur Verfuegung stellen muss.

Gruss,

        Thorsten.

[Thomas]

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.