Open Source Led Matrix Steuerung: PixelController

Zitat von michuNeo

so unter https://github.com/neophob/PixelControll?iDmxSerial.java habe ich mal eine erste version gemacht.

Super, danke! - sieht für mich (der sich mit Java nicht auskennt, nur so ungefähr nachvollziehen kann, was da passiert) auf jeden Fall interessant und plausibel aus...

das ist jetzt aber nur der Quelltext, oder...? - also ich hab's mal runtergeladen, aber da ist nicht diese PixelController.cmd zum starten dabei...?!

Zitat von michuNeo

ich denke aber diese erste version wird kaum funktionieren, ohne das ganze zu testen. hast du noch irgendwelche dev boards/ausschuss ware rumliegen?

Leider nicht - zum testen sollten da auch zumindest ein paar Pixel dran hängen, damit man sieht ob die machen was sie sollen, da habe ich nix über...

ich hatte gedacht, dass ich das halt teste, und dann die FW für den AVR hier poste...

Du sendest da jetzt mit 230.400 Bit/s...? - weil da muss ich dann erst nen Baudratenquarz auf mein Board löten, das geht mit 16 MHz Systemtakt nicht... k.A. wie das der Arduino macht, gehen da 230.400...? m.W. 115.200 auf jeden Fall, das wäre am AVR-USART bei 16 MHz ein Fehler von 3,5%, OK, da kann's sein, dass es noch funktioniert...

Und wo kommt das dann raus..? - ja, blöde Frage, aber ich kenne mich mit sowas am PC einfach nicht so gut aus, habe mehrere COM-Ports (Programmer, Modem, Touchscreen, und eben auch das Board mit dem FT232), woher weiß der, wo er das hin schicken soll..? - oder kann man das dann einstellen..?

Ich persönlich finde den Arduino ja auch gut, für Anfänger, oder Leute, die nicht so tief in die HW einsteigen wollen - auf der anderen Seite dann aber teilweise etwas blöd, dass das Teil einfach dies&das macht und man weiß nicht wie und warum, findet auch nur schwer Infos drüber...

z.B. eben wegen der Datenrate, man findet nur Beispiele wie man das einstellt, aber nirgendwo ne Liste, welche Baudraten das Teil nun definitiv unterstützt...

Bei mir ist das halt so, dass auf dem Board ein FT232 drauf ist, der µC bekommt von dem ein ganz normales serielles Signal mit eben z.B. 250kBaud - auf dem Rechner ist ein VCP-Treiber installiert (eben der für den FT232), an dem ich auch die 250 k einstellen kann, und dann läuft das - also irgendwie ist mir als Laie auf dem Gebiet schleierhaft, wieso Du dann beim Arduino nicht auf 250 k stellen kannst, sondern nur auf 230.400 k, obwohl das ja eigentlich ne "krumme" Braudrate ist und die 250 k besser wären... - also *warum* die das so gemacht haben, Arduino läuft ja auch auf 16 MHz, da passt 250 k einfach besser als 230 k...

oder liegt das an Java, dass *dort* nur bestimmte Baudraten vorgesehen sind...? - Mein Kumpel hat seinen Treiber in C geschrieben (siehe hier), muss ihn noch mal fragen, ob das evtl. wegen ähnlichen Problemen war... das Teil empfängt die Daten dann über nen Socket, und schickt sie als mini-DMX raus (mit frei einstellbarer Baudrate), allerdings hier dann auf FT232 festgelegt, weil er so nen "Direct Driver" benutzt...

Ist für mich halt alles etwas verwirrend was da auf dem PC abläuft, da ich ja nur in Assembler auf µC programmiere, da gibt's halt serielle Schnittstelle, 8N1 und passende Baudrate eingestellt, fertig...

Zitat von michuNeo

was ich weiter noch wissen sollte, kann ich überprüfen, ob am Seriellen Port wirklich ein miniDMX device hängt (so etwas wie ein ping)?

