LambdaSpeak FS - Serieller Modus

[TFM]

Hier einige Messwerte zum LSF im Seriellen Modus. Weitere Informationen gibt es auf github unter LambdaSpeak FS

Daten für Firmware Version 8:

Experimentelle Ermittlung serieller Kommandos &FF, &xx
--------V--------V------------------------------------
Befehl ! T min. ! T max.   / Gepufferter Modus
--------+--------+-------- /
&FF,&03 ! 1 NOPs !10 NOPs
--------+--------+--------
&FF,&04 ! 1 NOPs !10 NOPs
--------+--------+--------
&FF,&07 ! 2 NOPs !11 NOPs
--------+--------+--------
&FF,&08 ! 4 NOPs !14 NOPs
--------+--------+--------
&FF,&09 ! 9 NOPs !18 NOPs
--------+--------+--------
&FF,&0E ! 0 NOPs ! 9 NOPs
--------+--------+--------

Befehl ! T min. ! T max.   / Direkter Modus
--------+--------+-------- /
&FF,&03 ! 1 NOPs !10 NOPs
--------+--------+--------
&FF,&04 ! 1 NOPs !10 NOPs
--------+--------+--------
&FF,&07 ! 2 NOPs !11 NOPs
--------+--------+--------
&FF,&08 ! 4 NOPs !14 NOPs
--------+--------+--------
&FF,&09 ! 6 NOPs !16 NOPs
--------+--------+--------
&FF,&0E ! 0 NOPs ! 9 NOPs
--------+--------+--------

Bester Kompromiss beim Lesen von Bytes vom LSF:
--------+--------+--------
Max/Min ! 9 NOPs ! 9 NOPs
--------+--------+--------

[TFM]

Hier einige Messwerte zum LSF im Seriellen Modus. Weitere Informationen gibt es auf github unter LambdaSpeak FS

Daten für Firmware Version 9:

Experimentelle Ermittlung serieller Kommandos &FF, &xx - Firmware Version 9
--------V--------V---------------------------------------------------------
Befehl ! T min. ! T max.   / Gepufferter Modus
--------+--------+-------- /
&FF,&03 ! 1 NOPs !10 NOPs
--------+--------+--------
&FF,&04 ! 1 NOPs !11 NOPs
--------+--------+--------
&FF,&05 ! 0 NOPs !10 NOPs
--------+--------+--------
&FF,&07 ! 2 NOPs !12 NOPs
--------+--------+--------
&FF,&08 ! 4 NOPs !14 NOPs
--------+--------+--------
&FF,&09 ! 5 NOPs !15 NOPs
--------+--------+--------
&FF,&0E ! 0 NOPs !10 NOPs
--------+--------+--------

Befehl ! T min. ! T max.   / Direkter Modus
--------+--------+-------- /
&FF,&03 ! 1 NOPs !10 NOPs
--------+--------+--------
&FF,&04 ! 1 NOPs !11 NOPs
--------+--------+--------
&FF,&05 ! 0 NOPs !10 NOPs
--------+--------+--------
&FF,&07 ! 2 NOPs !12 NOPs
--------+--------+--------
&FF,&08 ! 4 NOPs !14 NOPs
--------+--------+--------
&FF,&09 ! 5 NOPs !15 NOPs
--------+--------+--------
&FF,&0E ! 0 NOPs !10 NOPs
--------+--------+--------


--------+--------+--------!--------+----
Max/Min ! 5 NOPs !10 NOPs ! FW8: 9 ! 9 !
--------+--------+--------!--------+----

[TFM]

Zum Seriellen Modus hab ich mal zwei simple BASIC Programme gemacht um zu sehen was so geht...
Auf der 2. DSK für den LSF sind SI-SEND und SI-RECEI drauf - einfach mal laden & listen.

Was können die?
- Datenblöcke aus dem RAM von CPC zu CPC übertragen, bis zu ca. 500 Bytes
- Ab 500 Bytes im Receiver bitte Zeile 140 löschen (den Print Befehl). Dann liest er Empfangenes schneller
- Bis zu 2 KB Blöcken getestet und tut.

Was kann es nicht?
- 16 KB Block übertragen. Warum? Scheint so zu sein dass keine Bits empfangen werden, wenn man gerade etwas vom LS zum CPC liest. Das liegt wohl daran, dass die LS-CPU auch nur eine Sache gleichzeitig tun kann.

Das ganze dient als simples Beispiel (mit den LS ROM Befehlen).

Download wie immer: Siehe meine Signatur...

[LambdaMikel]

Was kann es nicht?
- 16 KB Block übertragen. Warum? Scheint so zu sein dass keine Bits empfangen werden, wenn man gerade etwas vom LS zum CPC liest. Das liegt wohl daran, dass die LS-CPU auch nur eine Sache gleichzeitig tun kann.

Hmm, interessant. Wie äußert sich dass? Datenverlust? Eigentlich sollte es gehen... könntest Du sonst einmal versuchen, den Sub-Modus 50 zu verwenden. Mit dem kann man evtl. schneller Lesen sobal ein Byte verfügbar ist, sodass der Puffer nicht überläuft / blockiert.

Welche Datenrate kriegst Du mit 2 KB Blöcken?

Intern läuft das so, dass ein ankommentes Byte an der seriellen Schnittstelle einen Interupt auslöst, egal was LS-FS gerade macht (also z.B. Daten an den CPC sendet). Der LS-FS kriegt als ankommendes Byte immer mit, das ist nicht der Grund.

Die ISR speichert momentan allerdings nur ein Byte... dieses Byte wird es dann in den Empfangsbuffer geschrieben, wenn LS-FS wieder in der "Hauptschleife" (wo er die 255, ... etc. Kommandos annimmt) angekommen ist. Sollte in der Zwischenzeit ein 2. Byte ankommen, wird das evtl. verschluckt.

