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.
Eine beliebte Spielerei mit LEDs sind Modell-Ampeln. Dabei steht eher das Lernen der Mikrocontroller-Anwendung im Vordergrund als die Ansteuerung der LEDs. Folgende Fälle erscheinen regelmäßig:
Prinzip: In Ruhe haben alle Seiten Rot. Nur eine Seite bekommt Grün. Der Mikrocontroller realisiert Mindestzeiten für die Übergänge. Sowie dass bei permanenter Aktivierung der Detektoren jede Richtung einmal drankommt.
Realisierung: Entgegen von Verlautbarungen anderer werden Ampelsteuerungen
besser niemals als State Machine realisiert!
Wer soll denn derartigen Kode durchblicken?
Sondern als Sequenz, ggf. mit Unterprogrammen.
Also einfach Schalten — warten — schalten — warten — ggf. vezweigen — schalten — warten usw.
Richtig ist, avr-gccs _delay_ms() verwendet man besser nicht.
Sondern benutzt eine Routine die den Controller Strom sparend schlafen legt.
Steuerung von Ebay? Diese hat nur 3 Zustände.
Wer nicht programmieren will schließt die 3 Ampeln daran zirkulär versetzt an
und hofft, dass die Modell-Autofahrer nicht bei Grün drauflosfahren sondern die Autos,
die gerade Grün hatten, die Baustelle verlassen.
Und dass ja keiner bei Gelb fährt.
Ohne Detektor. Für eine Modellbahn reicht's.
Steuerung mit Mikrocontroller: Erfordert Mikrocontroller mit 9 Ausgängen und 3 Eingängen, bspw. ATtiny2313 oder PIC16F54. Kein Problem für jeden beliebigen Arduino. Mit Zeitmultiplex und „shared“ Sensoreingang 6 Ein/Ausgänge, also ATtiny13A. Zeitmultiplex erscheint vorteilhaft für die chinesischen Ampeln mit gemeinsamem Anodenwiderstand, um die Helligkeit untereinander etwas anzupassen (grün erscheint zu hell). Vorsicht mit dem treiberschwachen Reset-Anschluss, ggf. Transistor erforderlich. Nicht für PIC12F508, dessen Reset-Pin ist niemals Ausgang.
Aufbau: Zwei parallel geschaltete Ampeln rot-gelb-grün für Autofahrer, zwei parallel geschaltete Ampeln weiß-rot-grün für Fußgänger. Für Fußgänger weiß mit Aufschrift „kommt“, rot und grün mit Ampelmännchen oder Ampelfrau. Erfordert Mikrocontroller mit 6 Ausgängen und 1 Eingang, bspw. ATtiny24 oder PIC16F505. Bei Zeitmultiplex braucht man 5 Ausgänge und 1 Eingang (der ließe sich auch noch multiplexen, wenn man kein Hochvolt-Programmierergerät hat), also ATtiny13A oder PIC10F508. Die Funktion von Charlieplex ist nicht sichergestellt wegen unterschiedlicher Flussspannungen. Und erfordert Ampeln mit einzeln herausgeführten Diodenanschlüssen ohne Widerstand. Countdown-Siebensegmentanzeigen benötigen viel mehr Portpins.
| Zeile | Autos | Fußgänger | Zeit | Knopf abfragen? | Anmerkungen |
|---|---|---|---|---|---|
| 0 | aus | bis Knopfdruck | ja | ||
| 1 | ge | rt + „kommt“ | 4 s (von 0), 2 s (von 6) | unnötig | extra-langes Gelb wenn vorher Ampel aus (= ungewöhnliche Phase) |
| 2 | rt | 2 s | Rot-für-alle ist Pflicht | ||
| 3 | gn | 5 s | nein | Zeit je nach Straßenbreite und Klientel | |
| 4 | rt (ggf. + „kommt“) | 10 s | ja (lässt „kommt“ aufleuchten) | ||
| 5 | rt+ge | 1 s | |||
| 6 | gn | 15 s | je nach Verkehrsaufkommen | ||
| Wenn „kommt“ leuchtet springe zu Zeile 1 sonst zu Zeile 0 | |||||
Höchstwartezeit: Wenn's für Fußgänger gerade Rot wurde, haben Autofahrer ein Recht auf 15 s Grün. Mit diesen Zahlen liegt die Höchstwartezeit für Fußgänger bei 25 s, für Autofahrer bei 22 s, von Grün zu Grün (ohne Auszeit) bei 20 s.