Siehe die verlinkte Seite zu mini-DMX - normal soll der Empfänger, nachdem er einen Frame empfangen hat, die Folge 5A C1 A5 zurück senden... meine SW (die vom "SEDU-Ambilight") sendet der Einfachheit halber nur 0xAC (von "ACknowledge") zurück - also Frame schicken, und wenn AC kommt, dann ist das Teil auch vorhanden...

Zitat von michuNeo

ich unterstütze momentan folgende payloads:

und welche *benützt* Du hier tatsächlich...? die mit 512 Byte, oder..?

Nee, wie gesagt, mit Arduino kenne ich mich nicht so aus... das müsste halt letztlich ne mini-DMX-lib dafür sein, aber k.A., ob das überhaupt geht, wegen dieser USB-Puffer-Beschränkung...

im Prinzip, Arduino ist ja auch nix anderes als ein normaler AVR mit USB-Bridgechip dran und Bootloader drauf - da läuft aber kein Betriebssystem oder sowas (?), sondern die IDE erzeugt ein binary, welches so wie's ist drauf geladen wird...?

also wenn man da auch normale .hex-Files drauf laden kann, dann könnte ich meine SW im Prinzip auch auf den jeweiligen Ardunio (ist der mit Mega328, oder?) anpassen

da bleibt dann aber das Problem, wie vernünftig 230 k mit 16 MHz...

also werde ich nun mal bei mir nen Baudratenquarz drauf machen, und mir den ganzen Kram mal ansehen, bzw. mein Kumpel soll das mal kompilieren (der hat die ganze nötige SW schon auf dem Rechner und kennt sich da aus), evtl. hat der ja noch ne Idee, ob/wie man das irgendwie dazu bringen kann, doch mit 250 oder 500 k zu senden...

wegen dem Ping, wie gesagt, nen kompletten Frame hin schicken, dann kommt 0xAC zurück... so ist das i.M., wie gesagt, Standard-mDMX-Rückmeldung sieht anders aus, aber ich finde es recht sinnlos, bei einem Byte Info noch mal 5A davor und A5 danach zu senden...

geplant ist aber auch noch ein "richtiger" Ping, also man schickt nen entsprecheden Befehl, und dann meldet sich das Teil, gleich mit Info darüber, was es nun genau ist (also Lichterkette, oder Matrix mit x mal y Auflösung usw.)

z.B. statt Framegröße-Byte dann "EC" (für "extended command"), danach kommt eben der Befehl "Konfiguration senden" und das Teil schickt (ebenfalls nach ner festgelgten "Norm") die Info "ich bin hier, ich bin ne RGB-Matrix mit 32x16 und 8 bit Farbtiefe"...

das ist noch nicht ganz ausklamüsert, wie das genau aussehen soll, ich habe dazu ja extra diesen Thread aufgemacht, weil es super wäre, wenn möglichst viele Leute sich da auf nen Standard (eben z.B. welches Byte was bedeutet, welches Byte für welche Framegröße etc.) einigen könnten... aber irgendwie ist da ausser sinnlosen Grundsatzdiskussionen leider kein Interesse vorhanden...

ich weiß auch nicht, ob es nicht besser wäre, gleich nen komplett neuen Standard zu machen, aber mein Gedanke war der, dass man dann eben in den Fällen, wo 512 Byte reichen, ohne große SW-Änderung bereits vorhandenes mDMX-Equipment ebenfalls mit diesem Protokoll ansprechen kann... ich hatte halt mini-DMX genommen, weil AtmoWin das sendet - für meine Matrix hatten der Schulterklopfer und ich erst dran gedacht, dass man ein Protokoll mit flexibler Framegröße macht, also Startcode - Info über die Framegröße - Nutzdaten (variabel) - Blockende...

dann haben wir uns halt doch auf "praktisch mini-DMX, nur halt mit anderer Framegröße" geeinigt...

Zitat von michuNeo

