Black Knight Posted October 23, 2020 Author Posted October 23, 2020 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 ...
bontango Posted October 23, 2020 Posted October 23, 2020 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 ...
bontango Posted October 23, 2020 Posted October 23, 2020 lad noch mal neu bitte, jetzt sieht es besser aus
Black Knight Posted October 23, 2020 Author Posted October 23, 2020 Ich kann erst morgen weiter machen. Melde mich dann. Gruß Frank
Black Knight Posted October 24, 2020 Author Posted October 24, 2020 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?
bontango Posted October 24, 2020 Posted October 24, 2020 (edited) 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. Edited October 24, 2020 by bontango
Black Knight Posted October 25, 2020 Author Posted October 25, 2020 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.
Black Knight Posted November 1, 2020 Author Posted November 1, 2020 (edited) 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 Edited November 1, 2020 by Black Knight
bontango Posted November 1, 2020 Posted November 1, 2020 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?
Black Knight Posted November 1, 2020 Author Posted November 1, 2020 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.
Black Knight Posted November 3, 2020 Author Posted November 3, 2020 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?
bontango Posted November 3, 2020 Posted November 3, 2020 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.
Black Knight Posted November 4, 2020 Author Posted November 4, 2020 vor 21 Stunden schrieb bontango: Müssen nur überlegen wie wir die Erkennung machen Den 10K Erkennungswiderstand an einen anderen Pin legen?
bontango Posted November 5, 2020 Posted November 5, 2020 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)
Black Knight Posted November 5, 2020 Author Posted November 5, 2020 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.
bontango Posted November 5, 2020 Posted November 5, 2020 Veständlich, ich such heute Nachmittag mal ob ich eine geeigneten IO Port zur HW Erkennung finde.
bontango Posted November 5, 2020 Posted November 5, 2020 Dann lass uns pin18 (GPIO24) am PI nehmen. Leg den bitte über 10K an 3Volt.
Black Knight Posted November 5, 2020 Author Posted November 5, 2020 Da ist schon die gelbe LED dran, siehe hier (letzte Seite).
bontango Posted November 5, 2020 Posted November 5, 2020 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?
Black Knight Posted November 5, 2020 Author Posted November 5, 2020 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.
Black Knight Posted November 7, 2020 Author Posted November 7, 2020 Kann ich den Mangel an Widerspruch als Zustimmung deuten? 🙄
Black Knight Posted November 7, 2020 Author Posted November 7, 2020 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.
bontango Posted November 7, 2020 Posted November 7, 2020 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 😄
Black Knight Posted November 7, 2020 Author Posted November 7, 2020 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.
Black Knight Posted November 7, 2020 Author Posted November 7, 2020 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?
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now