Arduino Boblight Sketch --> Verlorene Bytes

Wie sich herausgestellt hat, sind die letzten drei Bytes im Adalight Modus nicht fest, sondern hängen von der LED-Zahl ab.

Hier mal mein letzter Stand. --> https://gist.github.com/CReimer/21239b5551cd6b8bd1fb

Deinen Zählfehler habe ich umgangen, indem ich einfach nicht mehr zähle
Und das Prefixproblem ist auch weg. Die letzten 3 Bytes des Prefix werden einfach ignoriert.

Das ist so zwar verschwendete Bandbreite, aber die vorhandenen "Protokolle" sind eben so gebaut.
Im Idealfall hätte man exakt 1 Byte als Prefix. Spätestens nach dem zweiten oder dritten Frame spielt sich das dann sauber ein.

Schöner ist da das Sedu-"Protokoll". Da sind es nur 3 Bytes. 2 am Anfang und 1 am Ende. Das zweite am Anfang ist wieder mit Zusatzinfos versehen, die im Falle des Arduino wieder unnötig sind.
An das werde ich später meinen Sketch noch anpassen und dann komme ich auch nicht wirklich weiter bis die Chinesen meine LED Stripes endlich liefern.

Edit: Sedu ist ja noch schlechter. Das hat feste Bytelängen. Das kleinste ist 256 Byte. Wenn ich das jetzt richtig gesehen habe wird der Rest einfach mit Nullen gefüllt. Ich lasse es also beim Adalight Protokoll.

Zitat von chriszero

Für Hyperion ist auch schnell ein neues Device programmiert, sieht nicht sonderlich schwer aus. Ist wenn es vom Entwickler gemergt wird hat man auch kein hickhack mit patchen.

Möchte ich nicht. Es gibt so schon zu viele Varianten. Da muss wirklich nicht noch eine dazu.

Zitat von chriszero

Das adalight hat halt den Vorteil das die Anzahl der LED nicht im Sketch festgelegt ist.

Ich dachte daran, das im Sketch wieder zu "entschlüsseln". Dann kam mir aber der Gedanke, dass man dadurch immer noch nicht alles abgedeckt hat. Man muss der FastLED Library ja nicht nur die Anzahl der LEDs mitteilen, sondern auch den Controller. Und das nur damit die 3 Bytes Sinn haben die Konfiguration auseinander reißen...

Zitat von chriszero

Was mich noch stört an der Sache ist die serielle Verbindung, und das bei Zeiten von USB. Mich reizt ein Ambilight welches direkt den USB nutzt, da wäre massig Bandbreite da, selbst bei USB 1.1

Da wirst du wohl Abstand von den ATmega328 Boards nehmen müssen und da wird es dann aufwändig.
Die neueren Boards (oder auch der SPI des RPi) laufen mit 3,3V. Da reagieren die WS2812B aber noch nicht zuverlässig.

Keine Ahnung für was man den brauchen sollte. Ich würde das Teil sogar als gefährlich bezeichnen.
Da werden die Digitalausgänge des Teensy 3.x auf LAN-Kabel gelegt.

Der Teensy ist genauso gut wie jedes andere ARM basierte Entwicklerboard. Die Idee ist ja der direkte USB am Mikrocontroller ohne vorheriges wandeln nach Serial

Es geht auch mit Serial (FTDI vorausgesetzt). Man müsste aber wohl langsam auf 1 MBaud hochgehen, damit man nicht bei ~200 LEDs beschränkt ist.

Edit: Es geht wohl auch mit dem Uno indem man den 16U2 mit einer anderen Software versieht. Ich trau' mich aber nicht. https://github.com/NicoHood/HID

Ich bin von 100Hz ausgegangen.

Es haben sich drei eigentliche Probleme herauskristallisiert.

Problem 1: Der ATMega 16U2 auf den aktuellen Arduinos ist ungeeignet für einen konstanten Stream. Zumindest bei mir blockiert irgendwann das /dev/ttyACM0 Device. (Ausweg: Einen FTDI an den RX-Pin des Arduino hängen)
Problem 2: In chriszero's Sketch ist ein Zählfehler. (Ausweg: Chriszero's Fix hier aus dem Thread nehmen und dort aber '-1' weglassen oder meinen Sketch nehmen)
Problem 3: Boblight verzählt sich irgendwie. Sichtbar wird das durch flackern der LEDs. Falschfarben und durch das DEBUG Define in meinem Sketch. (Ausweg: Hyperion. Ein gefixtes Boblight wäre aber auch nicht schlecht)

Wegen Boblight: Ich habe mal die "Failed bytes" Meldung ausgeblendet, wenn es keine Fehler gibt. Das hier ist was übrig bleibt.