ich sende nun als ping ein 512b payload (also eine gültige minidmx message) und erwarte eine 3 byte reply, nicht nur ein 1 byte reply wie du beschrieben hast.

Ah, OK, Du schickst also mini-DMX nach Original-Standard, dann muss ich das auch so implementieren...

Zitat von michuNeo

was hier noch anzumerken ist - da heute meistens ein usb/serieller konverter verwendet wird, sind 1byte replys (oder auch 3 byte) replys höchst ungünstig. der grund ist, (...)

Siehst Du mal, an so was denke ich gar nicht, weil bei dem Projekt alles jenseits vom AVR das Hoheitsgebiet meines Kumpels ist...

das muss ich dem dann mal verklickern! - wir hatten ja diesen Frameraten-Test gemacht, und sind dabei mit 3.072 Byte über 1 Mbit/s auf 33 fps gekommen, das war unser gewünschtes Maximum..

ich hatte ihm zwar schon erklärt, dass das Ganze synchron laufen sollte, also er schickt nen Frame, ich verarbeite den, schicke dann die Bestätigung, darauf hin er den nächsten Frame, usw.

aber *anscheinend* (ich frage nach) hat er einfach stur Frames raus geschickt, und den *Abstand* gemessen, in dem die "AC" zurück kamen (bzw. wie viele in der Sekunde), und nicht immer mit dem neuen Frame gewartet, bis der vorige bestätigt wurde...?!?

weil 33 x 16 ms wären ja 528 ms, d.h. da wüde das Teil mehr als die Hälfte der Zeit einfach warten - und da dann pro Sekunde nur noch 472 ms für die eigentliche Übertragung zur Verfügung stehen, kommt man dann noch auf gerade mal 15 fps bei 3.072 Byte und 1 Mbit/s...

jetzt ist die Frage, was machen - ich wollte ja schon, dass das Ganze synchron läuft... zum FT232R gibt's so ein Config-Tool, evtl. kann man da die Wartezeit runter schrauben, mal gucken...

ansonsten muss ich wirklich größere Bestätigungs-Meldungen schicken - nach einem Frame (ca. 33 ms) ist der Buffer ja definitiv leer, also dann 64 Byte schicken (= ca. 640 µs), dann sollte die Rückmeldung deutlich schneller da sein, als wenn ich nur ein Byte schicke...?

da ich natürlich keine 64 Byte brauche, halt dann einfach mit Nullbytes auffüllen o.ä. - im Prinzip, wenn ich als Bestätigung 5A C1 A5 schicke und dann 61 mal 0x00 hinterher, sollte das ja immer noch mini-DMX-kompatibel sein, weil die Bestätigung an sich kommt ja, und dann einfach noch 61 mal 0x00 hinterher, was der Sender einfach ignorieren sollte...

deswegen habe ich Dir ja ein paar Mal diesen Thread über mDMX-Modifikation verlinkt, weil ich gehofft hatte, dass eben solche Aspekte dort auch gepostet werden.... - aber gut, ich hab's ja nun zum Glück hier gelesen....

und jetzt wird mir auch klar, wie sowas funktioniert - hatte mich früher immer gewundert, wie geht das, die nutzen *jeden Takt* aus, wie soll der µC da noch was anderes machen..? - aber, klar, 250 kBit/s über USB (12 MBit/s) ist ja kein kontinuierlicher Strom, da kommt praktisch ein Telegramm mit 254 Byte, das wird abgespeichert (in der Zeit kann der µC wirklich *gar nix* anderes machen), und dann ist die meiste Zeit wieder Ruhe auf dem USB, also genug Takte, um die empfangenen Bytes zu verarbeiten...

Zitat von michuNeo

ich habe nun meine pixelcontroller software aktualisisert, damit du relativ einfach den minidmx output wählen kannst. im konfig file "config.properties" folgendes property aktivieren:

