Jump to content

Recommended Posts

Am 15.6.2019 um 19:41 schrieb Black Knight:

Wir hatten ja schon gesagt, dass die Segmentdaten in zwei Bytes übertragen werden sollten (14 Segment + Komma + Punkt) allerdings müssten wir uns noch auf die genaue Belegung der zwei Bytes einigen. Mein Vorschlag wäre, einfach die APC-Belegung zu verwenden, damit würden wir uns die Arbeit ersparen jeden Buchstaben in Segmenten abzubilden, da ich das vor ein paar Jahren schon gemacht habe. Die Belegung wäre dann d, c, b, a, e, f, g, Komma für's erste Byte und j, h, m, k, p, r , Punkt, n für's zweite. Ich habe mal ein Bild angehängt, wie die Segmente bei Williams zugeordnet sind.

 

Jetzt müssen wir ne Münze werfen wer es anpasst 😁 oder Jan entscheidet. Pinmame speichert bzw. schickt es so:

image.png

Link to post
Share on other sites
  • Replies 1.3k
  • Created
  • Last Reply

Top Posters In This Topic

bzgl. der Ansteuerung, hatte Ihr ja vor dass MPF/LISY-Pinmame abfragt was denn am APC dranhängt und dann entsprechend formatiert schickt,

macht aus Sicht von MPF wohl auch Sinn , aber ich stell mich jetzt mal auf den 'pinmame' Standpunkt:

Da gibt das laufende Game ja vor was am anderen Ende zu sein hat ( z.b. 5 * nummerisch für Comet, bzw. 2 * Alpha plus ... für z.B. Pinbot),  ich würde dem

APC lieber sagen: ich hab vor Dir zukünftig Format x für Display n, und Format Y für Display m, zu schicken sieh mal zu wie Du das vernünftig darstellst 😉

Das mach er ja beim Comet derzeit ja auch, ich schick ihm ASCII und er stellt es auf alphanumerischem Display sauber dar

d.h ich würde lieber einen Befehl 'Display format for Display #n' -> code 0x25 plus das Byte für BCD7, BCD8, .. haben und der APC sagt dann 'kann ich machen', 'kann ich machen aber nicht alles' ( z.B. bei Buchstaben auf rein numerischen Displays) oder' geht nicht'. Bei 'geht nicht' gibt der Client dann auf oder schickt ein anderes format und formatiert notgedrungen selbst.

Die Krönung wär noch ne Variante 'ASCII', dann könnte ich am Anfang, bevor Pinmame läuft, meine LISY Bootmeldung bequem ausgeben lassen

Man könnte auch beide Varianten implementieren, was meint Ihr?

 

Link to post
Share on other sites

Hallo Ralf,

aus PinMame Sicht hast du absolut Recht, aus Lisy Sicht kann das schon wieder anders aussehen.

Wie ich ja schon geschrieben habe, ist der APC für neue Homebrew Flipper meiner Meinung nach nur begrenzt geeignet, da zu sehr auf die alte Technik zugeschnitten. Sowas würde ich eher auf Mini Lisy aufbauen und dezentral kleine Steuerplatinen über USB anschließen (da könnte man natürlich APC Teile als Vorlage nehmen). Damit wäre es für Lisy aber günstiger, wenn wir das Displayprotokoll nach unserem Vorschlag implementieren, da auch Lisy sich dann nach den Displays der Zielmaschine richten muss.

Wenn ihr euch dafür entscheidet, wären Befehle wie WriteASCII, WriteBDC oder WriteSegements für mich aber auch vollkommen OK, da es sie bei mir intern sowieso schon gibt. Dann haben wir natürlich voraussichtlich keinen einheitlichen Standard mehr, der immer anwendbar ist.

Bei den Segmentdaten bin ich auch ziemlich leidenschaftslos. Ich denke nur, es wäre für MPF und Lisy einfacher, wenn ihr meine vorhandene Segmentdefinition nehmen könntet, um ASCII Zeichen in Segmentdaten zu verwandeln - ansonsten müsst ihr die ganzen Zeichen neu berechnen.

