Zum Inhalt springen

Entwicklung APC 3.0 -> Lisy_APC


Black Knight

Empfohlene Beiträge

vor 3 Minuten schrieb Black Knight:

Wenn man jetzt wüsste, ob die Leute bei sowas wirklich Probleme beim löten haben oder nur jammern und es dann doch hin kriegen.

Also ich gehöre in die 'Jammern und dann doch hinkriegen' Kategorie, aber sehr viele haben definitiv Probleme mit SMD!

Erst einmal ist der Abschreckungsfaktor recht hoch, da trauen sich viele erst gar nicht ran, und wenn doch nicht immer mit Erfolg,

ich habe da schon ein paar 'Resultate' gesehen 😬

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • Antworten 206
  • Erstellt
  • Letzte Antwort

Top-Benutzer in diesem Thema

  • Black Knight

    111

  • bontango

    95

  • Volley

    1

Top-Benutzer in diesem Thema

Veröffentlichte Bilder

Die Platzierung ist jetzt soweit fertig. Das sollte passen.

Ich mache jetzt erst mal die Standardversion, das ist nicht so besonders viel Arbeit. Danach schau ich mir dann an was man ändern muss, um es bestücken zu lassen und ob ich die Lust habe das alles zu machen.

Lisy_APC.pdf

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 4 Wochen später...

Ich habe gemäß folgender Tabelle auch mal den ersten Entwurf der Lisy Menüs eingebaut. Das kannst du dir also theoretisch auch an deinem Comet ansehen.

Die für Lisy relevanten Settings stehen unter 'Game settings in USBcontrol mode'

Lesen könnte Lisy diese Settings dann mit dem neuen 0x40 Befehl, wobei die APC Settings in Gruppe 0 stehen und die für USBcontrol in Gruppe 1.

Beispiel: Angenommen, Lisy möchte das Setting für den Lisy Mode lesen, was laut Tabelle die Nummer 3 in der USBcontrol Gruppe ist. Da die Nummerierung der Settings im Code mit 0 startet (und nicht wie in der Tabelle mit 1) müsste Lisy

0x40 1 2 senden, also das dritte Setting aus Gruppe 1 (USBcontrol).

Die Antworten starten auch mit 0, also stünde 0 für den PinMame Mode, 1 für MPF u.s.w.

Schau mal bitte, ob dir das so gefällt oder ob du gerne noch was geändert bzw. ergänzt hättest.

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 4 Wochen später...
Am 14.6.2020 um 16:20 schrieb Black Knight:

Beispiel: Angenommen, Lisy möchte das Setting für den Lisy Mode lesen, was laut Tabelle die Nummer 3 in der USBcontrol Gruppe ist. Da die Nummerierung der Settings im Code mit 0 startet (und nicht wie in der Tabelle mit 1) müsste Lisy

Ich habe das übrigens so geändert, dass die Nummerierung der Settings im Code jetzt genauso ist, wie in der Tabelle und im Display. Ich denke die Leute sind in der Lage von Null aus zu zählen und so ist es jetzt wenigstens überall konsistent.

Die Tabelle ist auch entsprechend angepasst.

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 1 Monat später...

@bontango Jan hatte im Pinside Forum gefragt, ob MPF auch eine I2C Unterstützung für die 3.0 HW haben sollte. Ich war bisher davon ausgegangen, dass MPF auf dem Pi unter Lisy Kontrolle laufen wird und sich daher nicht selbst um die Kommunikationsschnittstelle kümmern muss.

Wie ist denn deine Meinung dazu?

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 5 Minuten schrieb Black Knight:

Wie ist denn deine Meinung dazu?

LISY ist bei MPF 'aussen vor'.

Bei meiner LISY Hardware nutze ich zur Kommunikation mit MPF das Netzwerk via localhost, da läuft ja alles auf dem selben system (PI),

auf dem dann ein kleines Programm 'mpfserver' als Schnittstelle zur LISY Hardware installiert ist.

Der mpfserver empfängt via localhost die API Befehle von MPF und setzt sie in LISY sepizifische I2C Befehle um.

