Zum Inhalt springen

Arduino Pinball Controller


Black Knight

Empfohlene Beiträge

1 hour ago, jabdoa said:

Wann sendet der APC denn die Response?

Also ich bilde mir ein, mich genau an unsere Abmachung vom 27.Mai zu halten, d.h. er sendet eine Null, wenn der Bootvorgang abgeschlossen und er bereit ist Befehle zu empfangen.

Da er beim Bootvorgang auch alles initialisiert gibt es für den MPF doch eigentlich keinen Grund direkt danach nochmal einen Init zu senden. Damit wäre das Problem der beiden Nullen doch vom Tisch, oder?

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

  • Antworten 1,6Tsd
  • Erstellt
  • Letzte Antwort

Top-Benutzer in diesem Thema

  • Black Knight

    642

  • bontango

    438

  • Volley

    100

  • jabdoa

    97

Top-Benutzer in diesem Thema

Veröffentlichte Bilder

Hab' jetzt eingebaut, dass er bei 0x13 eine Null zurück gibt, das kann ich später noch mit meinen LED Settings abstimmen.

Jetzt passiert schon einiges, er fragt die Switches ab u.s.w. bleibt aber irgendwo bei den Displays hängen. Ich schicke euch das Log per PM, sonst müllen wir hier das ganze Forum zu.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Jo das können wir auch machen. Guck mal ob die neue Version geht. Sonst baue ich eine Option ein die beim Start von APC den 0x64 nicht sendet. Dann wartet er bis zu 10s und sendet dann den Reset falls die 0 nicht gekommen ist bis dann. Würde gehen oder?


Jan

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 2 Minuten schrieb jabdoa:

Sonst baue ich eine Option ein die beim Start von APC den 0x64 nicht sendet.

Oder einen Befehl für Init (Soft reset) und einen für Hardreset. Dann am Anfang Soft Reset -> 0x64 , 1 zurück wenn OK(Halte ich für sinnvoll)

und wenn der nicht greift, dann der Hardreset. Obwohl man den sicherer mit DTR auslösen kann, da in firmnware integriert!

Link zu diesem Kommentar
Auf anderen Seiten teilen

19 minutes ago, jabdoa said:

Guck mal ob die neue Version geht.

Ich kann nicht erkenn, dass der pip irgendwas macht, er sagt zu allem nur Requirement already satisfied, skipping upgrade

21 minutes ago, jabdoa said:

Dann wartet er bis zu 10s und sendet dann den Reset falls die 0 nicht gekommen ist bis dann.

Genau, so hatte ich das auch verstanden.

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 15 Minuten schrieb Black Knight:

Ich kann nicht erkenn, dass der pip irgendwas macht, er sagt zu allem nur Requirement already satisfied, skipping upgrade 

Sieht so aus als hätte ich das push falsch gemacht. Bin unterwegs. Mache ich später. Sorry.

Jan

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ich frage mich, ob wir 'Get Segment Display Count (0x06)',  'Get Segment Display Details (0x07)' und 'Get number of chars for display# (0x25)' nicht zusammenfassen sollten. Wir könnten einen String oder auch einfach nur ein Byte zurück geben:

0 -> 4x 6 Digit BCD Display (no Comma) + 1x 4 Digit BCD Display (Credit)
1 -> 4x 7 Digit BCD Display (with Comma) + 1x 4 Digit BCD Display (Credit)
2 -> 2x 7 Digit Alphanumerical Display + 2x 7 Digit Numerical Display + 1x 4 Digit Numerical (Credit)
3 -> 4x 7 Digit Alphanumerical + 1x 4 Digit Numerical (Credit)
4 -> 2x 7 Digit Alphanumerical Display + 2x 7 Digit Numerical Display
5 -> 2x 16 Digit Alphanumerical Display
6 -> 2x 16 Digit Alphanumerical Display + 1x 7 Digit Numerical
7 -> 2x 16 Digit Alphanumerical Display + 2x 7 Digit Numerical

Das wären die für uns relevaten Williams Displays von denen ich weiß, wobei Nr. 3 mein Selbstbau ist, den es von Williams gar nicht gibt. Diese Liste müsste man dann noch um die Gottliebs etc. ergänzen.