Das war's von mir.

Link to post
Share on other sites

Also wenn Du schon alle Formate intern abfackeln kannst dann hier meine Wunschliste,

andere HW muss/kann ja nicht alles implemententieren, und wer sich nach wem richtet wär ja dann

in der Initialisierung auszuhandeln ( Automatische Einigung auf groessten gemeinsamen Nenner )

0x6 - Get Segment Display Count

0x7 - Get Segment Display Type

0x25 - Set Segment Display Type

jeweils für 0x7 & 0x25 zwei Bytes: <code type><number of segments>

wobei für 0x25 dann Rückgabewert ob die HW das akzeptiert hat.

Code types:

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

5 -> ASCII ( ASCII Code -> ohne Komma)
6 -> ASCII2 (ASCII-> mit Komma im highbit)

Bei SEG14 schickt der Client zwei Byte Daten pro Segment, bei allen anderen Formaten jeweils ein Byte, aber immer vollständig 'number of segments'

 

vor 56 Minuten schrieb Black Knight:

Ich denke nur, es wäre für MPF und Lisy einfacher, wenn ihr meine vorhandene Segmentdefinition nehmen könntet, um ASCII Zeichen in Segmentdaten zu verwandeln - ansonsten müsst ihr die ganzen Zeichen neu berechnen.

Eher umgekehrt, bin da aber auch flexibel. Wenn wir 'pinmame' Format nehmen muesste ich gar nichts berechnen und die zwei Bytes einfach durchschieben, ich kann aber auch vorher noch bissel bits schieben..., kein Thema @jabdoawas ist mit MPF, gibt es da schon eine Segmentdefinition?

Link to post
Share on other sites

Wir sind da flexibel. Unterschiedlich Platformen machen das unterschiedlich. Mit dem Format oben komme ich gut klar. Am Ende ist es pro Format eine Mappingtable. An sich finde ich die Ordnung wie auf dem Display gut (also a,b,c...). Muss aber nicht. Ich richte mich da nach euch.

 

Jan

Link to post
Share on other sites
4 hours ago, bontango said:

wobei für 0x25 dann Rückgabewert ob die HW das akzeptiert hat.

Würdest du bei 0x25 auch die Anzahl der Segmente nochmal mitschicken wollen oder nur den Inhalt?

Wann soll sich die HW beschweren? Wenn man versucht auf einem BCD Display Segmente oder Buchstaben darzustellen? Meiner Meinung nach können wir uns diese Rückmeldung sparen. Lisy und MPF wissen ja durch 0x07 welche Art Displays verbaut sind, damit verfügen sie über die gleichen Infos wie die HW und können gleich selbst entscheiden, wie sie diese Displays ansteuern. Wenn sie das falsch machen, dann stimmt sowieso was grundsätzliches nicht und eine Fehlermeldung der HW würde ihnen vermutlich auch nicht weiter helfen.

Ansonsten ist das für mich OK.

Link to post
Share on other sites
vor 16 Stunden schrieb Black Knight:

Würdest du bei 0x25 auch die Anzahl der Segmente nochmal mitschicken wollen oder nur den Inhalt? 

Bei " 0x25 - Set Segment Display Type " würde ich den Typ für jedes Display setzen ( also dann pro vorhandenes Display jeweils drei Bytes schicken: <display number> <code type><number of segments> ) nicht zwei Bytes wie ich oben geschrieben hatte. Der Inhalt kommt dann über Befehle 0x1e bis 0x24, und zwar jeweils so viele Byte (Double Bytes) wie via 0x25 angekündigt. Also z.B. 6Bytes für BCD Display mit 6 Stellen, oder 14Bytes für SEG14 Display mit 7 Stellen.

vor 16 Stunden schrieb Black Knight:

Wann soll sich die HW beschweren? Wenn man versucht auf einem BCD Display Segmente oder Buchstaben darzustellen? Meiner Meinung nach können wir uns diese Rückmeldung sparen. Lisy und MPF wissen ja durch 0x07 welche Art Displays verbaut sind,