Also: MPF < - Netzwerk- > 'mpfserver' <- I2C - > LISY Hardware

Ich hatte angenommen du hast auch so etwas ähnliches wie meinen mpfserver laufen?!

Für APC 3.0 wäre es da IMHO schon sinnvoll auch I2C zu unterstützen.

Bei Dir dann also in etwa so:  MPF < - I2C - > 'APC mpfserver' <- APC interne Kommunikation - > APC Hardware

Im Moment nehme ich an dass du in der config.yaml die USB serial connection eingestellt hast, was dann derzeit so aussehen sollte

MPF < - USB serial - > 'APC mpfserver' <- APC interne Kommunikation - > APC Hardware

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 6 Stunden schrieb bontango:

Bei meiner LISY Hardware nutze ich zur Kommunikation mit MPF das Netzwerk via localhost, da läuft ja alles auf dem selben system (PI),

Bin mir nicht sicher, ob ich dich richtig verstanden habe, aber es geht nur um den Fall, dass MPF auch auf dem Pi läuft. Der andere Fall, bei dem MPF auf einem PC läuft und dieser über USB mit dem APC verbunden ist, wird beim 3.0 genauso funktionieren wie bei der jetzigen HW.

Die Frage ist jetzt also, wie sich Lisy und MPF den Pi teilen und wie man zwischen beiden umschalte könnte. Schön wäre ja z.B. wenn man am Flipper im Menü zwischen PinMame und MPF umschalten könnte, die beide auf dem Pi laufen. Dazu müsste aber jemand auf dem Pi den entsprechenden Befehl entgegen nehmen und bei Bedarf das eine oder das andere starten. Ich bin bisher davon ausgegangen, dass Lisy diese Aufgabe übernimmt, aber was weiß ich schon vom Pi ...

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 16 Stunden schrieb Black Knight:

aber was weiß ich schon vom Pi ..

Der PI ist ja auch nur ein  Rechner auf dem Linux läuft, in sofern kannst Du das 1:1 übertragen.

Bei den LISYs wird das über die DIP Schalter geregelt, beim boot wird dann entweder LISY oder MPF + mpfserver gestartet.

Könnten wir bei der integrierten LISY dann auch über das Menu regeln, Umschaltung 'on the fly' geht dann sicher auch

hab ich bislang aber noch nicht gemacht.

Wann kommen denn die neuen APCs ?

Link zu diesem Kommentar
Auf anderen Seiten teilen

@jabdoa Ich bin mir gar nicht sicher, ob du diesen Thread kennst, daher dies mal als Hinweis.

vor 2 Stunden schrieb bontango:

Wann kommen denn die neuen APCs ?

Die sind wohl gerade in Hong Kong auf dem Weg zum Flughafen. Ich habe diesmal DHL Express Versand genommen, also sollten die in einer Woche hier sein.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Am 7.9.2020 um 09:31 schrieb bontango:

Es sei denn Du hast die von JCL angebotene Variante inkl. Zoll genommen ?!

Habe ich leider nicht. Ich dachte das wäre ein Standardverfahren bei dem ich jetzt einfach eine Rechnung vom Zoll kriege, aber so einfach scheint es nicht zu sein. Stattdessen habe ich jetzt eine Mail von Jlcpcp gekriegt, dass der Zoll noch Unterlagen bräuchte und ich mich mit DHL in Verbindung setzen sollte. Also habe ich Vorgestern eine Supportanfrage an DHL gestellt und gefragt was denn noch fehlt und wo ich es hin schicken soll - bisher ohne Antwort.

Bisher habe ich den Eindruck, dass DHL Express ein ziemlicher Mist ist.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hatte das früher schon ein  paar Mal, normalerweise wollen die einen Nachweis über den Kaufpreis. Bildschirmfoto von der Paypal Überweisung hat es da immer getan. Ging bei mir online, hatte eine SMS mit nem Link zu einem Onlineportal. Da ist wichtig dass deine Handynummer stimmt die Du bei JCL angegeben hast.

