Zum Inhalt springen

Entwicklung APC 3.0 -> Lisy_APC


Black Knight

Empfohlene Beiträge

Der tar hat irgendwas zu meckern. Er packt brav aus, aber dann kommt

boot/lisy/mpfcfg/LISY1/005/hardware_sounds/My Name is Charlie.mp3
boot/lisy/mpfcfg/LISY1/005/hardware_sounds/theme.mp3
tar: Skipping to next header
tar: A lone zero block at 20143
tar: Exiting with failure status due to previous errors

Muss ich da erst aufräumen und die Daten des vorigen Updates entfernen? Aber das sollte dem tar doch eigentlich egal sein ...

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

grad mal mit 7zip gecheckt, scheint ein Problem zu haben, ich glaube meine SD Karte mit der ich entwickle

scheint gearde den Geist aufzugeben 😬 ich meld mich ...

Link zu diesem Kommentar
Auf anderen Seiten teilen

Das mit dem 0x29 'get changed switches' stimmt noch nicht, aber vielleicht haben wir uns da auch missverstanden.

Im Log-File kannst du die I2C Kommunikation sehen. Bei 740ms bremse ich den APC für 50ms aus und das sieht dann so aus:

0.731299000000000,528,0x88,0x0B,Write,ACK
0.731389000000000,528,0x88,0x28,Write,ACK
0.731644000000000,529,0x89,0x02,Read,NAK
0.739905000000000,530,0x88,0x29,Write,ACK
0.740173000000000,531,0x89,0x00,Read,NAK
0.754007500000000,532,0x88,0x29,Write,ACK
0.754280000000000,533,0x89,0x00,Read,NAK
0.771986000000000,534,0x88,0x29,Write,ACK
0.772266500000000,535,0x89,0x00,Read,NAK
0.784075000000000,536,0x88,0x0B,Write,ACK
0.784165000000000,536,0x88,0x0B,Write,ACK
0.784436000000000,537,0x89,0x02,Read,NAK
0.784702500000000,538,0x88,0x0C,Write,ACK
0.784792500000000,538,0x88,0x19,Write,ACK

Nachdem bei 0.74017s die erste Null zurück gekommen ist, wartet der APC auf einen erneuten Read_Zugriff von Lisy, bevor der nächste Befehl kommen darf. Lisy sendet den Befehl aber bei 0.754s erneut.

Gehst du davon aus, dass bei 'get changed switches' der Befehl komplett verworfen wird, wenn der APC eine Null zurück schickt?

Link zu diesem Kommentar
Auf anderen Seiten teilen

Mein Fehler, da ist mir noch was durchgegangen.

Ich musste jetzt die SD Karte wechseln und habe direkt ein Linux update gemacht, d.h. wenn du

den tar update machst könnte es ein binary Problem geben.

Am einfachsten du ziehst Dir die aktuelle Version von lisy_api_com.c von meinem Github

https://github.com/bontango/lisy-src-5.x/blob/master/src/lisy/lisy_api_com.c

überschreibst die aktuelle und führst

./make_lisy

./install_lisy

aus.

 

EDIT:

wenn Du im read/write modus bist ( rw ausführen) kannst Du für die aktuelle

Version von lisy_api_com.c auch in das Verzeichnis lisy wechseln und 'git pull' ausführen.

Bearbeitet von bontango
Link zu diesem Kommentar
Auf anderen Seiten teilen

Jo, das sieht jetzt besser aus.

Leider stürzt meine SW von Zeit zu Zeit komplett ab, noch nicht einmal der 1ms Timer-Interrupt zur Steuerung der HW läuft dann mehr. Das sollte natürlich eigentlich gar nicht passieren und könnte darauf hindeuten, dass die Wire-Library irgendwelchen Schmu mit den Interrupts macht.

Das könnte also eine längere Suche für mich werden, womit du wieder FPGA Zeit hättest. Solltest du natürlich gerade wieder Lisy-Lust haben, dann könntest du ja vielleicht mal nachsehen, warum der Schalter 72 (Advance Knopf) bei den System 3-9 Geräten nicht funktioniert. Dann könntest du endlich vernünftig Comet spielen und LeFreak könnte seinen Flash starten.;)

