Hier im Forum gibt es ja in letzter Zeit mehrere LED-Matrizen, "Pixeltische", etc. und nun auch 3 Freewares zur Ansteuerung von sowas.
Dabei benutzt jeder irgendwie ein eigenes Protokoll - OK, Artnet können alle drei Steuer-SWs, aber das ist schon wieder etwas komplizierter - daher kam der Gedanke auf, hier im Forum ein einfaches Protokoll zu entwickeln, um mit solcher SW einfach über USB/Seriell-Adapter Eigenbau-HW ansteuern zu können. Wunschvorstellung ist dabei, dass möglichst viele mitmachen, so dass der Anwender/Bastler vielseitig diese Steuer-SW mit jener HW kombinieren kann, ohne für jede Kombination wieder extra was programmieren zu müssen.
Dieses Protokoll, das mehrere User zusammen auf die Beine gestellt haben (McGyver, MichuNeo, Pepe_1981, T64, turi und ich) soll nun hier vorgestellt werden. Da dies ein reiner Vorstellungsthread ist, bleibt er geschlossen - bei Fragen und Anregungen bitte PN, wird dann hier eingepflegt. Wenn es was neues gibt, wird es ebenfalls hier hinzugefügt.
als Name wurde "tpm2" gewählt, das sind die Anfangsbuchstaben der Nicknames der Entwickler, t, p, m, je 2x - man kann das auch als "Transport Protocol (for) Matrices (generation) 2" lesen... 
Ziele/Vorgaben
- Das Protokoll sollte nicht auf eine spezielle HW oder Übertragungskanal angewiesen sein - "genormt" wird also nur, wie der Sender die Daten verschicken muss, so dass sie der Empfänger "versteht".
- in erster Linie zur Datenübertragung gedacht, aber mit der Option, es auch für Steuerbefehle nutzen zu können
- ausreichend für Bastler-übliche Matrixgrößen - eine Videowand mit 800x600 Pixeln muss damit nicht angesteuert werden können, da gibt es andere Möglichkeiten
- einfach umzusetzen (die Sende- und Empfangs-SW)
- dabei aber trotzdem recht vielseitig
- Grundsätzlich "Fire and Forget", also der Sender muss nicht auf eine Bestätigung warten (wie bei DMX z.B. ja auch) - vorgesehen ist aber eine einfache Rückmeldung, um z.B. einen Port automatisch finden zu können, oder festzustellen, ob der Empfänger überhaupt noch "anwesend" ist
- "Ausreichend sicher" - Es sollen ja keine Kernkraftwerke damit gesteuert werden, wenn auf einer Matrix alle 20 Minuten mal ein Pixel für einen Frame ne falsche Farbe hat, kann dies toleriert werden.
Protokoll/Umsetzung
Es werden Daten blockweise übertragen, also in "Frames", wie bei DMX z.B. auch - ein Frame ist z.B. ein Bild auf einer Matrix, oder eine Lichtszene o.ä.
Die Blöcke werden - wie bei vielen solcher Protokolle - am Anfang und Ende gekennzeichnet, hier nur mit je einem Byte. Eingebettet die Nutzdaten, davor noch ein paar Steuerbytes. Es gibt keine feste Größe für einen Frame, diese wird mit übertragen. Das macht das Ganze recht flexibel, das Protokoll reicht - bei entsprechend schnellem Kanal - für eine RGB-Matrix mit 21.845 Pixeln, aber wenn man nur einen RGBW-Controller damit steuern will, dann reichen auch 9 Bytes/Frame.
im einzelnen kommen in so einem Frame:
Blockstart-Byte: 0xC9
Block-Art: 0xDA = Datenframe (DAta) *oder*
0xC0 = Befehl (Command) *oder*
0xAA = Angeforderte Antwort (vom Datenempfänger an den Sender)
Framegöße in 16 Bit: High-Byte zuerst, dann
Low-Byte
Nutzdaten: 1 - 65.535 Bytes Daten oder Befehle mit Parametern
Blockende-Byte: 0x36Das schöne ist hier eben die variable Framegröße - dadurch gibt es keinen Overhead und immer maximal mögliche Übertragungsgeschwindigkeit. Weiterhin ist damit z.B. auch eine "automatische Adressierung" per Daisy-Chain möglich: der Sender schickt z.B. 2.048 Bytes raus, der erste Empfänger nimmt sich die ersten 512 Bytes raus, setzt die Framegröße um 512 runter und schickt den Rest weiter - usw., bis nichts mehr übrig ist.
Unabhängig davon ist es natürlich auch hier möglich (wie bei DMX auch), dass mehrere Empfänger "parallel" (an einem Bus o.ä.) die selben Daten empfangen, und jeder sich nur die rausnimmt, die für ihn interessant sind (per Adress-Einstellung).
Die Befehle sind zum jetzigen Zeitpunkt noch nicht genormt, ebensowenig wie mögliche Antworten darauf - denkbar z.B. Einstellungen aus der Ferne zu machen, oder Automatik-Einstellung, die Steuer-SW fragt die Matrix ab, wie groß sie ist, wie verkabelt, etc. und stellt sich dann automatisch darauf ein.
Hier ist i.M. noch nichts implementiert, wenn solche Befehle benutzt werden (z.B. auch Sachen wie "folgende Frames auf SD-Karte speichern"), sollten sie natürlich ebenfalls einheitlich sein, damit auch hier SW von User x mit HW von User y zusammenarbeitet.
Handshake/Flow-Control
vorgesehen ist, dass der Empfänger nach jedem korrekt empfangenen Frame (also beim Blockende-Byte) als Antwort 0xAC ("ACknowledge) zurück sendet. So weiß der Sender, dass das Gerät empfangen hat, es ist z.B. auch möglich, dass die Sende-SW auf allen möglichen Ports einen Frame rausschickt, wo dann 0xAC zurück kommt, hängt der Empfänger dran (Pixelcontroller macht das z.B. so).
Diese Rückmeldung soll aber keine "Pflicht" sein, der Sender soll trotzdem weiter senden, auch wenn keine Rückmeldung kommt (vermeidet Verzögerungen), und in der Sende-SW sollte der (z.B. bei USB VCP-)-Port auch manuell einstellbar sein.
Hardware/unterliegende Schicht/Baudrate etc.
Für dieses Protokoll sind keine speziellen HW-Voraussetzungen (Übertragungsweg, Stecker, etc.) "genormt" - Es geht wie gesagt nur um die Definition der Datenblöcke, ob diese dann über RS232, TTL, USB, RS485, Ethernet oder Funk übertragen werden, spielt dafür keine Rolle - dies bleibt jedem Anwender selbst überlassen.
Ebenso die benutzte Baudrate, diese kann ja je nach Anforderung höchst unterschiedlich sein: Für die 128x128-Pixel-Matrix mit 30 fps sind schon eher 100 Mbit (Ethernet o.ä.) angesagt, für den 16x16-Pixel-Tisch reichen 250-500 kBaud über USB, für ne Gebäudelichtsteuerung, wo hier und da mal eine Leuchte ein- oder ausgeschaltet wird, reichen auch 2.400 Baud...
Für die Übertragung über UDP wird noch ein Port genormt.
Das soll erst mal zur Definition reichen, wenn ich was wichtiges vergessen habe -> PN