Jetzt mein Vorschlag für 'Set Segment Display 0-6 (0x1e - 0x24)'. Ich tendiere dazu, keinen String mehr zu senden, sondern eine feste Anzahl von Bytes je nachdem welches Display selektiert ist:

Set content of segment display d 0-6. Payload is a fixed amount of bytes depending on the display type. 

Numbering of the display is as follows:
0 -> 4 Digit Numerical (Credit) for display types 0 - 3
1 -> Player 1 or the upper row for display types 5 - 7 (2x 16 Digit Alphanumerical)
2 -> Player 2 or the lower row for display types 5 - 7 (2x 16 Digit Alphanumerical)
3 -> Player 3 or an additional 7 Digit Numerical Display for display types 6 and 7
4 -> Player 4 or an additional 7 Digit Numerical Display for display type 7

Commands to non existent displays are ignored.

Content encoding depends on the type of the display (from command 0x6). BCD type displays are accessed by sending BCD values consisting of 1 byte for each digit. If the BCD display features a Comma then Bit 7 of the corresponding byte must be set for it to be lit.

Non BCD displays are accessed by sending the segment patterns consisting of 2 bytes per digit according to the pattern d, c, b, a, e, f, g, Comma for the first byte and j, h, m, k, p, r , Dot, n for the second.

Hier wäre das Bild der Williams Segmentbelegung gut aufgehoben.

Lasst mal hören, was ihr davon haltet.

Bearbeitet von Black Knight
Link zu diesem Kommentar
Auf anderen Seiten teilen

 
vor 2 Stunden schrieb Black Knight:
vor 2 Stunden schrieb jabdoa:

Guck mal ob die neue Version geht.

Ich kann nicht erkenn, dass der pip irgendwas macht, er sagt zu allem nur Requirement already satisfied, skipping upgrade 

Das Release sollte jetzt da sein.

vor 30 Minuten schrieb Black Knight:

Ich frage mich, ob wir 'Get Segment Display Count (0x06)',  'Get Segment Display Details (0x07)' und 'Get number of chars for display# (0x25)' nicht zusammenfassen sollten. Wir könnten einen String oder auch einfach nur ein Byte zurück geben:

0 -> 4x 6 Digit BCD Display (no Comma) + 1x 4 Digit BCD Display (Credit)
1 -> 4x 7 Digit BCD Display (with Comma) + 1x 4 Digit BCD Display (Credit)
2 -> 2x 7 Digit Alphanumerical Display + 2x 7 Digit Numerical Display + 1x 4 Digit Numerical (Credit)
3 -> 4x 7 Digit Alphanumerical + 1x 4 Digit Numerical (Credit)
4 -> 2x 7 Digit Alphanumerical Display + 2x 7 Digit Numerical Display
5 -> 2x 16 Digit Alphanumerical Display
6 -> 2x 16 Digit Alphanumerical Display + 1x 7 Digit Numerical
7 -> 2x 16 Digit Alphanumerical Display + 2x 7 Digit Numerical

Generell würde ich das lieber generisch halten als es ohne Not spezifisch auf einzelne Maschinen zu bauen. Die paar Bytes während des Init kosten uns nichts.

Ich würde gerne 0x06 behalten weil das dann konsistent zu den anderen Commands ist (z.b. Switches, Coils etc). 0x07 und 0x25 können wir zusammenfassen.

Wir könnten 0x07 einen Parameter geben (Display Index). Zurück würde dann die Number of Chars + der Type des Displays kommen. Number of Chars ist ein Byte da 255 hier ausreichen sollte. Typ kann dann ein String bleiben. Wir könnten auch ein Byte nehmen aber eigentlich haben wir beim Init keine Notwendigkeit Zeichen zu sparen.

vor 32 Minuten schrieb Black Knight:

Jetzt mein Vorschlag für 'Set Segment Display 0-6 (0x1e - 0x24)'. Ich tendiere dazu, keinen String mehr zu senden, sondern eine feste Anzahl von Bytes je nachdem welches Display selektiert ist:

Set content of segment display d 0-6. Payload is a fixed amount of bytes depending on the display type. 

