Hallo, bin neu hier, ich bin derjenige, der diese "Ambilight-SW" für das SEDU-Board geschrieben hat, und wurde auf
diesen Thread aufmerksam gemacht.
Dort hiess es, dass man über das angesprochene Thema hier in diesem Thread weiter diskutieren solle, also mal die Fragen von drüben hier kopiert und beantwortet:
1. Das Seduboard kann nur 250000 (256000 geht wohl auch) und 500000 Baud.
Wenn der richtige Treiber installiert ist (der, bei dem das SEDU-Board in der Geräteüberischt auch so heisst, und *nicht* "USB serial Port"), dann gehen auch 115,2 k Baud.
die Kommunikation erfolgt hier über einen FT232 und dann über UART am Mega16/Mega644p - der µC kann nur bestimmte Baudraten, abgeleitet vom Systemtakt, eben die "geraden" wie 250 k, 500 k, 1 MBit.
da aber die Übertragung vom Rechner zum FT232 über USB erfolgt, gibt es hier keine Baudrate, der Treiber "sagt" dem FT232 nur, wie er das dann ausgeben soll, und der "SEDU-Treiber" wurde eben so modifiziert, dass der FT232 dann 250 k ausgibt, wenn man am Rechner 115,2 k (das ist halt einfach eine oft verwendete Baudrate, auch bei Processing o.ä.) einstellt.
Dies ließe sich auch für andere Baudraten so machen, also z.B. auch wenn man 230 k einstellt, dass dann 250 k raus kommen - siehe dazu die entsprechende AN bei ftdichip.com - ob/wie das für Linux geht, weiß ich aktuell leider nicht...
letztlich ändert man da nur ein paar Zahlen (Prescaler zur Teilung des internen FT232-Takts auf die Baudrate) in der Treiber-Datei, so dass dann eben eine andere Baudrate rauskommt, wenn man am Rechner ne Standard-Baudrate einstellt.
2. Das Protokoll des Seduboard ist miniDMX mit 256Byte Nutzdaten. Der proto String wird dadurch sehr lang und unter XBMC kommt dann der fehler das der proto String nur 255 Zeichen enthalten darf.
Ja, das ist so ein Problem bei Mini-DMX mit den festen Framegrößen, manchmal ist ein Frame gerade 3 Bytes zu klein, manchmal wird er zur Hälfte mit Overhead aufgefüllt...
daher wurde "bei uns" im LED-Forum ein neues
Protokoll mit flexiblen Framegrößen entwickelt - dieses lässt sich hier auch umsetzen. Man muss nur den Startcode 0xC9 schicken, dann 0xDA für Datenframe, dann die Framegröße Hi-Byte/Lo-Byte, dann die Nutzdaten und dann 0x36 als Blockende-Code.
der Protocol-Descriptor würde dann z.B. so aussehen:
|
Source code
|
1
2
|
xC9|xDA|0|15|Rc|Gc|Bc|Rl|Gl|Bl|Rr|Gr|Br|Rt|Gt|Bt|Rb|Gb|Bb|x36
areas: Center, Left 1, Right 1, Top 1, Bottom 1
|
Die "15" eben für die 15 Bytes Nutzdaten, diese Zahl muss dann halt an die verwendete Framegröße angepasst werden, bei mehr als 255 dann in 16 Bit auf die Bytes 3 und 4 aufgeteilt...
für dieses Protokoll wird demnächst eine SW zur Umsetzung auf WS2801/WS2811/TM1804 etc.
hier veröffentlicht, open source, also auch an andere HW als SEDU anpassbar - die macht dann halt nur die Umsetzung für das Ambilight, ohne die ganzen Standalone-Programme etc. - in der nächsten "Plug&Play"-Fertigversion wird das Protokoll aber auch drin sein...
Ich habe immer 2 LED`s zu einem Kanal zusammengeschaltet, da das SEDU Borad nur 64 Kanäle kann.
Das kommt daher, dass es damals für das Zusammenspiel mit AtmoWin entwickelt wurde, und dieses eben max. 64 Kanäle raus schickt.
Vor ein paar Monaten wurde mal angedacht, die Kanalzahl zu erhöhen, weil Boblight auch 256 Kanäle ausgeben könnte - da hatte mir aber niemand gesagt, welchen (inoffiziellen) Mini-DMX-Startcode für die Framegröße 768 Bytes ich nun nehmen soll, also ist das wieder eingeschlafen...
Das "Problem" ist dann aber auch mit der tpm2-auf-WS2811-etc.-SW bzw. dem nächsten Update behoben... da sind dann bis zu 1.024 RGB-Kanäle drin...
Es gab in dem anderen Thread auch schon ne Antwort, gleich hier rein gebastelt:
Hi, das kligt ja super, dann kann ich ja demnächst alle Kanäle scharf machen
Das mit dem Treiber ist aber nur unter Windows möglich wenn ich dich richtig verstanden habe (also 115k einstellen für 250k).
Es gibt von mir diesen modifizierten Treiber leider nur für Windows - und zwar
hier...
mit Linux kenne ich mich nicht aus, ist da ein Treiber für FT232R schon dabei...? - falls ja, kannst Du mir die Datei ja mal schicken (PN), dann kann ich da mal rein gucken, sollte da ja ähnlich funktionieren, *irgendwo* muss das ja drin stehen, was der FT232 für nen Baudraten-Prescaler nimmt, wenn man am Virtuellen Com-Port (bzw. das Pendant bei Linux, k.A. wie das da heisst) 115,2 k einstellt...