Danke für die ganzen Infos etc! - das wird jetzt aber bestimmt ne Woche dauern, bis Du da ne Rückmeldung von mir bekommst, bin das ganze WE unterwegs und so auch viel Arbeit, muss mich erst mal in das Ganze rein denken, JDK und maven2 etc. sind komplettes Neuland für mich...

Zitat von michuNeo

ich habe bei meinen ersten rainbowduino versuchen asynchron gearbeitet, sprich ich habe einfach frames seriell rausgehauen und gehofft das das funktioniert, jedoch funktioniert das nach einer gewissen zeit nicht mehr.(...)

Ja, das hast Du ja schon mal erklärt, und ist auch ein cooles Konzept - nur, wie ebenfalls schon gesagt, bei den von mir geplanten Animationen kommt das de facto nicht vor, dass sich in einer Matrixhälfte nix ändert, also völlig überflüssig, auf Änderungen zu testen, weil *sowieso* ständig welche passieren...

und das mit µC flooden kann bei mir dank Assembler nicht passieren, auch bei 1 MBit/s habe ich 160 Takte zwischen 2 rein kommenden Bytes, da kann man einiges machen (auf jeden Fall genug) - das funktioniert ja auch schon problemlos (EDIT: asynchron), ich hätte es nur gerne deswegen synchron, damit so was hier gar nicht passieren *kann*, also dass zufällig das selbe Pixel ausgegeben wird, das gerade rein kommt...

solche Effekte habe ich bei mir zwar noch nicht beobachtet, aber auch noch nicht solche Programme ausgegeben wie ein Frame komplette Matrix weiß, nächster Frame komplette Matrix schwarz, usw. - will halt nur von vornherein das Ganze auf möglichst geringe Latenz(* und keine Überlappungseffekte ausrichten...

P.S.: ausprobiert habe ich Deine SW ja schon, also schon die erste kompilierte Version, die Du hier gepostet hast..

*) EDIT: dazu wäre es natürlich am Besten, jedes empfangene Byte einfach *sofort* an die WS2801 weiter zu schicken - dann ist es auch gut (bzw. absolut erforderlich), wenn die Rückmeldung sicher mind. 500 µs dauert, weil für diese Zeit muss dann auf der Ausgabe-Seite Pause sein... das geht nur bei mir nicht, da ich ja die empfangenen Bytes umsortieren, also auf jeden Fall erst mal puffern muss...

das wäre dann aber die Option für die als neues Ende der Fahnenstange festgelegten 2.048 RGB-Pixel mit 2 MBit/s, da geht's dann nicht mehr anders... da muss dann die Matrix richtig verkabelt sein, oder doch schon die Bytes im PC umsortiert...

Sorry, bis jetzt noch keine Zeit gehabt... - wie gesagt, ich müsste mir dieses ganze Zeug auch erst mal installieren und kapieren, wie das funktioniert

mein Kumpel, der sich mit sowas auskennt, war im Urlaub, ist Freitag erst wieder gekommen - Samstag haben wir dann erst mal an unserer eigenen SW weiter geschnitzt... wir machen das nun so, dass wir einfach Frames raus schicken, ohne auf ne Rückmeldung zu warten - getestet bis 60 fps bei 500 kBaud ohne Probleme - schreib' ich dann in dem Thread in der Lobby was dazu, wenn's interessiert

ich werde dem das noch mal unter die Nase reiben, dass er die SW von Dir mal kompilieren soll, wie gesagt, der hat den Kram eh' installiert und kennt sich damit aus, da muss ich nicht auch noch mit JDK und mavem usw. anfangen....

Super, vielen Dank!

ich habe jetzt mal nen Baudratenquarz auf mein Board gelötet, auf 230400 gestellt, und die SW so geändert, dass sie 100% mDMX-konform ist, also Startbyte, Framesize-Byte (wird ausgewertet und Framegröße entsprechend gesetzt), Payload, Blockende, danach wird 5A C1 A5 als Bestätigung gesendet...