Gebühren ( plus 10 Euro Bearbeitungsgebühr ) werden dann bei Lieferung fällig. Wie lang das dauert ist denke ich ist Tagesform abhängig. 1-4 Wochen bei mir.

Bin heilfroh dass es die Europaket Variante gibt.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Mittlerweile ist auch die Mail da, die nach der Paypal-Rechnung verlangt. Habe ich jetzt geschickt, mal sehen wie lange es nun noch dauert.

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 3 Wochen später...

Soweit so gut - Die ersten Test sind durch und bisher tut der APC 3.0 alles, was der Vorgänger auch getan hat.

Als nächstes muss jetzt der Raspi drauf und Lisy gestartet werden. Soll ich das ganz normale Lisy Image 5.26-28 runterladen oder gibt es was spezielles für den APC mit I2C und so?

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ich denk mal wir sollten mit I2C loslegen, dafür wäre es natürlich gut wenn ich eine neue APC Platine hätte. Da das FPGA Virus immer noch grassiert ( https://lisy.dev/fpga-mpus.html )  ist es mit Zeit zum löten knapp. Was müsste ich denn alles auf die Platine löten damit ein Schreibtischtest möglich ist?

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 30 Minuten schrieb bontango:

Da das FPGA Virus immer noch grassiert

Das nimmt ja beängstigende Ausmaße an. Ich hoffe, du bist damit in Quarantäne. 😉

vor 35 Minuten schrieb bontango:

Was müsste ich denn alles auf die Platine löten damit ein Schreibtischtest möglich ist?

Der Schreibtischtest lief bei dir ja schon (siehe Posts vom Mai), d.h. das Ding muss jetzt in den Flipper und sich in der Praxis bewähren.

Will sagen: dein 3.0 Board liegt hier und du kannst es natürlich jederzeit haben, aber da du momentan ja wenig Zeit hast sollte es eigentlich ausreichen wenn ich die weiteren Tests übernehme. Als einzige Änderung zu deiner I2C fähigen SW Version müsste eine Alternative zu den DIP Schaltern her, da es die beim APC 3.0 ja nicht mehr gibt.

Ich hatte ja mal diese Tabelle als Vorschlag für die USB und Lisy relevanten Settings erstellt, aber wir könnten natürlich auch zunächst mal eine Sparversion implementieren. Ich denke mal zu Setting Nr.3 (PinMame Game) gibt's keine Alternative, aber die Optionen und Debug Jumper könnten wir ja auch einfacher einbauen. Mein Vorschlag wäre also wie folgt:

- Setting 2 -> Alle Options DIP Schalter als Wert von 0 - 255

- Setting 3 -> Alle Game DIP Schalter (S2) als Wert von 0 - 255 (Nummer des PinMame Spiels)

- Settings 4 -> Alle Debug Jumper K1, K2 und K3 als Wert von 0 - 255 (K1 stellt dann die Bits 0-4, K2 Bit 5 / 6 und K3 ist Bit 7)

Für deinen Code hieße das: wenn du Kontakt über I2C kriegst, dann fragst du nicht die DIP Schalter ab, sondern schickst

0x40 1 2

und fragst damit Setting Nr. 2 aus Gruppe 1 (USBcontrol) ab und bekommst als Antwort ein Byte, dass den Wert der Options DIP Schalter als Zahlenwert ausdrückt. Die Nummer des PinMame Spiels bekommst du mit

0x40 1 3

u.s.w.

Ich denke, das wäre zunächst mal das einfachste, ändern können wir es hinterher ja immer noch.

Was denkst du, ist das OK für dich?

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 2 Stunden schrieb bontango:

Aktuelle APC Software bekomme ich auf deinem Github?

Im Prinzip ist 0.14 der letzte Stand, aber momentan sind die Settings noch so eingebaut, wie sie in der Tabelle stehen. Für die vereinfachte Version müsste ich die Settings 2 und 4 heute Nachmittag vorübergehend in Zahlenwerte ändern.

Ich melde mich wenn das erledigt ist.

Link zu diesem Kommentar
Auf anderen Seiten teilen

So ist in 0.14 jetzt geändert. Ich habe das Setting 4 auch in 'Debug Select' umbenannt.

Das mit den Settings ist ja sowieso alles nur vorläufig, wenn du da also gerne etwas geändert hättest dann lass es mich wissen.

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • 3 Wochen später...

Habe mich mal ein bisschen mit unseren I2C Problemen beschäftigt und sehe die Sache wie folgt:

Wenn der Master eine Antwort des Slave anfordert, dann muss dieser normalerweise sofort antworten. Daher ruft die Arduino I2C Library in diesem Fall eine Interruptroutine auf, innerhalb derer die Antwort geschrieben werden muss.

Das ist ziemlich blöd für mich, da meine APC SW ja noch einigen anderen Kram zu tun hat und die Antwort daher möglicherweise ein paar µs länger braucht. Eigentlich hatte ich gehofft, dass die Library das sogenannte  'Clock Stretching' nutzen würde - dann blockiert der Slave einfach die Clockleitung, um dem Master zu signalisieren, dass er mehr Zeit für die Antwort braucht. Daher wollte ich den Interrupt nur nutzen um ein Flag zu setzen und damit zu signalisieren das eine Antwort erwartet wird, also sowas wie:

#include <Wire.h>

bool RequestReceived = false;

void setup()
{
  Wire1.begin(68);                // join i2c bus with address #2
  Wire1.onRequest(requestEvent); // register event
}

void loop()
{
  if (RequestReceived) {           // write data if flag is set
    const byte Text[5] = {65, 80 , 67, 0, 178};
    static byte i;
    Wire1.write(Text[i]);
    i++;
    RequestReceived = false;
}}

// function that executes whenever data is requested by master
// this function is registered as an event, see setup()
void requestEvent()
{
  RequestReceived = true;
}

Das funktioniert aber leider nicht, da die Library einfach irgendwas anderes sendet wenn innerhalb der onRequest-Routine kein Schreibbefehl erfolgt. Jetzt könnte ich versuchen, einfach alles innerhalb der Interrupt-Routine zu erledigen und zu hoffen, dass die Library so lange clock stretching macht, bis ich damit fertig bin. Allerdings hätte ich dann eine große Menge Code im Interrupt, der irgendwann asynchron ausgeführt wird und das könnte mein ganzes System durcheinander bringen. Das basiert nämlich darauf, dass ich einen Hardware-Interrupt habe, der die HW des Flippers steuert und der sicher jede 1ms läuft. Alles andere läuft außerhalb dieses Interrupts und teilt sich die übrige Prozessorzeit.

Soweit zum Problem. Wie können wir das nun lösen?

Mein Vorschlag wäre, dass der Master (Lisy), wenn er eine Antwort erwartet, zunächst immer nur ein Status-Byte abfragt. Durch dieses könnte der Slave (APC) ihm anzeigen, wie viele Bytes sich im Sendepuffer befinden. Ist die Antwort Null, dann ist der APC noch nicht soweit und Lisy müsste bei nächster Gelegenheit erneut fragen. Andernfalls weiß Lisy durch die Antwort gleich, wie viele Bytes es zu erwarten hat und kann direkt die entsprechende Anzahl anfordern.

Ich wäre sogar dafür, auch bei Befehlen die keine Antwort des APC erfordern eine entsprechende Anfrage zu machen, bevor Lisy den nächsten Befehl sendet (da könnte man als Antwort 0xff oder sowas zurückschicken wenn das Kommando abgearbeitet wurde). Dadurch könnten wir sicherstellen, dass Lisy kein neues Kommando sendet bevor das alte abgearbeitet ist und dadurch das Problem des nur 32 Byte großen Empfangspuffers der Arduino Library umgehen.

Das würde sicherlich für mehr Datenaufkommen auf dem I2C Bus sorgen, aber wir könnten die Clockfrequenz ja von 100KHz eine Stufe hoch setzen. Der Vorteil wäre aber, dass Lisy immer die volle Übersicht hätte, was gerade passiert und ein Puffer-Überlauf auf APC-Seite nicht mehr passieren kann.

So, das war jetzt ein mittlerer Roman. Wie ist denn deine Meinung dazu? Ich bin mir bewusst, dass das auf Lisy-Seite etwas Arbeit verursacht, aber ich halte es für eine sichere Lösung. Denn wenn jemand z.B. eine SD-Karte mit sehr langen Dateiöffnungszeiten verwendet, dann kann bei unserer USB-Lösung theoretisch immer noch der Empfangspuffer des APC überlaufen und er hätte keine Möglichkeit Lisy davon zu informieren - das wäre mit meinem Vorschlag ausgeschlossen.

Aber vielleicht hast du ja auch noch eine bessere Idee ...

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 1 Stunde schrieb Black Knight:

So, das war jetzt ein mittlerer Roman. Wie ist denn deine Meinung dazu

Ich denke das Umschreiben ist keine grosse Sache. Beim derzeitigen Protokoll gefällt mir eh nicht dass

keine Bestätigung erwartet wird. Das führt immer dann zu Problemen wenn die Kommunikation 'aus dem sync' geht

dann hat mein keine Möglichkeit mehr in den sync zu kommen und unvorhersehbare Dinge können passieren.

Ich würde daher eher immer eine Antwort schicken lassen auf die der Master dann wartet. In der ersten Version als

'blocking' d.h. der Master wartet (recht lange) auf die richtige Antwort und macht nichts parallel. Das wäre wesentlich für mich wesentlich einfacher zu implementieren, muessen dann nur schauen ob es 'ruckelt'

Ich überlege mir mal was, eventuell schon Heute Abend, Pokern fällt ja wegen Corona aus 😐

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor einer Stunde schrieb bontango:

Beim derzeitigen Protokoll gefällt mir eh nicht dass keine Bestätigung erwartet wird. Das führt immer dann zu Problemen wenn die Kommunikation 'aus dem sync' geht dann hat mein keine Möglichkeit mehr in den sync zu kommen und unvorhersehbare Dinge können passieren.

Ja, das ist auch meine Befürchtung.

vor einer Stunde schrieb bontango:

In der ersten Version als 'blocking' d.h. der Master wartet (recht lange) auf die richtige Antwort und macht nichts parallel. Das wäre wesentlich für mich wesentlich einfacher zu implementieren, muessen dann nur schauen ob es 'ruckelt'

Das könnte bei Sound Kommandos Probleme geben, denn das Öffnen eines Files kann da wohl leicht 10ms und mehr dauern. Aber lass es uns probieren, vielleicht haben wir ja Glück.

Übrigens ...  mit deiner geänderten getDIPfromAPC und meiner ursprünglichen Version 'Sel14 added for HW_ext' funktioniert es jetzt einwandfrei 🤪

Aber ich bin auch der Meinung, dass wir es durch eine Synchronisierung stabiler machen können.

vor 1 Stunde schrieb bontango:

Ich überlege mir mal was, eventuell schon Heute Abend, Pokern fällt ja wegen Corona aus 😐

Ja, langsam nervt's. Ich hatte ja auch gehofft, dass wir uns bald mal in Volleys Halle treffen könnten aber das wird ja wohl erst mal nix.

Bin gespannt, was du ausbrütest.

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor einer Stunde schrieb Black Knight:

Übrigens ...  mit deiner geänderten getDIPfromAPC und meiner ursprünglichen Version 'Sel14 added for HW_ext' funktioniert es jetzt einwandfrei 

Ist das die aktuelle 14er Github Version? Dann würde ich die nochmal runterladen um meinen Startscript zu testen.

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 43 Minuten schrieb bontango:

Ist das die aktuelle 14er Github Version? Dann würde ich die nochmal runterladen um meinen Startscript zu testen.

Ja, genau. Der Kommentar dazu ist Revert to 'Sel14 added for HW_ext'.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Erstelle ein Benutzerkonto oder melde Dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde Dich hier an.

Jetzt anmelden

×
×
  • Neu erstellen...

Wichtige Information

Datenschutzerklärung und Registrierungsbedingungen