Numbering of the display is as follows:
0 -> 4 Digit Numerical (Credit) for display types 0 - 3
1 -> Player 1 or the upper row for display types 5 - 7 (2x 16 Digit Alphanumerical)
2 -> Player 2 or the lower row for display types 5 - 7 (2x 16 Digit Alphanumerical)
3 -> Player 3 or an additional 7 Digit Numerical Display for display types 6 and 7
4 -> Player 4 or an additional 7 Digit Numerical Display for display type 7

Wenn wir den Command anfassen würde ich nur einen Command machen 0x1e und als ersten Parameter den Display Index mitgeben. Dann können es später auch mehr Displays werden und wir haben Commandnummern frei. Danach würde ich dann ein Längenbyte einbauen und dann den Payload. String ist bei binarkodierten Daten in der Tat etwas schwer. Länge sollten wir uns aber gönnen sonst gibt das später nur böse Overflows.

 

Jan

Link zu diesem Kommentar
Auf anderen Seiten teilen

1 hour ago, jabdoa said:

Das Release sollte jetzt da sein.

Jo, er läuft 👍

Keine Fehlermeldungen und kein Reset mehr am Anfang. Laut Log hat er, bis ich ihn abgewürgt habe, brav den Befehl 'Get changed switches (0x29)' gesendet und immer 127 zurück bekommen, da ich keine Schalter betätigt habe.

Was mir noch aufgefallen ist:

- Er startet seine Abfrage aller Schalter am Anfang bei Schalter 0, den gibt es bei Williams aber nicht.

- Du hast in deinem Beispielconfig den Befehl 'Text to speech' benutzt, der läuft bei mir allerdings ins Leere. Ich wüsste auch nicht, wie ich das machen sollte.

Aber zusammengefasst scheint es zu klappen, d.h. ich muss jetzt mal lernen, wie das mit den Config-Files beim MPF funktioniert und wir müssen nochmal an das Displayprotokoll ran.

2 hours ago, jabdoa said:

Generell würde ich das lieber generisch halten als es ohne Not spezifisch auf einzelne Maschinen zu bauen.