funktioniert auch wunderbar im Terminal sowie mit AtmoWin (da halt mit 115200), aber Deine SW spricht das irgendwie nicht an...

muss dazu Puredata installiert sein...? - das hatte ich mal deinstalliert, und z.Zt. ist der Server down, ich kann das nicht runterladen...

das ist doch nur für die Bedienoberfläche, oder..? - also das Teil an sich läuft (diesmal sogar recht flüssig), sieht so aus:

ist das nun schon so, dass er den Empfänger-Port anhand der Rückmeldung erkennt...? - oder ist der fest..? - Bei mir hängt das Teil an Com2... ich finde in diesem Log auch keine Meldung, also dass er nen Comport sucht oder nicht findet o.ä.

ja, sag' doch mal Bescheid, ob's am fehlenden Puredata liegt oder falscher Comport o.ä. - Du schickst aber nun schon 512 Byte mit Kennung 0xA2 raus, oder...? - die "inoffiziellen" Framegrößen habe ich noch nicht drin in der Empfangsroutine...

Zum Beispiel mit:

http://technet.microsoft.com/en-us/sysinternals/bb896644

Kann man den Verkehr auf dem Com-Port mitschneiden. Hab ich früher öfter genutzt und zum Teil recht lange gesucht bis man eine funktionierende Freeware hatte. Funktioniert IMHO auch bis Windows 7.

Iopodx: Danke, hab's mal angesehen - muss ich mir bei Gelegenheit mal genauer angucken, wie das so funktioniert...

ja, das File hatte ich nicht geändert, ich bin einfach davon ausgegangen, dass das nun ne Version wäre, die Mini-DMX ausgibt...

habe ich jetzt mal gemacht, bekomme da aber Fehlermeldung:

Zitat

INFO: Output created: class com.neophob.sematrix.output.MiniDmxDevice, Layout: HORIZONTAL
14.09.2011 11:58:00 com.neophob.sematrix.output.minidmx.MiniDmxSerial <init>
INFO: Initialize miniDMX lib v1.0
WARNING: RXTX Version mismatch
Jar version = RXTX-2.2pre5
native lib Version = RXTX-2.1-7
14.09.2011 11:58:00 com.neophob.sematrix.output.minidmx.MiniDmxSerial <init>
INFO: open port: COM2
14.09.2011 11:58:02 com.neophob.sematrix.output.minidmx.MiniDmxSerial openPort
WARNUNG: Failed to open port COM2: java.lang.IllegalArgumentException: data lenght must be 768 bytes!

Alles anzeigen

Heisst das nun 1. (fett markiert) dass mein Java ne falsche Version ist, soll ich das updaten?! - oder irgendwas wegen der Framesize 768 Bytes (ebenfalls fett markiert)...? - ich habe meine sw. schon mal so angepasst, dass sie eben 768 Bytes empfängt, wenn der Header != A0, A1 oder A2... was sendest Du denn nun eigentlich für diese Framegröße, A3 oder B0...?

Oder liegt der Fehler ganz woanders...?

wie meinst Du das mit dem 64b Windows, hast Du eins über...?

Da sind wir schon mal nen Schritt weiter...

jetzt grast er nicht mehr alle Com-Ports ab, sondern bleibt bei Com2 "hängen" und öffnet den - sagt aber dann, dass kein Ping zurück kommt...?!?

wenn ich die Meldung oben (also die erste markierte im Log, Bild unten) richtig verstehe, dann schickt er zum Pingen ja so nen Frame mit 768 Byte...? - ich habe das noch mal im Terminal überprüft, meine SW funktioniert, wenn ich 5A, B0, dann 768 Byte Nutzdaten und A5 hinterher schicke, kommt ne positive Rückmeldung.... (5A C1 A5)

beim Pingen sendet er wohl auch was - ich habe zwei LEDs zum debuggen dran, eine blinkt, wenn der Startcode (also hier 5A B0) empfangen wurde, die andere beim Blockende-Byte A5

