Entwicklung APC 3.0 -> Lisy_APC

[bontango]

Ja, läuft 🙂 Es ist halt wie immer: kaum macht mans richtig funktioniert es.

Zum Protokoll: wie wäre es wenn Du als Slave immer als erstes Byte einen Status zurück gibst?

Mögliche Werte:

0 : nicht bereit/beschäftigt  -> Master wiederholt Befehl nach Wartezeit ( wie lange soll ich warten, 1ms ? )

Anzahl empfangener Bytes -> Befehl angenommen und ausgeführt ( Minimum 1 )

-1: Befehl angenommen aber Interpretationsprobleme :  Error

[Black Knight]

vor 14 Stunden schrieb bontango:

Zum Protokoll: wie wäre es wenn Du als Slave immer als erstes Byte einen Status zurück gibst?

Ja genau, das meinte ich. Ich wollte zwar, dass der APC die Anzahl der Bytes schickt die er im Sendepuffer hat, aber du hast Recht; es macht mehr Sinn den APC die Anzahl der empfangenen Bytes bestätigen zu lassen.

vor 14 Stunden schrieb bontango:

( wie lange soll ich warten, 1ms ? )

Ja, lass uns mal mit 1ms starten. Ich rechne sowieso damit, dass dieser Mechanismus nur nach Soundkommandos zum Einsatz kommen wird. Ansonsten ist der APC vermutlich schnell genug.

Dann sähe unsere initiale Kommunikation also wie folgt aus:

Lisy: 0x00

APC: 0x00 falls der Befehl noch nicht komplett verarbeitet wurde, ansonsten

APC: 0x01 (Bestätigung des empfangenen Bytes), dann "APC\0" als Antwort

Lisy: 0x40, 0x01, 0x02 (Lese Setting 2 aus Gruppe 1)

APC: 0x00 falls der Befehl noch nicht komplett verarbeitet wurde, ansonsten

APC: 0x03 (Bestätigung der empfangenen Bytes), dann den Wert des Settings als Antwort

 

Falls irgendwas schief geht antwortet der APC mit 0xff

Das müsste es doch sein, oder?

[bontango]

vor 2 Stunden schrieb Black Knight:

Das müsste es doch sein, oder?

Ja denke auch, lass uns das mal auf beiden Seiten implementieren und schauen was passiert

[Black Knight]

Ich hab's jetzt drin.

War ein größerer Umbau, bin gespannt ob's klappt.

Kommunikation über USB funktioniert zur Zeit nicht, die muss ich wieder dazu basteln wenn I2C läuft.

[bontango]

Kann ich mir morgen anschauen, melde mich ...

[Black Knight]

Sieht gut aus.

Ich habe dein getDIPfrom APC mal angepasst. Normalerweise sieht es so aus:

pi@lisy(ro):/run/user/1000$ ./getDIPfromAPC 2 -v
we are in verbose mode
try to get value of dip number 2
API_read_string: Byte no 1 is (0x01)""
API_read_string: Byte no 0 is (0x41)"A"
API_read_string: Byte no 1 is (0x50)"P"
API_read_string: Byte no 2 is (0x43)"C"
connected HW is: APC
API_read_string: Byte no 1 is (0x03)""
value of Dip number 2 is 45

Wenn ich den APC jetzt absichtlich ausbremse, dann kommen die 'Wartenullen' dazu:

pi@lisy(ro):/run/user/1000$ ./getDIPfromAPC 2 -v
we are in verbose mode
try to get value of dip number 2
API_read_string: Byte no 1 is (0x00)""
API_read_string: Byte no 1 is (0x01)""
API_read_string: Byte no 0 is (0x41)"A"
API_read_string: Byte no 1 is (0x50)"P"
API_read_string: Byte no 2 is (0x43)"C"
connected HW is: APC
API_read_string: Byte no 1 is (0x00)""
API_read_string: Byte no 1 is (0x00)""
API_read_string: Byte no 1 is (0x00)""
API_read_string: Byte no 1 is (0x00)""
API_read_string: Byte no 1 is (0x00)""
API_read_string: Byte no 1 is (0x03)""
value of Dip number 2 is 45

So ungefähr hatten wir uns das doch vorgestellt,oder?

[bontango]

Ja genau 🙂

Die API habe ich soweit auf meiner Seite geändert, sieht auch gut aus.

Derzeit liest er die Gamenummer und die Optionen aber noch von den Dips auf meiner LISY_mini,

da bin ich grad dran ...

[Black Knight]

Na so langsam wird's doch.

USB Kommunikation geht auch wieder.

[bontango]

Hast Du die auch auf das neue Protokoll umgestellt?

 

[Black Knight]

Nein, die ist wie vorher.

Da die ja auch für MPF verwendet wird, müssten wir das ja zuerst mit Jan klären.

[bontango]

Ok, dann muss ich da noch nen Schalter einbauen.

Irgendwas hackt derzeit beim Start, morgen mehr, Manni tanzt auf der Tastatur rum ...

[bontango]