Ja, können wir uns wohl sparen. Der APC muss nur klaglos als Displaytyp setzen was ihm LISY/MPF sagen. Ich denke da an den Fall dass der Anwender den Displaytyp falsch im APC einstellt, bzw gar nicht ändert, und nur auf USB_control geht. Dann ist das was APC via 0x7 zurückmeldet ja nicht dass was an Physik an ihm dran hängt.

Link to post
Share on other sites
10 minutes ago, bontango said:

Dann ist das was APC via 0x7 zurückmeldet ja nicht dass was an Physik an ihm dran hängt.

Verstehe, aber in diesem Fall geht es sowieso schief, da hilft uns auch eine Fehlermeldung nicht. Der APC weiß es dann ja einfach nicht besser und kann daher auch keinen Fehler schicken.

Ich baue das dann jetzt alles so ein.

Und denkt bitte an die Änderung bei den Audio-Kanälen: 

Quote

Könnten wir 'Play Soundfile' (0x34) so ändern, dass 1 die Nummer des ersten Tracks ist und nicht Null? Bei mir markiert die Null bei den Befehlen mit Stringargumenten nämlich immer das Ende des Befehls und das würde ich nach Möglichkeit auch gerne so lassen. 

 

Link to post
Share on other sites

Eins ist mir noch aufgefallen:  Bei 0x1e - 0x24

Das mit " Payload is a null terminated string. " ist ja nicht mehr richtig.

Wir würden dann (auch bei ASCII) immer nur die Anzahl Bytes (oder Bytes*2) schicken die auf das Display passen,

auch bei ASCII, womit die \0 am Ende wegfallen würde, richtig?

Link to post
Share on other sites

Na, bei dir läuft's ja.

Hast du da eine Switch-Matrix zum Testen? Nobel.

Du kannst die Schalter 65 - 73 übrigens auch testen: einfach den entsprechenden Pin an 1J18 oder 1J14 mit GND verbinden.

Link to post
Share on other sites
vor einer Stunde schrieb bontango:

Eins ist mir noch aufgefallen:  Bei 0x1e - 0x24

Das mit " Payload is a null terminated string. " ist ja nicht mehr richtig.

Wir würden dann (auch bei ASCII) immer nur die Anzahl Bytes (oder Bytes*2) schicken die auf das Display passen,

auch bei ASCII, womit die \0 am Ende wegfallen würde, richtig? 

Fixed. War im Example ja auch schon nicht mehr drin.

Link to post
Share on other sites
vor 5 Minuten schrieb Black Knight:

Hast du da eine Switch-Matrix zum Testen?

Jo.  Vor 5 Jahren hab' ich die gekauft aber nie gebaut.  Aber es hat sich jetzt gelohnt.

https://www.pinitech.com/products/64switch_tester.php

vor 7 Minuten schrieb Black Knight:

Du kannst die Schalter 65 - 73 übrigens auch testen

Scheint zu klappen.  Ich habe auch ein TestSwitch dafuer.  Im Bild kannst du auch Lamp Matrix and Solenoid Output testers sehen.  Die habe ich ziemlich oft benutzt bei meine "Snux" board.

IMG_20190706_140704.jpg.cedf643cf1bce563455d1260dbd85406.jpg

http://www.siegecraft.us/presta/index.php?id_product=11&controller=product&id_lang=1

Link to post
Share on other sites
13 minutes ago, Snux said:

Im Bild kannst du auch Lamp Matrix and Solenoid Output testers sehen.  Die habe ich ziemlich oft benutzt bei meine "Snux" board.

Die kannst du ja dann bald wieder benutzen.

So gut bin ich nicht ausgestattet. Ich arbeite viel mit meinem Logiktester und wenn's haarig wird, dann muss das Oszi ran.

Link to post
Share on other sites
3 hours ago, bontango said:

Bei " 0x25 - Set Segment Display Type " würde ich den Typ für jedes Display setzen ( also dann pro vorhandenes Display jeweils drei Bytes schicken: <display number> <code type><number of segments> ) nicht zwei Bytes wie ich oben geschrieben hatte.