die erste blinkt auch (Startcode empfängt er also), er empfängt auch Nullbytes (der nach dem starten zufällige Inhalt des RAMs wird gelöscht) - aber dann anscheinend ne falsche Framegröße oder das A5 nicht, die 2. LED blinkt nicht (die zeigt eben an, wenn der Frame komplett durch ist) - und sendet deswegen auch die Bestätigung nicht...

hier noch mal das Log, nach dem Ping (also wenn dann das Bild kommt) wird gar nix mehr gesendet, Portmon zeigt da auch nichts mehr an:

was das mit dem Create Frame with Size da unten zu bedeuten hat, verstehe ich leider nicht, aber da steht nicht 768...? - liegt's evtl. da dran..?

P.S.: Nur zur Info: ich habe zum testen (wollte mal sehen, ob das mit Paylod 512 geht) mal ne andere Größe eingestellt:

#=========================
#settings for minidmx
#=========================
minidmx.resolution.x=8
minidmx.resolution.y=8

da macht er die Anzeige am Bildschirm auch so, aber im Log steht

Zitat

SCHWERWIEGEND: Unable to initialize output device: MINIDMX
java.lang.IllegalArgumentException: Unsupported Payload size defined!
at com.neophob.sematrix.output.minidmx.MiniDmxSerial$MiniDmxPayload.getDmxPayload(MiniDmxSerial.java:113)

Da kann er dann anscheinend nicht die passende Framegröße zu den 8x8 Pixeln zuordnen...?

Zitat von michuNeo

ist halt schwierig ohne zu testen.

Dafür bin ja ich da! - und danke, dass Du Dir die Mühe mit dem ganzen Umbauen machst...

Zitat von michuNeo

was aber sein kann, ist dass irgend ein buffer zu klein ist ??

k.A., wäre das dann im Java..? - ich habe zwischendurch mal bisschen mit Processing (das basiert doch auch auf Java?) rumgespielt, da meckert er auch irgendwas mit zu großem Array, wenn ich eins mit 515 Byte (eben für mini-DMX) ausgeben will...

aber anscheinend geht das jetzt mit dem Ping, zumindest positive Rückmeldung!

die Leds sind dann nicht mehr schwarz (so wie vorher, wohl die Nullbytes aus dem Ping), sondern so grün/blau/violett, kann das schon ne ausgegebene Animation sein...? - was sollten die denn eigentlich anzeigen, das grüne Gewaber oder den Graustufen-Toroid...? - ich nehme an, zweiteres, so wie am Bildschirm halt auch, also wie der emulierte Output...?

anscheinend ist nun aber ein anderes Problem nach dem Setup, wegen dem die Animation dann auch stoppt und nix mehr weiter ausgegeben wird, siehe hier:

Zitat

INFO: Initialize MiniDMX lib v1.0
15.09.2011 16:12:05 com.neophob.sematrix.output.minidmx.MiniDmxSerial <init>
INFO: MiniDMX payload size: 768
WARNING: RXTX Version mismatch
Jar version = RXTX-2.2pre5
native lib Version = RXTX-2.2pre4
15.09.2011 16:12:06 com.neophob.sematrix.output.minidmx.MiniDmxSerial <init>
INFO: open port: COM2
15.09.2011 16:12:08 com.neophob.sematrix.output.minidmx.MiniDmxSerial waitForAck

INFO: #### Reply size: 3 bytes ###
15.09.2011 16:12:08 com.neophob.sematrix.output.minidmx.MiniDmxSerial <init>
INFO: found serial port: COM2
15.09.2011 16:12:08 com.neophob.sematrix.output.minidmx.MiniDmxSerial waitForAck

