Hallo Liebes Forum, Ich bin gerade dabei meine LED-Matrix mit Leben zu füllen. Dazu möchte ich gerne Software wie Jinx oder Glediator verwenden. Um die Daten auf die Matrix zu bekommen benutze ich ein Stm32f4-Discovery mit HC-05 Bluetooth Modul. Die Ansteuerung der LED und des HC-05 funktioniert alles schon. Ich möchte gerne das TPM2-Protokoll über die serielle Schnittstelle nutzen (http://www.ledstyles.de/index.php/Thread/18969-tpm2-Protokoll-zur-Matrix-Lichtsteuerung/). Kurz zusammengefasst: 1. Blockstart: 0xC9 2. Blockart: 0xDA 3. Framegröße: 0x0003 (In meinem Fall) 4. Nutzdaten: 256*3=768 Byte (In meinem Fall) 5. Endekennung: 0x36 Kopfschmerzen bereitet mir dabei die Endekennung des Protokolls. Bisher wurde im Empfangspuffer nach 0x36 gesucht und wenn gefunden wurde ein Telegramm als Empfangen angesehen. Funktioniert soweit auch gut bis 0x36 als Farbwert in den Nutzdaten auftaucht. Dann wird ja mitten im Telegramm das Ende erkannt und es kommt Unsinn auf der Matrix heraus. Wie umgeht man dieses Problem nun am elegantesten? Gruß M.M.
Gast
#4647801
Du solltest mit der Framegröße arbeiten anstatt nur auf das Endezeichen zu matchen, sonst passiert genau das was du berichtet hast :)
Kam mir natürlich auch schon in den Sinn. Nur welchen Ansatz benutzt man da. man muss ja nicht immer das Rad neu erfinden ;-) Ein Ansatz von mir wäre Blockstart und -art zu suchen und dann die Framegröße auszulesen. Diese dann auf Plausibilität prüfen. Ebenfalls benötige ich die Position des Lese-Pointers (Empfangspuffer ist ein Ringpuffer). Dann kann ich mir die Position berechnen an dem die Endekennung auftauchen müsste. Wenn dann die restlichen Bytes bis zu dieser Position empfangen wurden und es wirklich die Endekennung ist habe ich mein Telegramm beisammen. Macht dieser Ansatz Sinn oder gibt es einfachere bessere elegantere Methoden? Es könnte natürlich auch passieren dass zufälligerweise mal irgendwo 0xC9DA als Farbwert auftaucht!