Entwicklung APC 3.0 -> Lisy_APC

[bontango]

Hast Du das beim 3er mal manual über ssh gestartet und kurz vorher den Arduino resettet? ( mit "./run_lisy-apc" )

Beim Autostart geht mein 3er auch nicht, ich vermute mal dass der Arduino durch die Bootmeldungen vom

PI verwirrt wird, die gibt er über seriell aus ...

[Black Knight]

vor 56 Minuten schrieb bontango:

Hast Du das beim 3er mal manual über ssh gestartet und kurz vorher den Arduino resettet? ( mit "./run_lisy-apc" )

Ist das gleiche. Dazu hatten wir ja auch extra das Freigabesignal an GPIO18 eingeführt. Das scheint auch alles zu funktionieren; während des ganzen Bootvorgangs zeigt mein Display 'Waiting f Lisy' und springt dann für die Startmeldung mit dem Countdown um. Bis hierher also alles super, aber wenn PinMame startet kommen die 'Unknown Command' Meldungen. Danach fängt sich das Ganze meistens wieder und der Attract Mode läuft scheinbar normal weiter. Erst beim Start eines Spiels dreht es dann total ab.

So lange du nur am Schreibtisch testest kann es also sein, dass du die Probleme gar nicht bemerkst, da sich das System immer wieder synchronisiert. Ich versuche jetzt mal, die 'Unknown Command' Meldung so zu verändern, dass eine Meldung auf dem USB Anschluss ausgegeben wird. Damit sollte man es auch am Schreibtisch erkennen können.

 

[bontango]

und beim Zero W ist alles OK? 🤔

 

[Black Knight]

vor 50 Minuten schrieb bontango:

und beim Zero W ist alles OK? 🤔

Alles super. Genau wie bei den beiden 3ern, wenn man sie über USB anschließt.

Das Fehlerbild bei den 3ern ist das gleiche wie ich es im Frühjahr hatte, bevor ich den Empfangspuffer vergrößert habe. Ich hatte daher auch erst auf sowas getippt, aber der Zero W läuft und läuft.

Ich werde heute wohl keine Debug SW mehr fertig kriegen, ich versuch's aber die Woche nochmal.

[bontango]

wart noch mit dem dem debug, hab da was gefunden, bau ich morgen mal ein.

beim pi zero (ohne W) muessen wir dann mal schauen, aber der verhält sich anders oder?

----

Der Raspberry Pi 3 nutzt für den GPIO-Port standardmäßig den UART1 (ttyS0), während die vorherigen Raspberry Pi-Modelle noch den UART0 dafür verwendeten. Der UART0 (ttyAMA0) wird beim Pi 3 durch das neu eingeführte Bluetooth-Modul softwaremäßig belegt. Der UART1 des Pi 3 mit Anhängigkeiten von CPU-Frequenz, CPU-Last, Temperatur und anderem ist für den Betrieb von Aufsteckmodulen jedoch häufig nicht stabil genug. Der Pi 3 muss daher zur Verwendung von einigen Aufsteckmodulen für den GPIO-Port, die über GPIO 14/15 kommunizieren so umkonfiguriert werden, dass der GPIO-Port wie bei den Vorgängermodellen wieder den UART0 einsetzt.

[Black Knight]

vor einer Stunde schrieb bontango:

beim pi zero (ohne W) muessen wir dann mal schauen, aber der verhält sich anders oder?

Ja komplett anders, der scheint Lisy gar nicht zu starten.

Das mit der falschen Clock könnte passen, denn im Prinzip funktioniert es ja, die Kommunikation gerät nur irgendwie aus dem Tritt.

[bontango]

Mit der Änderung starten meine PIs ( Zero, Zero-W, 3B ) jetzt einwandfrei.

Kannst du mit dem 'standard upadte.tgz' ausprobieren

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

[Black Knight]

Dafür gibt's den Daumen hoch 👍

Mit dem Update läuft alles wie am Schnürchen - sowohl auf den 3ern, als auch auf dem Zero ohne Wlan (den ich ja schon fast abgehakt hatte).

Da du gerade im Erfolgsrausch bist hätte ich noch eine Frage 

Ich tu mich etwas schwer damit, die vergrößerten seriellen Sende- Empfangspuffer nutzerfreundlich zu implementieren, da das eine interne Einstellung in einer Arduino Sub-sub-library ist.

Wenn ich die Library neu definiere und den Code in meine SW übernehme, dann gibt's immer Ärger, wenn sich was in einer der beteiligten Libraries ändert und meine Implementierung nicht mehr passt.

Wenn ich die Leute dagegen das Setting in der Library selbst ändern lasse, muss ich das für jede IDE und jedes Betriebssystem machen und wenn sich dann was ändert ... 🤪

Daher kam mir die Idee unsere API um eine rudimentäre Synchronisation zu ergänzen, wie wir das ja auch bei I2C vor hatten. Um das Ganze möglichst simpel und kompatibel zu MPF zu halten, hätte ich folgenden Vorschlag:

Da die Puffer ja nur bei Audioaufrufen volllaufen können, würde es reichen wenn Lisy nach jeden Audioaufruf einen 'get changed switches' (0x29) sendet und mit weiteren Befehlen so lange wartet bis die Antwort erfolgt ist.

Wäre das für dich ohne viel Aufwand möglich oder verlagern wir das Problem damit nur auf deine Seite, weil dann deine Sendepuffer überlaufen (der PinMame arbeitet ja weiter)?

Oder hast du noch eine andere Idee, wie wir potentielle Pufferüberläufe vermeiden können?

[bontango]

Eine Warteroutine kann ich einbauen, pinmame würde dann auch warten, läuft alles seriell!