Das hat halt Vor- und Nachteile. Sicherlich wäre ein generisches System das alle Eventualitäten abdeckt optimal, wenn aber ein Fall auftaucht der nicht abgedeckt ist, kann das unangenehm werden. Es gibt z.B. Bally Flipper aus den 80ern, die ganz andere Segmente haben (so 'ne Art Spar-Alphanumerisch) und wenn unser generisches System dafür nicht vorbereitet ist und irgendwer so'n Display ansteuern will dann sind wir aufgeschmissen.

Wenn man dagegen jedem Displaytyp eine Nummer zuordnet muss man jeden neuen Typ einmal definieren, dafür ist danach aber auch allen klar was Sache ist und dass ein Übertragungsmodus existiert, der auf dieses Display zugeschnitten ist.

Letztendlich läuft es darauf hinaus, ob wir uns zutrauen ein System zu entwerfen, dass generisch genug ist um alles abzudecken, ansonsten wären wir vermutlich mit einer Typennummer besser dran. Ich werde da mal darüber nachdenken.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Wenn wir ein generisches System zur Displayansteuerung haben wollen, dann sollten wir erst mal sammeln, mit was für Displays wir es zu tun haben.

Ich habe oben ja schon mal zusammengefasst, welche Williams Segmentdisplays mir bekannt sind, was fällt euch denn noch ein?

Link zu diesem Kommentar
Auf anderen Seiten teilen

APC muss ja nicht alle Displays unterstützen die das Protokoll unterstützt. Aber wenn LISY universal bleibt können andere Hardware Lösungen das später.

 

Jan

Link zu diesem Kommentar
Auf anderen Seiten teilen

Das stimmt, aber wenn wir ein generisches System zur Definition der Displays haben wollen, dann muss dieses auf alle möglichen Displayarten vorbereitet sein.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hab eben die Displays in Betrieb genommen, läuft 😃 sogar das Nachglimmen ist weg. Musste der Jumper evtl. für dein Display anders stehen?

In die Displaydiskussion bzgl. Protokoll klinke ich mich nächste Woche ein, bin jetzt ein paar Tage weg.

Link zu diesem Kommentar
Auf anderen Seiten teilen

35 minutes ago, bontango said:

Hab eben die Displays in Betrieb genommen, läuft

Super, denk dran die Displayeinstellungen jetzt auf 4Alpha + Credit zu ändern, sonst steuert er die Displays 3 und 4 als Numerische an.

36 minutes ago, bontango said:

Musste der Jumper evtl. für dein Display anders stehen?

Eigentlich nicht, vielleicht doch eine wackelige Lötstelle?

Link zu diesem Kommentar
Auf anderen Seiten teilen

On 6/16/2019 at 7:01 PM, jabdoa said:

Ich würde gerne 0x06 behalten weil das dann konsistent zu den anderen Commands ist (z.b. Switches, Coils etc). 0x07 und 0x25 können wir zusammenfassen.

OK, das würde bedeuten, er fragt mit 0x06 die Anzahl der Displays ab und bestimmt dann mit 0x07 den Typ jedes Displays, korrekt?

On 6/16/2019 at 7:01 PM, jabdoa said:

Wir könnten 0x07 einen Parameter geben (Display Index). Zurück würde dann die Number of Chars + der Type des Displays kommen. Number of Chars ist ein Byte da 255 hier ausreichen sollte. Typ kann dann ein String bleiben. Wir könnten auch ein Byte nehmen aber eigentlich haben wir beim Init keine Notwendigkeit Zeichen zu sparen.

Ich würde wieder ein Byte bevorzugen, weil's einfacher zu handhaben ist und ich den Mehrwert eines Strings nicht sehe, aber für dich schicke ich auch Strings raus.😉

Auf Basis meiner oben genannten Williams-Displays fallen mir folgende Typendefinitionen ein. Ich schreibe mal einfach Byte und String, wir können uns ja noch entscheiden, was wir nehmen:

1 -> BCD7 (BCD Code für 7 Segment Displays -> ohne Komma)
2 -> BCD8 (BCD Code für 8 Segment Displays -> mit Komma)
3 -> SEG7 (7 Segment Displays + Komma mit direkter Ansteuerung -> Segmentmuster)
4 -> SEG14 (14 Segment Displays + Punkt + Komma mit direkter Ansteuerung -> Segmentmuster)

Angenommen, wir hätten was ich oben als Displaytyp 2 bezeichnet habe, '2x 7 Digit Alphanumerical Display + 2x 7 Digit Numerical Display + 1x 4 Digit Numerical (Credit)' dann würde die Initialisierung also folgendermaßen ablaufen:

MPF sendet 0x06 und bekommt eine 5 zurück.

Dann fragt er mit 0x07 + 0 die Daten von Display 0 ab und bekommt als Antwort 4 + 3 (bzw. SEG7).

Da er es mit 5 Displays zu tun hat wiederholt er das so lange, bis er für alle eine Definition bekommen hat, also in diesem Fall sendet er 0x07 + 1 für Display 1 und bekommt 7 + 4 (SEG14), die gleiche Antwort gibt's auf 0x07 +2. Dann kommt 0x07 + 3 und als Antwort kommt 7 + 3 (SEG7), dito für 0x07 +4.

Das sollte doch passen, oder?

Link zu diesem Kommentar
Auf anderen Seiten teilen

Das klingt sehr gut. Gefällt mir. Bytes sind gebongt. Ich update das dann in der Referenz und implementier es in MPF über das Wochenende.

 

Jan

Link zu diesem Kommentar
Auf anderen Seiten teilen

49 minutes ago, jabdoa said:

Ich update das dann in der Referenz und implementier es in MPF über das Wochenende.

Vielleicht sollten wir noch auf Ralfs Meinung warten, bevor wir anfangen zu implementieren?

Ich habe übrigens das MPF Tutorium Schritt 11 mit APC am Laufen. Ich habe nur noch nicht kapiert, wie ich meine Flipperspulen aktivieren kann. Die ganzen Flipper-Devices scheinen immer auch die Flipperknöpfe abfragen zu wollen, dabei muss ich ja einfach nur eine Spule dauerhaft einschalten. Hast du da vielleicht einen Tipp für mich?

Link zu diesem Kommentar
Auf anderen Seiten teilen

Endlich ein bisschen Zeit gehabt.  "Step 1" klappt - "Houston, we have sound".  Hoffentlich Sonntag geht es weiter :) 

