Nicht für die Modelleisenbahn, sondern für einen Doktorhut.
Simuliert das Lichtbogenschweißen. Mittels ATtiny13.
Ansonsten dasselbe, was man auch aus China kaufen kann.
Nur 1-kanalig und ziemlich lausig, was den Ruhestrombedarf angeht.
An PB4 (Pin 3) ist eine weiße LED ohne Vorwiderstand nach Masse (Pin 4)
angeschlossen.
Gespeist wird der Controller durch 4 NiMH-Akkus, also nominell 4,8 V.
Zusätzlich ist via Koppelkondensator ein kleiner Lautsprecher angeschlossen,
um ein „echtes“ Knistergeräusch zu haben.
Alle anderen Pins sind unbenutzt bzw. frei zur ISP-Programmierung.
Siehe Archiv.
Der C-Quelltext ist gerade mal 33 Zeilen lang.
Der meiste Kode und die größte Rechenlast entsteht durch das Einbinden
von rand() aus der Standardbibliothek.
Um Besucher oder Kinder in einem Verkehrsgarten den richtigen Weg zu weisen,
sind einander verkettete LEDs (in Pfeilform) optimal,
wenn sie nicht zufällig blinken, sondern in Kette an- und ausgehen.
Die vorliegenden Module (Einzelpfeile) habe eine Speisespannung
von 5..12 Volt.
Da nicht nur ein einzelner Lichtpunkt durchlaufen soll, scheidet
eine Lösung mit 4017
(dekadischer Zähler mit dekodierten Ausgängen) aus.
Hingegen bietet sich der 4015
(2x 4-bit-Seriell-Parallel-Schieberegister) an.
Mit 4093 als Taktgenerator.
Schaltplan
Das erste 4093-Gatter generiert den Schiebetakt, mithin die Zeit
von einer LED zu nächsten, etwa 200 ms.
Das zweite 4093-Gatter generiert die Hell- und Dunkelzeit,
über Dioden entkoppelte zwei Potenziometer getrennt einstellbar,
im Sekundenbereich.
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:
Wenige billige Bauelemente, ohne Mikrocontroller-Programm
Weiter Speisespannungsbereich ohne Spannungsregler,
Stabilisierung wegen der Zeitglieder erforderlich
Wenn 6 Ausgänge genügen, dann kann man vorteilhaft einen 8-beinigen
Mikrocontroller verwenden. (Hochvolt-Programmiergerät steht zur Verfügung.)
Hier tat es ein
ATtiny13,
der gerade in der Bastelkiste herumlag.
Aus an dessen Ausgänge müssen Treibertransistoren,
diesmal in Emitterschaltung und mit Basisvorwiderständen.
Außerdem sollte ein Festspannungsregler
(78L05)
vorgesehen werden,
wenn die LEDs mitsamt der Schaltung aus 12 V versorgt werden sollen.
Schaltplan
Die Firmware ist so simpel,
dass ich sie diesmal in Assembler erstellt habe.
Nicht avrasm2,
sondern gnu-assembler.
Dadurch lassen sich in speziellen Sections die Fuse-Werte
für den Programmer ablegen.
Siehe Quelltext!
(Der Gebrauch der lokalen Marken
mag etwas gewöhnungsbedürftig sein.)
Fließende Übergänge (per
PWM)
lassen sich nur mit der
Mikrocontroller-Lösung realisieren.
Für den Modellbau sollte eine blaue Rundumleuchte im Maßstab 20:1 her.
Klar, dass man so ein Ding mit 7 mm Fußdurchmesser nicht mehr mit
Lampe und motorisiertem Reflektorspiegel bauen kann. Schade!
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/RESET unzureichend!
Schon daher ist von so einer Lösung abzuraten.
Charliplexing führt zur Einsparung eines Portpins
und damit zur „Schonung“ des Reset-Anschlusses zur ISP-Programmierung.
Jede LED kann antiparallel-zweifarbig sein.
Mit 14 SMD-LEDs Bauform 0603 und 14 mm Platinendurchmesser
ist dieser Entwurf sogar einigermaßen „handlich“, aber auch eher für Modelle
im Maßstab 10:1 oder solide Gartenzwerge:
Mit 0,3 mm Leiterzugbreite und 0,3 mm Abstand (Clearance)
ist das Layout zu Hause geradeso ätzbar.
Die Durchkontaktierungen sind für 0,3 mm Bohrdurchmesser
vorgesehen, das erfordert eine Tischbohrmaschine.
Die Bauelemente sind handelsüblich (bspw. bei Reichelt),
wenn man die SMD-Dioden querkant auflötet.
Seitlich abstrahlende LEDs wären natürlich besser.
(Der Entwurf benötigt keine extra links- und rechtsstrahlenden LEDs;
ggf. muss die Firmware für den korrekten Umlaufsinn angepasst werden.)
Der „riesige“ SMD-Mikrocontroller kann im aufgelöteten Zustand
per ISP programmiert werden.
Hochvolt-Programmierung ist trotz Verwendung von
RESET nicht erforderlich!
Weil der Analogeingang auch ohne Reset-Deaktivierung funktioniert.
In Grenzen natürlich.
Auch hier wurde auf Charliplex gesetzt.
Schaltplan
Hier habe ich auch mal die Platine geroutet, das Ergebnis ist hier zu sehen:
Platinentwurf und Bestückung (Vorder- und Rückseite)
Die Umlaufrichtungsumschaltung erfolgt hier durch — RESET!!
Oder Einschalten.
Denn der Mikrocontroller kann die Reset-Ursache finden
und im EEPROM
einen Taktteiler realisieren.
Der Widerstand R1 drosselt schließlich die Umlaufgeschwindigkeit.
Dann liest der A/D-Wandler einen Wert kleiner 0x3FF.
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:
Die aktuellen Farbeinstellungen werden nicht
im Mikrocontroller für autonomen Betrieb gespeichert.
Der USB-Betrieb erfordert unter Windows einen Treiber.
HID wäre viel bequemer, zumindest unter Windows.
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.
Screenshot des Windows-Programms
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 hiermeine 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:
Baustellenampel: Zwei Ampeln rot-gelb-grün
Baustellenampel mit Einmündung oder Abzweig: Drei Ampeln rot-gelb-grün, passend für dusseliges Ebay-Angebot
Fußgängerquerung: Zwei Ampeln rot-gelb-grün + zwei Ampeln rot-grün
Fußgängerquerung mit Knopf: Zwei Ampeln rot-gelb-grün + zwei Ampeln weiß-rot-grün (weiß ggf. als Countdown-Zähler)
Als Einzel-Ampel gab's das bei Playmobil
mit mir unbekanntem Schaltschema und ohne „Grün kommt“-Anzeige
Kreuzung ohne Fußgänger: Vier Ampeln rot-gelb-grün
Kreuzung mit Fußgängern: Vier Ampeln rot-gelb-grün, acht Ampeln rot-grün
Dreiseiten-Baustellenampel mit Detektor für jede Richtung⚓
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.
Energie sparende Fußgängerampel mit flotter (6 s) Reaktion auf den Knopf für Fußgänger (wünschenswert, in Deutschland nie gesehen)
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.