Ich würde dann aber eher die Audioaufrufe 'blocking' machen ( auf positives Feedback warten) oder einen neuen Befehl einführen ( so was wie: get back when ready) als den get changed switches für etwas zu nehmen für das er nicht gebaut ist.  Das ist eindeutiger und ich muss auch nicht eventuell gemeldete switches verarbeiten.

[Black Knight]

vor 2 Stunden schrieb bontango:

Eine Warteroutine kann ich einbauen, pinmame würde dann auch warten, läuft alles seriell!

Kommt der PinMame nicht aus dem Tritt wenn man ihn mittendrin anhält?

vor 2 Stunden schrieb bontango:

oder einen neuen Befehl einführen ( so was wie: get back when ready)

Können wir auch machen. Dann würde Lisy nach einem Audioaufruf diesen 'get back when ready' Befehl senden und erst weiter machen, wenn der APC das bestätigt hat, korrekt?

[bontango]

Macht pinmame nichts mal zu warten, ich nutz dass z.B. um die Geschwindigkeit an das Original anzupassen.

vor 3 Minuten schrieb Black Knight:

Dann würde Lisy nach einem Audioaufruf diesen 'get back when ready' Befehl senden und erst weiter machen, wenn der APC das bestätigt hat, korrekt?

Genau, muessen uns jetzt nur auf den code für den Befehl einigen, ich würde etwas im 100er Bereich vorschlagen.

Rückgabewert 0 wenn OK, >0 wenn Error?

 

//general, parameter none
#define LISY_INIT               100     //init/reset LISY - return byte 0=OK, >0 Errornumber Errornumbers TBD
#define LISY_WATCHDOG           101     //watchdog - return byte 0=OK, >0 Errornumber Errornumbers TBD

#define LISY_BACK_WHEN_READY               102     //get back when ready, call blocks until answer received - if Arduino needs more time (e.g. for sound) - return byte 0=OK(continue), >0 Errornumber Errornumbers TBD

[Black Knight]

Befehl 102 ist mir Recht.

Ich wüsste zwar gerade keine Verwendung für eine Errornummer, aber vielleicht fällt uns da ja noch was ein.

[Black Knight]

Ich habe den Befehl mal eingebaut. Momentan gibt der einfach immer nur Null zurück.

[bontango]

Damit die Feiertage nicht langweilig werden habe ich für

 LISY_S_PLAY_SOUND       50      //play sound#

 LISY_S_PLAY_FILE        52      //play a file (in ./hardware_sounds) - option(1byte) + string 'filename'

das wait Kommando eingebaut (Version 5.27-2 )

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

frohes Fest!

Ralf

[Black Knight]

Läuft noch etwas holprig.

Ich habe dir mal das Log File geschickt.

Dir auch frohe Feiertage.

Frank

[bontango]

Hab da wohl vergessen dass der serielle Treiber noch nen eigenen Timeout hat.

Den hatte ich auf 100msec gesetzt. Jetzt loopt er 50 Mal so er in diesen timeout läuft,

warte hier also 5 Sekunden auf dich.

Probier bitte noch einmal, selbe tgz datei, ist jetzt (Version 5.27-3 )

[Black Knight]

Jawohl, das war's. Ich musste bei mir allerdings auch noch was fixen.

Dafür läuft's jetzt auch ohne dass ich den seriellen Empfangspuffer vergrößern muss. 👍

[bontango]

sehr schön, dann mach morgen ein 'APC release' 🙂

[bontango]

was kann ich denn zu deiner Version schreiben? Minimum 0.14 (#27) ?

[Black Knight]

Nee, da ich noch was fixen musste läuft das nur mit 0.21.

Ich stricke noch ein bisschen an der Doku und dann werde ich 0.21 auch releasen, damit das die neue Master-Version wird.

Gibt es bei dir eine spezielle Seite, die ich bezüglich Doku, SW Download u.s.w. verlinken sollte? Momentan verweise ich nämlich einfach nur auf lisy.dev

[bontango]

OK, dann verweise ich auf 0.21

Software ist hier: https://lisy.dev/version_5x.html

und LISY doku hier: https://lisy.dev/documentation.html

[Black Knight]

vor 22 Minuten schrieb bontango:

OK, dann verweise ich auf 0.21

Genau, aber bitte nicht direkt auf den 0.21 Branch verlinken, denn der verschwindet ja wenn ich ihn in den Master merge.

vor 24 Minuten schrieb bontango:

Software ist hier: https://lisy.dev/version_5x.html

OK, aber es gibt keinen extra APC Bereich oder sowas. Dann ist es vermutlich ganz gut einfach allgemein auf lisy.dev zu verweisen, denn damit werden auch zukünftige Updates gefunden.

[bontango]

ich habe mal ne APC Seite auf lisy.dev erstellt und dein Bild geklaut.

Am besten verweist Du darauf

https://lisy.dev/apc.html

 

[Black Knight]

Alles klar, mach' ich.

Möchtest du noch ein paar Zeilen zu den Lisy-Jumpern beim APC 3 schreiben oder soll ich das auf meine Seite packen?

Das die Debug-Optionen über Setting 4 (das nach der PinMame Spiel Nummer) gesteuert werden hattest du schon eingebaut, oder?

Dann nehme ich die ganzen einzelnen Option wie Debug-Switch und so nämlich raus; das verwirrt nur.

Hättest du sonst noch gerne was in der APC-Doku, das bisher noch fehlt?

[bontango]

Ja, im seriellen Modus sollte sich LISY alle Einstellungen vom APC holen.

Doku wäre ich dankbar wenn Du das übernehmen könntest 😁

APC Doku muss ich erst mal lesen 🙄 aber die Übersicht finde ich gut, war bislang immer

alles so 'zerstreut'. Eventuell die Übersicht sogar besser an den Anfang ?!

 

Gruesse

Ralf