Der Befehl fehlt noch in der Doku.

Was ist eigentlich mit 'number of segments' gemeint? Wir haben doch eigentlich schon alles mit 0x07 geklärt, oder?

 

Link to post
Share on other sites

Anzahl Stellen auf dem Display wonach sich die Anzahl der Bytes die pro Display gesendet werden berechnet.

Ist halt die Frage ob der Client die, unter Umständen falsche, HW Einstellung des APC überschreiben darf.

z.B. der AW hat den APC Displaytyp auf z.B. System9 falsch eingestellt und LISY/pinmame will ein grosses System11C Displayboard betreiben,

 

Link to post
Share on other sites
vor 52 Minuten schrieb Black Knight:
vor 4 Stunden schrieb bontango:

Bei " 0x25 - Set Segment Display Type " würde ich den Typ für jedes Display setzen ( also dann pro vorhandenes Display jeweils drei Bytes schicken: <display number> <code type><number of segments> ) nicht zwei Bytes wie ich oben geschrieben hatte.

Der Befehl fehlt noch in der Doku.

Was ist eigentlich mit 'number of segments' gemeint? Wir haben doch eigentlich schon alles mit 0x07 geklärt, oder?

Warum setzen? MPF wird genau das senden was die Hardware als Type zurück gibt. Und zwar genau die Anzahl an Bytes. Wir können gerne bei 0x1E - 0x24 auch noch eine Länge einfügen. Ist dann einfacher zu parsen aber eigentlich redundant. Mir egal.

Ich habe gerade in MPF eine generische Mappingtable eingebaut für alle möglichen Displays https://github.com/missionpinball/mpf/blob/lisy_segment_displays/mpf/core/segment_mappings.py. Werden wir dann in Zukunft in allen Platformen verwenden. Zusätzlich brauchen wir vermutlich noch einen Raw mode in MPF damit man eigene "Grafiken" anzeigen kann. Ich denke ein Text und ein Grafikinterface macht Sinn. Später abstrahieren wir dann Text -> Elemente aus den Platformen raus damit wir das nicht mehrfach implementieren müssen.

Link to post
Share on other sites

Zumindest die Möglichkeit zum setzen des Typs wäre gut, ein 14 Segment kann ja auch ASCII ist halt die Frage in welchem Format man es anspricht. Der APC kann die Umsetzung ja schon, und ASCII direkt würde mir ersparen ein Mapping zu machen wenn ich LISY Statusmeldungen ausgeben will.

Link to post
Share on other sites

Können wir noch hinzufügen. Ich habe die erste Implementierung des Formats in MPF fertig gemacht. Braucht noch ein paar mehr Unit Tests aber an sich gehts. Merge ich morgen nach dev.

Jan

Link to post
Share on other sites

Mit meiner Lamp Matrix ist was ein bisschen komish.

"All Lamps" - fehlen Lamps 01-08.  Aber nicht ganz, die sind einfach nicht so hell.IMG_20190707_080533.jpg.455456928ae79eb47319581add3bd92f.jpg

Single Lamps - klappt OK, aber es gibt auch eine andere Lampe die "on" ist aber schwach.  Lamp 1 on - lamp 57 on aber schwach.  Lamp 2 on, lamp 58 schwach.  Lamp 9 on, lamp 1 schwach, bei lamp 20 ist 12 schwach.  Immer quasi "same row, previous column".

IMG_20190707_075728.jpg.ef907a71dafc03799dcc765551351ed3.jpgIMG_20190707_075807.jpg.81dd765ba81043b52df8b53473800d0b.jpg

 

Ist es veilleicht ein Software (timing) problem, weil die Lampen LEDs sind?  Meine F-14 hat uberall LEDs fuer Matrix Lampen.....  Nicht RGB, sondern normale LED #555 oder #44.

Logik Tester habe ich, falls das hilft.  Oszi habe ich nicht...

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Privacy Policy and Community Guidelines