Es sind die kleinen Dinge im Leben… In diesem Fall ein ATtiny85. Wobei ein ATtiny25 auch vollkommen ausreichen würde. Zur letzen Maker Faire brachte ich ja bereits meinen Würfel, ebenfalls mit einem ATtiny85 mit. Optisch halbwegs ansprechend, allerdings vom Programm her zu stromgierig. Vor dem letzten Stammtisch entschied ich mich gegen Mittag noch einmal eine neue Version davon zu bauen.
Viel braucht es nicht:
natürlich den ATtiny, vorzugsweise im Sockel, diesmal einen LiPo statt CR2023, 7 LEDs, ebensoviele Widerstände, einen Schüttelsensor und eine Buchse zum Laden des Akkus.
Wie bekommt man 7 LEDs angesteuert, wenn der ATtiny nur 8 Pins hat, davon 2 für Strom und einen zum Reset? 5 Pins bleiben einem, einer geht noch für den Schüttelsensor. Aber eben diese 4 Pins reichen völlig aus! Schon einmal die Anordnung der Würfelaugen genauer untersucht? In der Mitte ist bei jeder ungeraden Augenzahl ein Punkt, die horizontale nur bei der 6 besetzt. Ansonsten sind bei der 2 und 3 die Diagonale besetzt, bei 4, 5 und 6 alle Ecken. Bedeutet:
4 2 6 1 6 2 4
Logisch: 1 bei Augenzahl modulo 2 = 1, 2 bei Augenzahl ≥ 2, 4 bei Augenzahl ≥ 4 und 6 nur bei der 6.
Der LiPo hat bis zu 4V im geladenen Zustand, die LEDs arbeiten mit 20mA@2-2.2V. Reichen also 100Ω Widerstände.
___
(5) RST–|• |–VCC
3–| |–2
4–| |–1
GND–|___|–0
0 ist bei mir für den Schüttelsensor benutzt, da er einen Interrupt bietet. RST ist direkt mit VCC verbunden. VCC und GND an den Akku, der ATtiny steuert die LEDs direkt ohne Transistoren an, also die Masse auch mit den kurzen Beinchen der LEDs verbinden. Ansonsten kann man Pin 1-4 irgendwie den LEDs zuordnen, solange sie nach der obigen Abbildung gruppiert bleiben. Natürlich die Widerstände nicht vergessen.
Dazu der Schaltplan – Pin Nummern beachten! In meinem obigen Diagramm entsprechen die Ziffern den Pins PBx. Die Skizze orientiert sich an der Belegung meines Sketches, wobei PB1 und PB2 als Diagonalelemente getauscht werden können. Zum Flashen muss allerdings noch die Library in den hardware-Ordner verschoben werden, damit die Arduino-Umgebung auch für den ATtiny richtig kompiliert. Das Flashen geht nur mittels ISP.
Hallo Luca, woher bekommt man den Schüttelsensor ? Kannst du den Schaltplan und den Sketch auch noch veröffentlichen. Ich würde den Würfel gerne mit Azubis nachbauen.
Hallo Martin,
Schaltplan kommt, ebenso der Sketch, der liegt aktuell auf meinem iMac.
Schüttelsensoren habe ich noch genügend, könnte welche abgeben.
Schaltplan eingefügt, nicht ganz hübsch, aber zeigt die Verkabelung. Sketch ebenso hinterlegt.
Hallo Luca,
Folgendes Problem: Ich habe den Würfel nun nachgebaut und hardwaremäßig funktioniert soweit auch alles (Schüttel-Sensoren noch nicht da, deshalb vorerst durch Knopf ersetzt).
Aber die Software macht irgendwie zicken. Es würfelt nämlich immer dieselbe Zahl.
Durch einiges herumprobieren mir anderen Zufalls-Generatoren, uvm. ist mir aufgefallen, dass es durch den Sleep kommt, dass immer die gleiche Zahl kommt.
Wenn man den nämlich in der loop auskommentiert, würfelt der Würfel fröhlich Zufallszahlen vor sich hin.
Ich sitze jetzt bereits den ganzen Abend da dran und ich habe es nicht geschafft, den Code mit dem Sleep zum laufen zu bekommen.
Den Sleep weglassen ist leider keine Option, da meine Batterie länger als nur ein paar Tage halten soll…
Hallo Leandro,
welchen Software-Stand nutzt du denn? Den von GitHub oder aus der hier verlinkten ZIP? Als ich es das letzte Mal testete ging es noch, da muss ich ansonsten noch mal durchgucken. Probiere ansonsten einfach mal genau den anderen Sketch aus und berichte dann. Kann sein, dass ich die Software verschlimmbessert habe.
Beste Grüße
Luca
Hallo Luca,
beide Versionen funktionieren nicht gescheit…
Erstens würfelt der Würfel immer eine 6 und zweitens Blinkt er am Ende nicht (2. hatte ich durch Benutztung von delay() anstatt delayMicroseconds() behoben…)
Aber wie gesagt, egal wie ich den Zufallsgenerator implemetiere (mit millis(), PRNG, oder sonst was), irgendwie haut das alles nicht hin und die Zahl ist nicht wirklich zufällig. (Sprich es kommt immer die gleiche).
Und wie schon gesagt, ohne Sleep-Modus funktioniert alles einwandfrei…
Ich komm gerade einfach nicht weiter.
Vorstellbar wäre, dass der sleep-Modus irgendwas mit dem millis()-Timer anstellt, und er deshalb immer die gleiche Zahl anzeigt.
Grüße
Leandro
Hallo Luca,
wie steht’s?
Könnte es evtl. auch damit zu tun haben, dass ich nicht den PB0 (PCINT0) sondern den PBe (PCINT3) als Interrupt nutze? Ich denke zwar nicht, aber ich möchte es auch nicht ausschließen…
Ich denke immer noch, dass da irgendwas mit der Sleep-Lib nicht stimmt.
Grüße,
Leandro
Hallo Leandro,
tut mir leid, dass von mir so lange keine Rückmeldung kam.
also ausschließen möchte ich es nicht, dass es mit dem Interrupt zu tun hat (Frage wäre dann allerdings: warum?).
Ansonsten ersetze einfach den millis()%6+1 Aufruf durch random(6)+1. Das sollte auf Dauer immer klappen. Da ist allerdings der Nachteil, dass es Pseudo-Zufallszahlen sind, also wenn du ihn neu startest, hast du immer die gleiche Folge. Da du den Sensor an einem ADC-Pin hast, kannst du den auch zu Beginn als floating lassen und dann mittels randomSeed(analogRead(3)) den Zufallsgenerator etwas zufälliger machen.
Hoffe, dass du damit mehr Erfolg hast.
Luca