Forums

Ja denke auch, lass uns das mal auf beiden Seiten implementieren und schauen was passiert

Ja genau, das meinte ich. Ich wollte zwar, dass der APC die Anzahl der Bytes schickt die er im Sendepuffer hat, aber du hast Recht; es macht mehr Sinn den APC die Anzahl der empfangenen Bytes bestätigen zu lassen. Ja, lass uns mal mit 1ms starten. Ich rechne sowieso damit, dass dieser Mechanismus nur nach Soundkommandos zum Einsatz kommen wird. Ansonsten ist der APC vermutlich schnell genug. Dann sähe unsere initiale Kommunikation also wie folgt aus: Lisy: 0x00 APC: 0x00 falls der Befehl noch nicht komplett verarbeitet wurde, ansonsten APC: 0x01 (Bestätigung des empfangenen Bytes), dann "APC\0" als Antwort Lisy: 0x40, 0x01, 0x02 (Lese Setting 2 aus Gruppe 1) APC: 0x00 falls der Befehl noch nicht komplett verarbeitet wurde, ansonsten APC: 0x03 (Bestätigung der empfangenen Bytes), dann den Wert des Settings als Antwort   Falls irgendwas schief geht antwortet der APC mit 0xff Das müsste es doch sein, oder?

Ja, läuft 🙂 Es ist halt wie immer: kaum macht mans richtig funktioniert es. Zum Protokoll: wie wäre es wenn Du als Slave immer als erstes Byte einen Status zurück gibst? Mögliche Werte: 0 : nicht bereit/beschäftigt  -> Master wiederholt Befehl nach Wartezeit ( wie lange soll ich warten, 1ms ? ) Anzahl empfangener Bytes -> Befehl angenommen und ausgeführt ( Minimum 1 ) -1: Befehl angenommen aber Interpretationsprobleme :  Error

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

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

Ja, das ist auch meine Befürchtung. 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. 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.

Ja, die Arduino IDE ist leider ziemlich rudimentär. Ich persönlich nutze ein Arduino Plug-In für Eclipse und bin damit sehr zufrieden. Wenn du Eclipse noch nicht kennst wird das etwas Eingewöhnungszeit brauchen, aber das ist eine professionelle IDE, die jede Menge nützliche Funktionen bietet. Allein der eingebaute Debugger ist den Einstiegsärger wert und hat mich schon so manch hartnäckigen Fehler finden lassen. Anhalten ist nicht möglich, da du dann dein ganzes Programm anhalten würdest und du willst ja, dass z.B. Lichteffekte u.ä. weiter laufen. Aber mit deinem Timer bist du auf dem richtigen Weg. Die Funktion selbst läuft nicht mehr, sie wird nur durch den Timer wieder aufgerufen. Da die Routine von sich aus nicht weiß, dass der Timer läuft wird sie sich genauso verhalten wie beim ersten Aufruf. Wenn du dir mein BlackKnight Beispiel ansiehst, dann wird in ClearOuthole ein BlockOuthole Flag gesetzt, welches einen erneuten Durchlauf der Routine verhindert und erst später zurückgesetzt wird, wenn der Ball in die Truhe geschossen wurde u.s.w. Da du ja keine Balltruhe o.ä. in deinem Flash hast braucht dein NewBall eigentlich keine Balls Variable und du könntest mit dieser deinen Status signalisieren. Was ich damit meine ist folgendes: Ich nehme an, du hast in deinem GameMain sowas wie case 48: // outhole WF_NewBall(0); break; dann wird dein NewBall mit dem Parameter Null aufgerufen, wenn er jetzt eine entsprechende Abfrage hat void WF_NewBall(byte Status) { // release ball (Event = expected balls on ramp) static bool Block; if (QuerySwitch(48)) { if (Status) { // wait time already passed? Block = false; // remove block ActivateSolenoid(40, 1); //Give Ball ShowAllPoints(0);} else { // called from GameMain if (!Block) { // block not set? Block = true; // set it ActivateTimer(250, 1, WF_NewBall);}}} // call timer else { // switch 48 not active any more Block = false;}} // remove block dann kannst du damit unterscheiden, ob er vom Timer oder GameMain aus aufgerufen wurde. In diesem Fall bedeutet Status = 0 einen Aufruf von GameMain, dabei wird die Block Variable gesetzt um weitere Aufrufe aus GameMain zu blockieren. Dieser Block wird nur aufgehoben, wenn der Timer abgelaufen ist und NewBall daher mit dem Parameter 1 aufgerufen wird oder wenn Switch 48 nicht mehr aktiv ist. ActivateTimer() gibt dir ja die Nummer des Timer zurück. Diese könntest du speichern und den Timer einfach bei Bedarf mit KillTimer beenden. Das ist allerdings eine recht unsanfte Methode, bei der man immer den Überblick über seine Timer behalten muss, damit man nicht den falschen Timer killt. Ich baue solche Routinen daher meisten so ähnlich wie PB_EyeBlink aus Pinbot.ino. Der für dich wichtige Teil ist dieser: void PB_EyeBlink(byte State) { static byte Timer = 0; if ((State > 1) || ((State == 1) && !Timer)) { // do your blinking here Timer = ActivateTimer(500, State, PB_EyeBlink);} else { if (!State) { if (Timer) { KillTimer(Timer); Timer = 0;}}}} Durch die statische Timer Variable weiß die Routine immer, ob sie schon gestartet wurde (Timer != 0) oder ob es der erste Aufruf ist (Timer == 0). Will man die Blinkerei starten dann ruft man PB_CycleDropLights(1) auf. Wenn der Timer schon läuft (Timer !=0) dann passiert gar nichts, d.h. die Routine ist geschützt gegen versehentliches mehrfaches starten. Läuft der Timer dagegen noch nicht, dann wird meine Blinkerei ausgeführt und danach ein neuer Timer aufgerufen, dessen Nummer in Timer gespeichert wird. Hat State beim Aufruf einen Wert größer 1, dann ist die Routine vom eigenen Timer aufgerufen worden und geht direkt zum Blinkteil. Dieser kann State-Werte größer 1 also für sich nutzen. Will man die Blinkerei beenden, dann ruft man PB_EyeBlink(0) auf. Die Routine prüft dann, ob ein Timer läuft und beendet diesen ggfs., sie ist also auch gegen versehentliches mehrfaches Beenden geschützt. Ich hoffe, das hilft dir weiter. Mit Lisy und System 4 müssen wir den Ralf mal ganz lieb fragen, vorausgesetzt er spricht noch mit mir nachdem ich ihn mit I2C Problemen gequält habe. 🙄

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 😐

Da das Problem etwas umfangreicher und die Antwort daher auch etwas länglich geworden ist, habe ich sie jetzt in den APC 3.0 thread geschrieben, wo sie ja auch eigentlich hin gehört.

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 ...

Danke Frank, habe sie gefunden bei Karin.👍

Schau mal bei Karin (thepinwitch.com), die hat die richtigen im Programm!