INFO: #### Reply size: 3 bytes ###
15.09.2011 16:12:08 com.neophob.sematrix.output.MiniDmxDevice <init>
INFO: ping result: true
15.09.2011 16:12:08 com.neophob.sematrix.output.emulatorhelper.InternalDebugWindow <init>
INFO: create frame with size 532/296
15.09.2011 16:12:08 com.neophob.sematrix.output.emulatorhelper.InternalBuffer setup
INFO: create frame with size 532/306
15.09.2011 16:12:08 com.neophob.PixelController setup
INFO: --- PixelController Setup END ---
Exception in thread "Animation Thread" java.lang.IllegalArgumentException: convertBufferTo24bit error, data lenght must be 768 bytes!
at com.neophob.sematrix.output.minidmx.MiniDmxSerial.convertBufferTo24bit(MiniDmxSerial.java:531)
at com.neophob.sematrix.output.minidmx.MiniDmxSerial.sendRgbFrame(MiniDmxSerial.java:330)
at com.neophob.sematrix.output.MiniDmxDevice.update(MiniDmxDevice.java:81)
at com.neophob.sematrix.output.PixelControllerOutput.update(PixelControllerOutput.java:64)
at com.neophob.sematrix.glue.Collector.updateSystem(Collector.java:262)
at com.neophob.PixelController.draw(PixelController.java:137)
at processing.core.PApplet.handleDraw(PApplet.java:1631)
at processing.core.PApplet.run(PApplet.java:1530)
at java.lang.Thread.run(Unknown Source)

Alles anzeigen

P.S.: *Evtl.* unabhängig von dem hier für Dich auch interessant...?

Ach, k.A. ob Du das nachträglich editierte P.S. noch mitbekommen hast...?

das war etwas falsch ausgedrückt, eigentlich passt das für hier auch ganz gut - wie gesagt, diesem Server ist es egal, wo die Daten her kommen, falls das hier mit dem mini-DMX nicht hinhauen sollte, wäre ja evtl. *da* ne "universelle" Schnittstelle..?

also, ich kenne mich mit sowas ja nicht aus, aber evtl. wäre es einfacher, nur die RGB-"Rohdaten" auf diesen Socket zu schicken..?

der Server empfängt die da wie gesagt, schaut nach, welche mDMX-Framegröße passt, füllt ggfs. den Rest auf und gibt das Ganze dann als mDMX aus - muss man sich also keine weiteren Gedanken machen, nur Frames auf das Teil schicken... geht da auch recht schnell und mit beliebigen Baudraten, weil er keinen VCP benutzt, sondern den d2xx-Treiber für den FT232 - erst wollte er das ja auch in Java machen, nun doch in C, eben wegen so Sachen wie Einschränkungen in der Wahl der Baudrate etc. bei Java...

ich denke bei sowas ja gerne "universell/global/opensource/community", es *wäre* (in der Praxis funktioniert hat sowas hier selten :D) eben ganz cool, wenn man da irgendwo ne "universale" gemeinsame Schnittstelle hätte, an der versch. Steuer-SW und Matrixen zusammen arbeiten könnten - so wäre es dann möglich, dass man meine Matrix mit Deiner SW steuert, und - wenn es nen Server dafür gibt - auch Deine Matrix über die SW meines Kumpels, andere Leute könnten ganz einfach noch weitere Steuer-SW in Flash, VisualBasic oder wasauchimmer schreiben...

aber das ist dann wohl wieder zu viel Aufwand (v.a. eben den Server zu schreiben, der das dann an Arduino mit Deinem Protokoll weitergibt), und tatsächlich benutzen wird es kaum jemand.... war nur so ein Gedanke... - zumindest *etwas* "universeller"/für Bastlerprojekte leichter nutzbar wird es nun ja schon durch das erweiterte Mini-DMX...

EDIT: Zu oben noch was: Zumindest einen Frame schickt er raus, bevor er stehen bleibt - beim Ping wird die Matrix kurz schwarz, dann kommt wieder dieses grünblauviolette Bild, lt. meinen Debug-LEDs sind 2 Frames empfangen, der Ping, und dann noch einer...