Hier mal eine Idee: i.M. geht es ja wieder verstärkt um Pixelmatritzen, Ansteuerung solcher über den PC u.ä.
Dabei tauchen immer wieder ähnliche Fragen/Problemstellungen auf wie ich habe ne (evtl. selbstgeschriebene, so wie hier) SW am PC, die Daten erzeugt (Animationen etc.) und ne Matrix, die damit angesteuert wird - wie am Besten machen, und gerade bei den komplett selbst gestrickten Sachen kocht da jeder sein eigenes Süppchen...
DMX ist zwar weit verbreitet, hat hier aber die Beschränkung, dass man mit einem Universe nur 170 Pixel ansteuern kann - und evtl. zusätzliche HW braucht, also erst mal ein oder mehrere DMX-Interface(s), und dann wieder ne HW, die DMX empfängt und damit die Matrix steuert (so wie hier z.B.)
für wirklich große Setups ist dann wiederum eher was über Ethernet zu empfehlen, das stellt dann aber schon größere Anforderungen an HW und SW, als die meisten hier bewältigen können...
viele so selbst gebaute LED-Displays haben ja ne Größe zwischen 8x8 bis 16x16 oder 32x16 Pixel, diese Datenmenge ist noch gut über USB zu bewältigen, und von der HW her simpel, ein µC mit USB-Serial-Bridge dran (z.B. FT232) und VCP-Treiber am PC ist alles, was man braucht...
dann geht's nur noch um das Protokoll, was da drüber soll - und hier wird von einigen hier im Forum schon mini-DMX benutzt, auch von Projekten wie AtmoWin (Ambilight), Steuer-SW wie DMXControl und Freestyler kann dieses Protokoll auch ausgeben...
Ich würde es daher gut finden, wenn man diesen Standard im Forum "etablieren" könnte, *muss* ja keiner verwenden, aber wenn jemand gerade so was plant und sich selbst noch keine Gedanken über das Protokoll gemacht hat, warum dann nicht dieses, und dann ist möglichst viel hier im Forum vorgestellte HW und SW von Bastlern untereinander kompatibel...
was haltet Ihr davon...?
das Protokoll ist ja ganz simpel: der µC empfängt Bytes über die serielle Schnittstelle bzw. USB mit Bridgechip - das sid im wesentlichen dann hier eben die RGB-Daten, dazu ein Header zum synchronisieren...
es kommt also zuerst 0x5A, dann als Angabe der Framegröße entweder 0xA0, 0xA1 oder 0xA2, dann die Nutzdaten, und danach 0xA5, wobei
0xA0 = 96 Byte Nutzdaten
0xA1 = 256 Byte Nutzdaten
0xA2 = 512 Byte Nutzdaten
also im Original maximal auch nur ein DMX-Universe...
nun ist es aber kein Problem, mit ausreichender Framerate bei entsprechender Geschwindigkeit an der seriellen Schnittstelle auch größere Frames zu übertragen - von mir getestet wurde bis 3.072 Kanäle mit stabil 33 fps, bei 1 Mbit/s seriellem Input. Das reicht dann schon für ne Matrix mit 32x32 Pixeln...
ich schlage also nun einfach eine simple Erweiterung des Protokolls um weitere Framegrößen vor, und zwar:
0xB0 = 768 Byte Nutzdaten (= 256 RGB-Pixel, also z.B. Matrix 16x16)
0xB1 = 1.536 Byte Nutzdaten (= 512 RGB-Pixel, also z.B. Matrix 32x16)
0xB2 = 3.072 Byte Nutzdaten (= 1.024 RGB-Pixel, also z.B. Matrix 32x32)
da sollte für jeden ein passender Kompromiß zwischen Overhead und Nutzdaten dabei sein, ich werde für meine 20x10-Matrix dann z.B. 0xB0 nehmen, auch wenn es nur 200 Pixel sind - man muss auf Empfängerseite ja auch nicht den kompletten Frame speichern, sondern nur die benötigten Bytes, um RAM zu sparen...
32x32 ist dann schon ziemlich Ende der Fahnenstange bei der Methode, sollte aber für die meisten reichen...
hier eine Übersicht, welche Frameraten dann bei welchem Modus und Datenrate erreichbar sind:
. 250k 500k 1Mbit
0xB0 32 fps 64 fps 128 fps
0xB1 16 fps 32 fps 64 fps
0xB2 8 fps 16 fps 32 fps
(gerundet, wie gesagt, 3.072 Byte über 1 MBit haben in der Praxis 33 fps ergeben, das reicht...)
im Original wird dann eine Bestätigung zurück gesendet, also 0x5A 0xC0 0xA5 für "ausgeführt" - das ignorieren die meisten Sender aber...
da es sich auch nur um ein Byte Info handelt, finde ich die Bytes für Blockstart und Blockende hier überflüssig, würde also nur ein Byte zurück schicken, das reicht - bei mir ist das z.B. 0xAC für "ACknowledge" als Bestätigung - ist so in der SEDU-Ambilight-SW drin und wird auch benutzt...
Dort gibt es auch noch eine Erweiterung - kommt nach dem Blockstart statt A0 - A2 etc. ein 0xFF, dann sind die folgenden Daten Steuerbefehle - wie diese wiederum aussehen, ist dann anwendungsspezifisch, ich benutze das z.B. für die Konfiguration des SEDU-Ambilight über Terminal bwz. Config-Tool...
Bei den Nutzdaten würde ich das dann so machen, dass diese "generisch" gesendet werden, also immer je ein Byte R, G und B, von links oben nach rechts unten - wenn eine Matrix z.B. weniger Farbtiefe als 24 Bit hat, oder von der Pixelreihenfolge her anders verkabelt ist, dann kann man das Umrechnen/Umsortieren im Controller machen, weil *der* gehört ja zur Matrix dazu, der *weiß*, wie diese die Daten braucht - wenn schon in der PC-SW ne bestimmte Reihenfolge oder Farbtiefe etc. festegelegt wird, dann ist man nicht mehr flexibel... so (generische Daten) kann man dann im Prinzip jede Matrix mit jeder Steuer-SW ansprechen
Also, wer alles mit der Thematik beschäftigt ist, schreibt doch mal hier, was Ihr davon haltet - also wie Ihr es generell finden würdet, wenn man sich hier im Forum auf so nen Standard einigen könnte, und ob dieser hier passen würde oder was man dran verbessern könnte...