Failed bytes: 58
Failed bytes: 50
Failed bytes: 3
Failed bytes: 58
Failed bytes: 49
Failed bytes: 3
Failed bytes: 58
Failed bytes: 49
Failed bytes: 3
Failed bytes: 58
Failed bytes: 49
Failed bytes: 3
Failed bytes: 58
Failed bytes: 49
Failed bytes: 3
Failed bytes: 58
Failed bytes: 50
Failed bytes: 3
Failed bytes: 58
Failed bytes: 49
Failed bytes: 3
Failed bytes: 58
Failed bytes: 49
Failed bytes: 3
Failed bytes: 58
Failed bytes: 56
Failed bytes: 68
Failed bytes: 49
Failed bytes: 3
Failed bytes: 58
Failed bytes: 50
Failed bytes: 3
Failed bytes: 58
Failed bytes: 49
Failed bytes: 3
Failed bytes: 58

Edit: 150 Channels bzw. 50 RGB-LEDs.

6 Stelliger Prefix also müsste sich nach 156 Bytes alles sauber wiederholen.

Edit2: bei einem zweiten Versuch ergibt sich folgendes:

Failed bytes: 122
Failed bytes: 123
Failed bytes: 122
Failed bytes: 123
Failed bytes: 122
Failed bytes: 123
Failed bytes: 123
Failed bytes: 123
Failed bytes: 122
Failed bytes: 124
Failed bytes: 123
Failed bytes: 122
Failed bytes: 123
Failed bytes: 123
Failed bytes: 124
Failed bytes: 123
Failed bytes: 123
Failed bytes: 124
Failed bytes: 119
Failed bytes: 123
Failed bytes: 124
Failed bytes: 124
Failed bytes: 123
Failed bytes: 123
Failed bytes: 123

Edit3: Sieh mal an. Wenn ich bei boblight-X11 den Sync-Modus ausschalte "-y off" läuft es fehlerfrei. Jetzt muss ich nur noch herausfinden, was dieser Modus tut und warum es damit nicht funktioniert.

Edit4: Das kann man auch global in der Boblight.conf abschalten:

Zitat

allowsync
Allows sync mode when a client requests it, this setting is optional, the default is on.
When sync mode is on, a device gets woken up immediately when a client sends input to a light that that device is using, this works quite well with clients like boblight-X11 and boblight-v4l because the light updates are exactly synchronized to the client's input.
However when a client updates too frequently or too many clients are using one device, the device's output can become constipated and all hell will break loose.
Sync mode can also be disabled in boblight-X11 or boblight-v4l by using the "-y off "flags.
Sync mode doesn't work with sound devices, they run synchronized to the soundcard and can't be woken up early.

Eigentlich sollte Serial.readBytes unabhängig vom Buffer direkt in das 'leds' Array schreiben. Wenn das nicht schnell genug geht, weiß ich auch nicht.
Ich sage dem ja lese mir 150 Bytes in das Array hier.

Bei dir ist das etwas fummeliger aber mit Neopixel geht das so anscheinend nicht besser.

Nö, ich benutze einen FTDI.

Zitat von chriszero

Arduino hat einen 64Byte Großen Ringpuffer für Serial RX, der wird nicht schnell genug leergelesen, Hardware Flusskontrolle nicht verfügbar in den Arduino Libs (Xon/Xoff)

Das kann ich so bestätigen. Der Puffer ist bei mir schon ohne Syncmodus sehr häufig mit 62 Bytes gefüllt.

Zitat von TheChief

Vielleicht bist Du ja der erste, der 100Hz haben will?

Vielleicht verstehe ich den Sync Modus auch immernoch falsch, aber sollte das dann nicht sogar runter gehen auf die Display Wiederholrate? (im Fall meines Desktops 60Hz)

Zitat von TheChief

Weiss nicht, wie es beim UNO ist, aber wenn man einen FTDI an Pin 0 und 1 klemmt, sollte es dann nicht Serial1 sein in deinem Sketch?

Für mich sieht das aktuell so aus, als wären die einfach parallel. Der Uno hat nur ein Serial Interface.

Dann halten wir mal fest.

Wenn sich jetzt jemand neu ein DIY Ambilight aufbaut sollte er besser gleich zum Teensy greifen.
Ich habe jetzt auch schon darüber nachgedacht mir einen Teensy zu holen, aber es funktioniert ja mit meinem Arduino auch. (FTDI vorausgesetzt und abgesehen vom Sync-Modus)

Und extra deswegen nochmal 25€ Teensy + 5€ Levelshifter-Platine. Ich habe ja jetzt schon zusätzlich 5€ für eine FTDI Platine ausgegeben.