Ich hab für eine led matrix eine ino file aufs arduino board geladen und hab das problem, dass nach dem neustart von jinx, dem trennen des usb steckers oder nach längerer wartezeit keine reaktion mehr bei neuem verbinden. Daher die frage, liegt es am Arduino programm selbst oder am arduino?
bei anderen programmen funktioniert alles nach dem neustart oder dem stromverlust des arduinos.
im anhang die ino.
tpm2_test.ino (9.59 KB)
Hallo,
ich würde erstmal die Baudrate richtig einstellen.
die ist richtig danke dafür^^ ich arbeite mit 500000 baut für die kommunikation. diese war von anfang an so in der firmware integriert. also von der funktion läuft alles, nur eben nach stromverlust muss ich die firmware neu aufspielen bei diesem code. bei anderen läuft alles und bleibt auch fix.
psyqjo:
Daher die frage, liegt es am Arduino programm selbst oder am arduino?
Wieso sollte es "am Arduino" liegen?
Dein serielles Datenprotokoll kann sich offenbar nicht "selbst synchronisieren", wenn der Empfang "mittendrin startet".
Wenn ich mir nur ansehe, dass Du die Variable "data.pos" immer munter mit "data.pos++;" hochzählst, nachdem Du ein Zeichen empfangen hast, aber Du gleichzeitig ein Startbyte nur dann erkennen möchtest, wenn "data.pos" den Wert 0 hat, während das Startbyte eintrifft:
if (data.pos == posStart && val == tpm2Start) // Startbyte
resetVars();
dann sieht das für mich so aus, als wenn sich Dein Code niemals "selbst synchronisieren" kann, nachdem er einmal aus der Synchronisierung raus ist. Sondern dann synchronisiert sich die serielle Empfangslogik nur dann auf den Datenempfang, wenn gleichzeitig "data.pos" zufällig gerade den Wert 0 hat, wenn ein Startbyte eintrifft.
Also für mich sieht das aus nach entweder "Logik des Protokolls fehlerhaft" oder "Protokoll fehlerhaft implementiert". Und dadurch keine Selbstsynchronisierung, wenn das Startbyte nicht das erste Byte ist, das empfangen wird.
Hallo,
Du meinst Du mußt den Arduino neu flashen nach Trennung vom Strom?
Ein Reset des Arduino's reicht nicht aus? Kann eigentlich so nicht sein.
Hast Du einen Nachbau oder Originalen?
Ist der Code selbst geschrieben oder woher?
Mir fiel jetzt noch auf das du in der loop noch eine while(1) hast. Stört zwar nicht, ist aber doppelt gemoppelt.
Bei Deiner Kommunikation steige ich noch nicht durch. Jurs schon.
Ich denke Du machst was ähnliches wie Leon333. fastled laufen lassen und woanders her Befehle entgegennehmen.
Dann nehme mal die Kommunikationgeschichte raus und gucke was passiert. Ich denke es wird laufen.
Dann weist du schon einmal grob woran es liegt.
Danke für die posts bisher, also zu den fragen:
Ich besitze ein Nachbau, und den code hab ich im inet gefunden da ich es noch nicht so mit dem coden hab.
Die geschichte mit dem syncronisieren macht irgendwie sin, jetzt nur die frage, wie kann ich das beheben? hast du mir evtl einen code, oder kann man den nutzen den du gepostet hast?
Der original code liegt als anhang bei, bei meinem code hab ich schon einige teile entfernt die ich für unnötig halte.
hier übrigend der download GitHub - TheChief79/tpm2arduino: Tpm2 Firmware for Arduino
tpm2arduino-master.zip (6.32 KB)
Hallo,
du bist schon irgendwie lustig, oder?
Andere Sketche funktionieren, nur der nicht und dann erfährt man so nebenbei das Du einfach paar Teile vom Code entfernt hast die Du für unnötig hälst. Aber Du noch keine Ahnung vom programmieren hast. Paßt das irgendwie zusammen?
Haste schon den unveränderten Code probiert?
kurzes info, der code funktioniert schon wie im 1. post ja bereits gepostet. doch wenn der arduino keine spannung mehr hat wird das sketch zwar nicht gelöscht, aber wenn ich mit jinx verbinde funktioniert dann nichts mehr. dann muss ich erst wieder das sketch hochladen dann funktioniert wieder alles.
wenn der arduino keine spannung mehr hat wird das sketch zwar nicht gelöscht, aber wenn ich mit jinx verbinde funktioniert dann nichts mehr. dann muss ich erst wieder das sketch hochladen dann funktioniert wieder alles
Keine Ahnung was jinx ist, aber noch unklarer ist mir, was deiner Meinung nach mit dem sketch passiert. Wird der flash mit was anderem überschrieben, oder nicht ?
Ein Reset des Arduino's reicht nicht aus? Kann eigentlich so nicht sein.
Ist immer noch äusserst mysteriös...
Hallo,
ich weis auch nicht was jinx sein soll. Und das ein Reset nicht ausreicht will ich nicht glauben. Zudem mir bei dem Code auch Zweifel kommen ob der wirklich getestet wurde bevor er ins Netz ging. jurs hat ja schon einen Fehler gefunden. Falls der nicht durch unüberlegtes Code löschen selbst verursacht ist. Und dann wäre da noch die while(1) direkt in der loop, was mir sagt, dass den Code jemand geschrieben hat der noch nicht so Bescheid weis. Schon deshalb traue ich dem Code an sich nicht über dem Weg.
Aber wie gesagt. Das ein Reset keine Wirkung haben soll leuchtet mir noch nicht ein.
Zumindestens müßte man jinx beenden, Arduino reseten und dann erst jinx wieder starten. Vom Gefühl her.
Was ist Jinx? Jinx ist eine Led Matrix steuer software die unter anderem auch mit TMP2 die steuersignale für die led matrix übermittelt. Ungefähr wie bei einem DVD player (Jinx) und einem TV Gerät (led Matrix)
Der code so wie ich ihn gepostet habe, funktioniert und wurde vorher getestet daher ja auch dieser post der eigendlich nur das problem beheben soll. leider ist es hier ja nicht möglich ein video zu posten um das problem zu verdeutlichen.
Aber ich versuche es einfach nochmals zu erläutern:
Wenn ich das sketch auf das Arduino lade, dann Jinx öffne und mit meinem Arduino verbinde, soll die software die Signale zum ansteuern meiner led Matrix an mein Arduino übermitteln. das Passiert auch und funktioniert ja auch aber nur solange bis ich das Arduino board vom usb ( stromversorgung und Datenübertragung) nehme (Vorher von Jinx getrennt).
Somit sollte eigendlich nach dem reconnekt mit dem PC ( das arduino board) ja das darauf gespeicherte Sketch behandeln als wäre es ein reset bzw eigentlich neustarten. ich weis nicht genau was dann im Programm passiert, aber nach dem wiederholtem verbinden mit Jinx funktioniert die anzeige der übermittelten Datensignale nicht. die signale werden aber übertragen doch wrden offenbar nicht verarbeitet. nachdem wie bereits erwähnt das sketch wiederauf das aurduino aufgespielt wurde und erneut mit Jinx verbunden wurde funktioniert wieder die Anzeige der Übermittelten Signale.
also sehe ich das Problem wohl wie bereits hier erwähnt das mein arduino die Startvariable des TPM2 protokolls nicht mehr findet und kein reset ausführt.
Und wegen meiner aussage, ich habe noch keine erfahrung mit der programmierung von arduino heist das nicht das ich blöd bin und unüberlegt teile aus dem code lösche. zum anderen habe ich ja meinen und in einem anderen post hier das original gepostet. ich hab nur die voreinprogrammierte autoprogramme entfernt. mit programmierung von javascript php und as3 habe ich aber genug erfahrung um zu wissen was ich tue. hätte ich einen teil des codes gelöscht der das ganze steuert hätte ich es rückgängig gemacht. aber das problem besteht auch mit der original datei.
Ob der AVR seinen Speicher verliert, kannst du mit avrdude prüfen.
... ich kanns nicht glauben ....
Hallo,
naja, wer die gestellten Fragen nicht beantwortet und einen Hinweis ignoriert, darf sich nicht wundern. Wenn ich übers Ziel hinaus geschossen bin ... Entschuldigung dafür.
So wie ich das rauslese kann sich jinx und Arduino bei der Kommunikation nicht neu syncronisieren. jurs hatte schon einen Hinweis gegeben. Haste den ernst genommen? Ansonsten wie syncronisierst Du die Kommunikation? Gibts ein Übertragungsprotokoll?
da mir das mit der Syncronisierung auch logisch erschien habe ich vor kurzen schon einmal danach gefragt:
psyqjo:
Die geschichte mit dem syncronisieren macht irgendwie sin, jetzt nur die frage, wie kann ich das beheben? hast du mir evtl einen code, oder kann man den nutzen den du gepostet hast?
Das wäre jetzt eben auch meine vermutung. doch wenn ich jetzt aber die verbindung zu Jinx beende und wenig später wieder verbinde geht alles tadellos.
Das problem kann evtl sein, Wäre jetzt meine vermutung, dass irgend eine Variable fest in den speicher schreibt und diese als Ausgangsvariable beim nächsten neustart des arduinos verwendet wird. dafür müsste ich eben wissen welcher befehl werte in den arduino speicher langfristig speichert um evtl eine funktion zu schreiben diesen speicher nach dem neustart oder eines resets wieder zu lehren.
Hallo,
kennst Du denn das Übertragungsprotokoll von jinx? Irgendwas in der Art mit Startkennung und Endezeichen?
Die werden sicherlich nicht wild drauf los irgendwas an Befehlen schicken.
Wenn Du immer den gleichen Befehl senden kannst, dann lasse ihn 1:1 vom Arduino erstmal ausgeben. Dann siehst was alles geschickt wird. Dann einen anderen Befehl und gucken was ist verschieden und bleibt gleich. Wäre jetzt meine herangehensweise. Wenn das klar ist, können wir anfangen über das Startbyte zu reden wovon jurs schon sprach was munter hochgezählt wird.
ich habe nur diese daten die festlegen welche bytes das tpm2 protokoll verwendet:
tpm2Start = 0xc9,
tpm2DataFrame = 0xda,
tpm2Command = 0xc0,
tpm2Answer = 0xaa,
tpm2End = 0x36,
tpm2Ack = 0xAC
das sind die Standart bytes des tpm2. alles andere wäre nebensache denke ich.
mit 0Xc9 wird einfach der startbyte gesendet und mit 0x36 der endbyte. wie ich aber das ganze protokoll auslesen kann ist mir leider noch nicht klar. bzw ich bekomme leider kein Textstück mit all den werten um das zu vergleichen.
aber ich hoffe das hilft schon mal etwas weiter.
im grunde müsste man nur die abfrage stellen ob der Startbyte ( 0xc9) gesendet wird.
Hallo,
das klingt doch schon mal nach einem klaren Frame oder wie das heißt. Entscheidend ist nämlich nicht nur das Startbyte sondern auch das Ende-Byte zur Erkennung. Sonst weis niemand wann der Befehl komplett ist. Kennst Du noch die maximale Länge eines Befehls? Also ob inkl. Start/Ende Zeichen 5, 10 oder 30 Byte übertragen werden.
Pro frame wird ein kompletter satz ( led werte) ausgegeben. das wären in meinem fall 165 sätze.
ein beispiel wie ich es in einer logfile habe die ich eben erstellt habe:
(Schwarzes bild)
ÉÚï 6
(rotes bild)
ÉÚï p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p p 6
dabei wird wohl das muster sichtbar, bei 30 fps habe ich pro sec 30 dieser zeilen. nach dem endwert "6" wird der Startwert "É" angefügt. die restlichen werte
das heist im protikoll wird dann der Startwert 0xc9 = É , die datenFrameRate 0xda = Ú , command 0xcf (0xc0) = Ï , dann die werte danach der endbyte 0x36 = 6 übertragen
C9DA01EF00700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700000700036
das ist ein frame mit rot ausgelesen mit einem hex editor.
das wären dann 495 chanals wobei jede led 3 chanals benötigt. davor sind dann nur die ganzen start, frame,command und endwerte.
Hallo,
satte 165 Zeichen in einer Befehlübertragung? Das ist arg viel, laut meiner Meinung.
Naja, da kann ich Dir nur das Bsp. geben was ich Leon333 schon gab. Vielleicht haste ja Glück und es klappt gleich. Weil das vor kurzem schon ein Thema war auch mit der fastled Lib, die die Interrupts blockiert.
Kurze Erklärung. Es gibt einen Lesepuffer namens _serialBuffer der z.Z. pauschal 170 Byte groß ist. Es passen minus eins also 169 Zeichen rein. Den unsichtbaren '\0' Null Terminator sieht man nicht. Falls der Buffer doch zu klein ist, mußte ihn erhöhen.
So, die Einlesefunktion legt sich auf die Lauer und wartet bis das Startzeichen erkannt wird. In Deinem Fall müßte das 0xc9 sein. Ab da wird blockierend für den restlichen Sketch alles eingelesen was reinkommt und wieder gewartet bis das Endezeichen kommt. Jetzt ist der Buffer mit einem Befehl gefüllt den man auswerten muß. Und ganz wichtig, der Buffer wird wieder gelöscht und auf Anfang gesetzt, was bei Dir scheinbar nicht der Fall ist.
Damit kannste mal rumspielen und dann an jinx Befehle anpassen oder änderst dann Deinen Sketch ab.
Wichtig ist, dass Du beim einlesen den Frame komplett erkennst und nicht munter einliest ohne Ende.
Du kannst Dir auch diesen Thread reinziehen. Vielleicht wird da manches klarer.
http://forum.arduino.cc/index.php?topic=287398.0
seriell_read_psyqio_jinx_001.ino (3.03 KB)