rand() aus der Standardbibliothek.
An den Ausgängen hängen npn-Emitterfolger ohne weitere Widerstände, um die Strom fressenden LEDs von den CMOS-Ausgängen zu bereiben.
Eigenschaften und Vorteile:
Fließende Übergänge (per PWM) lassen sich nur mit der Mikrocontroller-Lösung realisieren.
Daher eine Abfolge rundum angeordneter, hinreichend gerichtet abstrahlender
SMD-LEDs sowie eine Ansteuerung, die fließende Übergänge realisiert.
Also ganz klar ein Mikrocontroller-Problem.
Die LEDs können direkt am Controller betrieben werden,
da die Stromaufnahme nicht allzu groß ist.
Der Controller kommt fürs erste ins Fahrzeuginnere,
ein Einbau ins Zentrum der Rundumleuchte ist ziemlich fummelig
und erst in Kleinserie beherrschbar.
Hierzu wäre eine flexible Leiterplatte nötig.
Der erste Entwurf geht von einem Hochvolt-programmierten Mikrocontroller aus.
Dabei kann der RESET-Anschluss nur sinnvoll nach GND steuern.
Allerdings ist die High-Treiberfähigkeit von PB5/
Charliplexing führt zur Einsparung eines Portpins und damit zur „Schonung“ des Reset-Anschlusses zur ISP-Programmierung. Jede LED kann antiparallel-zweifarbig sein.
Dazu gibt es Eagle-Schaltpläne. Firmware wurde entwickelt, ist woanders.
Hier habe ich auch mal die Platine geroutet, das Ergebnis ist hier zu sehen:
Die Frage nun: Wer baut's?
Hier Eagle-Schaltplan und -Board. Firmware wurde dort entwickelt.
Die Umlaufrichtungsumschaltung erfolgt hier durch —
RGB-LEDs mit eingebautem WS2812-Controller haben einen Dateneingang und einen Ausgang zur Kaskadierung. Damit sind sie hervorragend für Lichtzeilen geeignet und ein beliebtes Bastelobjekt, vor allem für Ebay- und Alibaba-Einkäufer.
Zu ihrer Ansteuerung wird in jedem Fall ein Mikrocontroller benötigt.
An den bisher vorgefundenen, durchaus sehr pfiffigen Lösungen gab es zwei k.-o.-Kriterien:
Zwei Mini-Platinen, eine mit ATtiny45 und eine mit ATtiny85,
dienten als Ausgangspunkt.
Den USB-Bootloader micronucleus habe ich auf Teufel-komm-raus
nicht zur Funktion gebracht, also habe ich die V-USB-basierte Firmware
einfach „nackt“ aufgesetzt.
Ein treiberloses Windows-Programm mit 8 KByte Größe macht den Chip mit der LED-Kette bedienbar. Wie gewünscht findet keine Animation statt, sondern es werden einfach feste RGB-Werte eingestellt.
Die Firmware und Software mit Quellen (V-USB ist extra). Das HID-Protokoll ist recht simpel: Ein länglicher Feature-Report liest oder schreibt alle RGB-Werte (in WS2812-typischer GRB-Reihenfolge) vom bzw. zum Mikrocontroller. Ein zusätzlicher Output-Report von 4 Byte Nettodatenlänge adressiert ein GRB-Tripel zum Verändern. Der Mikrocontroller schreibt „im Hintergrund“ alle Datenänderungen in seinen EEPROM.
Dieser Aufbau mit dem 6-beinigen ATtiny9 oder ATtiny10 erforderte von Tim Böschke das V-USB unter 1 KByte zu pressen.
Das Bild zeigt meinen raumgreifenden Probeaufbau. Von den beiden WS2812 ist nur die blau leuchtende angeschlossen. Die rote LED dient zur Spannungsreduktion auf 3,3 V für den Mikrocontroller sowie als Stromanzeige. Der 10-kΩ-Widerstand verbindet 5 V mit D– zur Low-Speed-Geräteerkennung. Der Mikrocontroller selbst sitzt auf einem roten Stück Pappe, dessen Beinchen ich mit Einzeladern eines Abschirmgeflechts verlängert habe. Damit diese Verlängerungen insbesondere in der Programmierfassung handhabbar sind, sind an deren Enden abgeschnittene LED-Beinchen angelötet. Auch an den Enden des USB-Kabels von einer alten Computermaus habe ich derartige Beinchen angelötet. Das macht sich beim Einsatz auf Steckbrettchen so optimal.
Weil das Original auf Github keine HEX-Datei beigelegt hat (und für den Gelegenheitsbastler evtl. schwierig zu compilieren ist, weil leider die verwendete Versionsnummer von avr-gcc nicht dabei steht), habe ich hier meine Version mit HEX-Datei.
Und da steht beschrieben, wie ich's in den Chip hineinbekommen habe: Mit meinem eigenen Brennprogramm.
Schließlich habe ich noch ein Windows-Konsolenprogramm dazu geschrieben, mit dem man die LED per Kommandozeilenparameter (RGB-Wert wie in HTML, etwa #808000 für gelb) setzen kann. Um den Chip in der Schaltung mit der Firmware an libusb-0.1 zu binden, habe ich das Paket libusb-win32-bin-1.2.6.0.zip heruntergeladen und daraus das Programm inf-wizard.exe benutzt.
Da der ATtiny10 keinen EEPROM hat, kann dieser die letzte Einstellung nicht speichern. Beim Anstecken an USB bleibt die LED daher erst mal dunkel. Relativ einfach erscheint die Erweiterung auf bis zu 256 gleichfarbig leuchtende WS2812-LEDs durch schnelle Wiederholung der 24-Bit-Ausgabe wie im Artikel unten.
Da libusb unter Windows 10/64 nicht so recht zum Laufen zu bringen war, habe ich mich in WinUSB ausprobiert. Zunächst habe ich im Visual Studio holper-di-polter ein Beispielprogramm erstellt, welches schließlich auf die LED zugreifen konnte. Um den Quelltext MSVC6-kompatibel zu halten, habe ich die entsprechenden Include-Dateien aus dem Windows-10-WDK auf die wenigen notwendigen Zeilen zusammengekürzt und ins C++-Programm eingefügt. Und die winusb.dll dynamisch geladen, damit's trotzdem noch unter Windows 98 oder Windows 2000 funktioniert. Dementsprechend wurde auch libusb0.dll dynamisch geladen, um diese DLL auch unter Windows 10 nicht mehr vorhalten zu müssen.
Das „Unbekannte Gerät“ muss im Geräte-Manager mit dem Treiber „WinUSB“ verknüpft werden. Eine selbstgemachte INF-Datei (mit der eigenen Interface-GUID) ist nicht erforderlich; die Software kämmt einfach alle USB-Geräte durch. Dadurch klappt's auch ohne Code-Signing und/oder Reboot.
WinUSB ist im Gegensatz zu libusb deutlich einfacher in der Anwendung. Schade dass man libusb so unnötig kompliziert gestrickt hatte. Nun ja, man sollte nicht das SetupDi-Geraffel von Microsoft unverändert übernehmen, sonst wäre libusb wieder einfacher.
Hier ist es. Zum automatischen Laden von winusb (und Nutzung mit webusb) fehlt der Firmware Platz für die recht umfangreichen Deskriptoren. Das würde die Steuerung durch einen Web-Browser ermöglichen, heutzutage (2021) alles außer Firefox und IE.
Problem: Heutzutage werden miniaturisierte WS2812, die als Ardino-Gedöhns sattsam bekannten RGB-LEDs mit seriellem Interface, in Spulen von 800 Stück (Bandlänge 5 m, 160 LED/m, Abstand 6,25 mm) geliefert. Bei der Wareneingangskontrolle soll die Spule getestet werden. Die gängigen Arduinos streiken, ohne dass man im Buildprozess informiert wird warum: Zu wenig RAM für die übliche Implementierung! Es werden beim linearen Herausschieben aus dem RAM für 800 LEDs 3×800 = 2400 Byte RAM benötigt. Ein Arduino Uno hat aber nur 2 KByte RAM.
Deppen-Lösung: Man nehme einen 32-Bit-Controller.
Richtige Lösung:
Man wirft die 💩 Arduino-Software mitsamt 💩 Libraries über Bord
und macht eine angepasste, RAM sparende Lösung
gefälligst mit C++-Templates und nicht mit #define!
(Das zweite Jahrtausend ist schon lange vorbei, wir sind im dritten.)
Hier genügen 3 Bytes, um einfach die gleiche Farbe auf alle 800 LEDs zu repetieren.
Kurz und knapp: Ein WinAVR-Projekt. Als eigentliches Problem erwies sich die Stromversorgung der Spule: Bei Vollaussteuerung auch nur einer Farbe bricht die Spannung der „Schnecke“ im Innern auf knapp 2 V zusammen, was sich in seltsamen Verhalten und „Rotverscheibung“ bemerkbar macht. Dieses Testprogramm verwendet deshalb nur kleine Werte, und so funktioniert es wunderbar.