Link zu diesem Kommentar
Auf anderen Seiten teilen

13 hours ago, Snux said:

Endlich ein bisschen Zeit gehabt.  "Step 1" klappt - "Houston, we have sound".

Sehr gut. Es war so ruhig bei dir, da habe ich schon gedacht, du hättest beim SMD löten vor Wut in die Platine gebissen.😉

Denk dran, den Stecker für den Lautstärkeregler abzuziehen, wenn du die digitale Lautstärkeeinstellung nutzt, sonst klappt das nicht richtig.

Vielleicht hast du ja gesehen, dass wir gerade das USB-Protokoll für die Displays definieren. Weißt du, wie der PinMame bei Sys11 die Displaydaten überträgt? Es gibt ja auch Spiele, die 'Effekte' nutzen, also nicht unbedingt echte Buchstaben anzeigen, also muss der PinMame doch die Segmentdaten 'roh' übertragen, oder?

Das wäre dann sowas wie: 14 Segmente + Punkt + Komma = 16Bit = 2Byte.

Beim Sound könnten wir deine Hilfe auch gebrauchen, der Ralf hatte dazu einen eigenen neuen Thread gestartet.

Link zu diesem Kommentar
Auf anderen Seiten teilen

@jabdoa Hallo Jan, kann es sein, dass die HW rules noch nicht im MPF integriert sind? Ich bekomme den Fehler:

AssertionError: Hardware rules are not support in LISY.

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 53 Minuten schrieb Black Knight:

@jabdoa Hallo Jan, kann es sein, dass die HW rules noch nicht im MPF integriert sind? Ich bekomme den Fehler:


AssertionError: Hardware rules are not support in LISY.

 

Mache ich am Wochenende.

 

Jan

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 3 Stunden schrieb Black Knight:

habe ich schon gedacht, du hättest beim SMD löten vor Wut in die Platine gebissen.😉

War knapp......

vor 3 Stunden schrieb Black Knight:

also muss der PinMame doch die Segmentdaten 'roh' übertragen, oder?

Yup.  Und ist UINT16, also doch 2 bytes / Stelle.

Aber jetzt wird's zu kompliziert fuer mein Deutsch, also ein bisschen Englisch...

This is the segment display handler in pinmame, routine is updateDisplay

https://sourceforge.net/p/pinmame/code/HEAD/tree/branches/proc/src/wpc/core.c#l936

Normally, pinmame displays the segments on the computer screen.  For P-ROC we add some code at screen drawing time to capture the segment data.   At the end of updateDisplay we have 2 arrays of UINT16 called proc_top (for the first 16 displays) and proc_bottom (for the second 16 displays).  Depending on the machine, some of the positions are unused.  We then call procUpdateAlphaDisplay here

https://sourceforge.net/p/pinmame/code/HEAD/tree/branches/proc/src/wpc/core.c#l1047

And the P-ROC will push out the raw data direct to the display.

https://sourceforge.net/p/pinmame/code/HEAD/tree/branches/proc/src/p-roc/display.cpp#l405

I do not know exactly the format of the raw data, but there is a routine in the P-ROC code for displaying 2 lines of "text", it converts to the raw data and then called procUpdateAlphaDisplay.  That routine is here...

https://sourceforge.net/p/pinmame/code/HEAD/tree/branches/proc/src/p-roc/display.cpp#l311

I think if LISY-pinmame does a similar kind of thing like P-ROC it should be easy to get the data I think.

 

Link zu diesem Kommentar
Auf anderen Seiten teilen

On 6/19/2019 at 8:26 PM, jabdoa said:

Vermutlich brauchst du type: driver für APC.

Jo, klappt. Ich kann jetzt schon fast sowas ähnliches wie spielen.

4 hours ago, Snux said:

I think if LISY-pinmame does a similar kind of thing like P-ROC it should be easy to get the data I think

Danke für die Info. Ich hoffe, das hilft dem Ralf, wenn er wieder da ist.

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