Link zu diesem Kommentar
Auf anderen Seiten teilen

Hier mal ein Lebenszeichen von mir.

Leider habe ich immer noch nicht herausgefunden, warum die Wire Library manchmal falsche Werte schickt. Im oberen Bild sieht man z.B. wie der APC auf den Befehl 0x0c 0x29 mit 0x05 antwortet, obwohl es 0x02 sein sollte. Ich lasse mir alle Werte aber zusätzlich noch über einen Parallelbus ausgeben und da kann man in der untersten Zeile sehen, dass meine SW die korrekten 0x02 an die Wire-Lib übergibt.

Ich bin mittlerweile soweit, dass ich wohl versuchen werde diese blöde Library nicht mehr zu verwenden, sondern die Funktionen direkt selbst zu programmieren - mal sehen, wann ich dazu Zeit und Lust habe.

Einen komischen Effekt habe ich auch noch gesehen. Im unteren Bild fragt Lisy mit 0x29 nach betätigten Schaltern und bekommt zunächst mit 0x01 die Länge des Befehls zurück. Eigentlich müsste Lisy nun noch ein weiteres Byte lesen, es  sendet aber einen Schreibbefehl ohne Inhalt (nach dem zweiten W[0x88] kommt erst mal nix mehr. Da müsstest du also nochmal nachsehen. Wenn du möchtest schicke ich dir den entsprechenden Datalog.

Insgesamt ist dieser I2C Mist ein ziemlicher Alptraum. Wie gesagt werde ich mal versuchen, die Funktionen selbst und ohne zusätzliche Libs zu programmieren, aber wenn das zu aufwändig wird müssten wir anstatt I2C vielleicht auf eine serielle Schnittstelle wechseln - dazu müsste ich dann natürlich leider die Boards ändern.

Wie hast du das denn bei deinen PICs gemacht, gibt's da vernünftige Libraries oder hast du die I2C Funktionen auch selbst programmiert?

Frustrierte Grüße

Frank

Crash3.png

Crash4.png

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

Ja, schick mir den Log bitte dann schaue ich mal.

Bei den PICs ist das in Applikation Notes beschrieben, war auch ein langer steiniger Weg bis das rund lief, bzw. bei den Switches bei denen das PIC senden muss ( die anderen beiden PICs empfangen nur) habe ich auf 4-bit parallel umgestellt weil das nicht störungsfrei lief wenn direkt nach dem Switch eine Spule ausgelöst hat. Kann das noch ein Grund sein, dass Du Dir einfach Störungen einfängst?

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 59 Minuten schrieb bontango:

Kann das noch ein Grund sein, dass Du Dir einfach Störungen einfängst?

Bei meinen momentanen Experimenten nicht; da betreibe ich das Board außerhalb des Flippers.

So eine Applikation Note suche ich für den Atmel auch noch, die Dokumentation ist da leider nicht so toll.

Das Log ist übrigens raus.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ich frage mich, ob es wirklich sinnvoll ist sich weiter mit I2C herumzuschlagen. Der Hauptvorteil von I2C ist ja wohl die Kommunikation mit mehr als zwei Teilnehmern (so wie bei Lisy) - das haben wir beim APC aber gar nicht.

Wie wäre es also, wenn wir einfach einfach eine serielle Schnittstelle nehmen würden? Die USB-Verbindung, die wir bisher verwendet haben, ist bei mir sowieso nur eine serielle USB-Adaption. Vermutlich könnte ich also alles genauso machen wie zuvor und müsste nur auf eine andere serielle Schnittstelle umschalten.

Wäre das bei dir ähnlich einfach?

Link zu diesem Kommentar
Auf anderen Seiten teilen

Gute Idee,ist ja hupe was intern verwendet wird. Umstellung sollte auch bei mir kei Thema sein. Müssen nur überlegen wie wir die Erkennung machen, eine I2C Adresse haben wir ja dann nicht mehr.

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 21 Stunden schrieb bontango:

Müssen nur überlegen wie wir die Erkennung machen

Den 10K Erkennungswiderstand an einen anderen Pin legen?

Link zu diesem Kommentar
Auf anderen Seiten teilen

Sympathischer wäre mir wenn wir I2C für die Erkennung drin lassen könnten, oder willst Du die am Arduino

die selben Pins für den seriellen Port nehmen?

Beim PI wären es Pin8 (TxD) und Pin10 (RxD)

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 6 Minuten schrieb bontango:

oder willst Du die am Arduino die selben Pins für den seriellen Port nehmen?

Das nicht, aber ich würde die Wire-Library gerne wieder komplett los werden. Sobald ich das Ding aufrufe reserviert die sich ja alle möglichen Pufferspeicher u.s.w. und auch der Arduino DUE kommt dann irgendwann an sein Limit - zumal ich ja jetzt noch einen zweiten seriellen Port durchfüttern muss.

vor 8 Minuten schrieb bontango:

Beim PI wären es Pin8 (TxD) und Pin10 (RxD)

Das sind ja die beiden Pins, die sowieso schon auf dem Lisy-Serial Anschluss liegen. Die würde ich dann einfach weiter an den Arduino führen.

Link zu diesem Kommentar
Auf anderen Seiten teilen

stimmt, irgendwie hatte ich im Hinterkopf Du hast die LISY Standardleds nicht.

Dann lass uns erst mal so starten, ich würde dann für die Tests fest auf seriell schalten. Später kann ich ja einen kurzen Versuch auf seriell starten und dann auf USBseriell umschalten wenn da keiner wohnt!?

Sag mir einfach wenn die SW auf deiner Seite ready ist und welche Pins ich anzapfen muss. Wir bleiben dann aber bei dem neuen, sicheren Protokoll, oder?

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 2 Minuten schrieb bontango:

Später kann ich ja einen kurzen Versuch auf seriell starten und dann auf USBseriell umschalten wenn da keiner wohnt!?

Ist auch OK.

vor 8 Minuten schrieb bontango:

Sag mir einfach wenn die SW auf deiner Seite ready ist und welche Pins ich anzapfen muss.

Das werden wohl die Arduino-Pins 14 und 15 werden. Ich habe auch den Schaltplan auf Github aktualisiert.

vor 11 Minuten schrieb bontango:

Wir bleiben dann aber bei dem neuen, sicheren Protokoll, oder?

Das ist eine sehr gute Frage.

Ich würde es eher kompatibel zum USB-Protokoll aufsetzen und zwar aus folgenden Gründen:

1. mit USB klappt's ja auch 😉

2. keine Verwirrung durch unterschiedliche Protokolle je nach Schnittstelle

3. wir wissen noch nicht, wie flüssig die Emulation in Lisy läuft wenn es ständig auf den APC warten muss. Beim alten System gilt dagegen Punkt 1

Das ist aber momentan nur mein Bauchgefühl, bin offen für Gegenargumente.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ich hab's jetzt einfach mal so eingebaut.

Mein Pi3A ist mittlerweile auch da, also werde ich mein Mini-Lisy Board wieder an's Laufen bringen. Wenn die Steuerung über USB noch funktioniert dann wissen wir wenigstens, dass ich bei meinen Umbauten nicht alles kaputt gemacht habe.

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 52 Minuten schrieb Black Knight:

Kann ich den Mangel an Widerspruch als Zustimmung deuten?

Sorry, ja! Hatte nur in Gedanken geantwortet. 😀

Kannst du den Link zum Schaltplan noch mal korrigiert posten, deiner zeigt auf //home/ff/kram   😄

Link zu diesem Kommentar
Auf anderen Seiten teilen

vor 18 Minuten schrieb bontango:

Kannst du den Link zum Schaltplan noch mal korrigiert posten, deiner zeigt auf //home/ff/kram

Interessant, hier nochmal der korrekte Link.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Mein Lisy_Mini will übrigens auch mit dem Pi3A nicht mehr - das gleiche wie mit dem Pi3B+: gelbe LED blinkt und sonst passiert nix.

Hat sich an Lisy irgendwas verändert? Soll ich mal die Version vom Sommer probieren?

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