Früher war es so, dass ich direkt in der ISR die Bytes in den Empfangsbuffer geschrieben habe. Da dies allerdings zeitaufwändiger war (die ISR bruachte nun mehr Zeit, wg. Pointer- und Arrayzugriffen und so), habe ich das umgebaut. Für dem MIDI "Steamingmode 10 und 50" war das vorteilhaft, dass die ISR zu schnell wie möglich zurückkehrt.

Für die Anwendung hier könnte es besser sein, die ISR wieder wie früher einzurichten.

[TFM]

Einfach mal die beide BASIC Programme ausprobieren, die zeigen den Effekt am besten.

IMHO liegt das Problem darin: Wenn man abfragt ob Daten im Puffer sind bzw. während man Daten aus dem Puffer liest, können Bytes verloren gehen. Wenn Bytes genau in dem Moment ankommen, dann sind sie weg.

Es sind Standard Parameter (9600 baud). Mit Slow-Getters ist der Effekt riesig, mit Fast-Getters nur noch ganz klein.

Es ist auch keine Kritik, eher mal so ein Befund. Gut zu wissen wenn man programmiert.
Da wird sich wohl auf Hardware-Ebene auch nichts machen lassen. Außer der ATMega könnte ein Byte empfangen und puffern während er etwas anderes macht.

[TFM]

Hier mal die Daten für die Firmware 10...


Experimentelle Ermittlung serieller Kommandos &FF, &xx - Firmware Version 10
--------V---------V----------------------------------------------------------
Befehl !  T min. !  T max.  / Gepufferter Modus und
========+=========+======== /  Direkter Modus
&FF,&03 !  7 NOPs ! 17 NOPs
--------+---------+--------
&FF,&04 !  7 NOPs ! 17 NOPs
--------+---------+--------
&FF,&05 !  7 NOPs ! 17 NOPs
--------+---------+--------
&FF,&07 !  7 NOPs ! 17 NOPs
--------+---------+--------
&FF,&08 !  8 NOPs ! 18 NOPs
--------+---------+--------
&FF,&09 !  8 NOPs ! 20 NOPs
--------+---------+--------
&FF,&0E !  5 NOPs ! 15 NOPs
--------+---------+--------
&FF,&0E ! 11 NOPs ! 21 NOPs
--------+---------+--------


--------+---------+--------!-------------------------
Max/Min ! 11 NOPs !15 NOPs ! FW.10: 12 ist also ideal
--------+---------+--------!-------------------------


Das ROM für Firmware 10 habe ich hoffentlich nächste Woche fertig. Denn das alte ROM funzt nicht mit FW10, da Michael noch einiges an tollen Sachen eingebaut hat.

[LambdaMikel]

Interessante Messungen!
Wobei - wenn Du den neuen "handshake getters" Modus verwendest, wäre es gut, etwas länger zu warten. Hintergrund ist, dass der CPC - dem ATmega / der Firmware - sonst "vorneweg" rennt, und es wieder zu Synchronisationsproblemen kommen könnte. 
Also - lieber etwas länger warten, als zu kurz. Mit Experimenten wie Deinen kriegst Du die optimale Einstellung sicherlich raus.

[TFM]

Interessante Messungen!
Wobei - wenn Du den neuen "handshake getters" Modus verwendest, wäre es gut, etwas länger zu warten. Hintergrund ist, dass der CPC - dem ATmega / der Firmware - sonst "vorneweg" rennt, und es wieder zu Synchronisationsproblemen kommen könnte. 
Also - lieber etwas länger warten, als zu kurz. Mit Experimenten wie Deinen kriegst Du die optimale Einstellung sicherlich raus.

Ganz genau, das war ja auch ohne Handshake Getters. "Mit" kann ich ja nochmal nachmessen, wird aber wohl gleich bleiben.
Die Wartezeit ist auch auch sinnvoll nutzbar. Muss man hald entsprechend programmieren. 

[TFM]

Dank dem Michael und der Firmware 10  läuft der serielle Modus jetzt sehr viel besser.

Die Testprogramme SI-RECEI und SI-SEND können problemlos (bei allen Baud Raten) 16 KB übertragen und zwar Fehlerlos. 

Ja, gut beim Empfänger-Programm muss man die Zeile 110 löschen (Ausgabe der Adresse), sonnst kommt das nicht mehr mit, ist eben BASIC.

Den schönen neuen Handshake-Modus habe ich dabei noch gar nicht eingebaut. Das ROM ist jetzt an Firmware 10 angepasst. Siehe meine Homepage oder gleich hier:

Wer sich Firmware 10 nicht selber in den ATMega644 brennen kann, dem kann ich natürlich helfen. 

[LambdaMikel]

Gut dass es jetzt besser funktioniert! Vielen Dank für das Update, probiere ich demnächst aus.

[TFM]

Und weil es so schön ist, gibt's jetzt auch die ersten positiven Meldungen vom XMODEM.

Es gibt zwei neue Befehle:
|S.XBLK: Mit dem Befehl |S.XBLK,Adresse,Länge kann ein Speicherbereich per XMODEM verschickt werden. Dabei definiert 'Adresse' die Startadresse im RAM und 'Länge' die Anzahl der 128 Byte Blöcke.

|R.XBLK: Mittels des Befehls |R.XBLK,Adresse können per XMODEM verschickte Daten empfangen und ab 'Adresse' ins RAM geschrieben werden.

Achtung: Vor dem Verwenden der Befehle '|S.XBLK' und '|R.XBLK' bitte beide LSF in den seriellen Modus schalten!

Momentan läuft es gut mit bis zu 14400 Baud, ab 19200 gibt es Probleme - die ich auch noch in den Griff bekommen werde.