Hier mal die erste Version zum Test: http://www.flipperkeller.de/lisy/lisy_update_5_26_33.tgz

Derzeit wird nur S2 (setting 3; game number) vom APC gelesen.

Den Autostart habe ich fest rausgenommen weil ich immer mal wieder den Effekt hatte dass es ne Zeitlang lief

und dann plötzlich nur noch '0x0' vom APC zurück kam. Liess sich nur durch neustart Arduino beheben.

Du musst dich einloggen und dann Manuell starten mit "./run_lisy_apc"

 

Schau mal bitte wie weit Du kommst.

Gruesse

Ralf

[Black Knight]

Wie kann ich denn LisyControl starten, ohne einen Flipper angeschlossen zu haben? Oder kann ich das Update direkt irgendwo auspacken?

Dadurch dass der blöde Pi 3B+ nicht funzt habe ich gerade keine Möglichkeit Lisy an einen Flipper anzuschließen. Wenn ich nun DIP6 setze, dann springt irgendwann die rote LED und er scheint LisyControl nicht zu starten.

Ich werde mir übrigens wieder einen Pi 3A bestellen, damit ich Lisy auch wieder über USB nutzen kann.

[Black Knight]

Kann ich die Updatedatei nach update_prep kopieren und dann do_update_prep ausführen?

[bontango]

Stimmt, habe ich nicht dran gedacht ...

Du kannst das Update manuell ausführen:

erst mit 'rw' in den read/write modus wechseln, dann

cd update

wget http://www.flipperkeller.de/lisy/lisy_update_5_26_33.tgz

tar -xzf lisy_update_5_26_33.tgz

sudo install.sh

sudo reboot

[Black Knight]

Lisy mag mich nicht mehr:

pi@lisy(ro):~$ run_lisy_apc
==== AUTHENTICATING FOR org.freedesktop.systemd1.manage-units ===
Authentication is required to start 'dhcpcd.service'.
Authenticating as: root
Password:
==== AUTHENTICATION COMPLETE ===
/usr/local/bin/run_lisy_apc: line 69: /dev/serial0: Permission denied

Ich hab's dann auch mal mit 'sudo run_lisy_apc' probiert. Da kommt dann auch keine Fehlermeldung mehr aber es passiert trotzdem nichts am I2C Bus.

Auch bei den LEDs tut sich nichts; nach dem Bootvorgang leuchtet die gelbe LED durchgehend und das war's

[bontango]

Ups, ich hätte evtl. kreativer bei der Namensgebung sein sollen 🙄

Der script den Du aufrufst ist ein startscript aus /usr/local/bin daher will der nochmal das Netzwerk starten.

Es gibt im Homeverzeichnis von pi noch einen.

Probier mal ./run_lisy_apc bitte

[bontango]

ah, wird auch schief gehen, die lisy binary die da im Pfad steht ist nicht upgedated worden 😐

du musst den script ändern von

sudo ./lisy/xpinmame.vid_lisy -nosound -skip_disclaimer -skip_gameinfo -nvram_di
rectory /pinmame/nvram -rp /boot/lisy/lisy_m/roms lisy_apc

nach

sudo /usr/local/bin/lisy -nosound -skip_disclaimer -skip_gameinfo -nvram_di
rectory /pinmame/nvram -rp /boot/lisy/lisy_m/roms lisy_apc

 

[Black Knight]

Jetzt läuft's und ich kann das Problem nachstellen.

Es sieht so aus, als würde Lisy nicht auf den APC warten. Im beigefügten Screenshot schickt der APC eine Null um zu signalisieren, dass er den Befehl noch nicht komplett bearbeitet hat. Lisy scheint daraufhin auch zu warten, fragt aber nicht erneut nach, ob der APC nun fertig ist, sondern schickt direkt den nächsten Befehl.

Ich hatte das jetzt so eingebaut, dass Lisy nochmal ein Byte liest und zwar so lange bis der APC die Länge des letzten Befehls zurück schickt.

[bontango]

Bei mir wiederholt er den Befehl nach ca. 1ms wenn er ne Null zurückbekommt. d..h Du bufferst dei Antwort und schickst sie dann 'irgendwann'?

[bontango]

ausser beim pollen mit 'get status of switch' da interpretiert er das als keine Änderung und wartet nicht sondern verlässt sich auf den nächsten Poll

[Black Knight]

vor 19 Minuten schrieb bontango:

Du bufferst dei Antwort und schickst sie dann 'irgendwann'?

Genau, es könnte ja auch länger als einen Wartezyklus dauern den Befehl zu bearbeiten. Deshalb geht es bei mir nicht weiter bevor der APC seine Antwort nicht los geworden ist.

[Black Knight]

Bei 'get status of switch' könnte man natürlich eine Ausnahme machen, aber momentan werden bei mir alle Befehle gleich behandelt.

[bontango]

Stell ich morgen auf meiner Seite um

Melde mich

[bontango]

so, next try

http://www.flipperkeller.de/lisy/lisy_update_5_26_34.tgz

Bearbeitet 23. Oktober 2020 von bontango