Würfel auf Sparsamkeit trimmen

Wuerfler schrieb:
> Da ich den IRQ0 als Ausgang für eine LED verwendet habe, scheine ich den
> Attiny lediglich in den Idle-Modus schicken zu können.
> Da er aus Power-Down/Standby nur durch den IRQ0 aufgeweckt werden kann.

Wenn das so ist, dann wäre die einzig sinnvolle Maßnahme das 
umverdrahten dieses Pins.

Du kannst ihn einfach komplett ausschalten und mit dem Taster 
einschalten, der Attiny hält dann über einen Mosfet die 
Spannungsversorgung und schaltet sich danach wieder komplett ab.

Wuerfler schrieb:
> Da er aus Power-Down/Standby nur durch den IRQ0 aufgeweckt werden kann.

Nein.

Er kann mit allen PCINT (PB0..7) aufwachen.

Und der ATtiny2313A kann mit allen 18 IOs aufwachen.

Peter Dannegger schrieb:
> Wuerfler schrieb:
>> Da er aus Power-Down/Standby nur durch den IRQ0 aufgeweckt werden kann.
>
> Nein.
>
> Er kann mit allen PCINT aufwachen.

Und mit Reset auch!

Wuerfler schrieb:
> Dann bedeutet:
> Seite 31 im Datenblatt
> "Note 2. For INT0, only level interrupt.",
> das er mit allen Interrupts (INT0,INT1,PinChange) aufwachen kann?
>
> Das würde ich mir wünschen

Nun, ich würde mir wünschen daß du lernst, Datenblätter zu lesen.
In meinem PDF für den ATtiny2313 gibt es auf Seite 34 eine Tabelle 
"Active Clock Domains and Wake-up Sources in the Different Sleep Modes."

Die ist doch wohl eindeutig, oder?


XL

Wuerfler schrieb:

> Ich möchte einen Würfel welcher mti einem Attiny2313 arbeitet möglichst
> energiesparsam realisieren.

Hmm, ich überlege gerade, wie mann ein solches Gerät
wohl auf Sparsamkeit trimmt???
http://www.jassshop.ch/shop/KategorienBilder/wuerfel.jpg

Wuerfler schrieb:
> Der Power-Down Mode wird in der ISR von T1 Aktiviert, ich komm jedoch
> nicht mehr raus.

Das ist völlig korrektes Verhalten.
Um Sleep zu beenden muß ein Interrupt ausgeführt werden. Blöd nur, wenn 
man bereits in einem Interrupt ist. Der AVR kann ja keine nested 
Interrupts.

Generell ist das Programm maximal dämlich^Wungeschickt. Nix von dem was 
da in den ISR steht, gehört auch dahin. Das sollte alles nach main() und 
die ISR sollten gerade mal ein Flag setzen (Timer) bzw. gar nix tun (Pin 
Change).

Außerdem würde ich darüber nachdenken, den µC per Reset aufzuwecken. 
Dann ist seine erste (und einzige) Funktion, zu zählen bis die Taste 
losgelassen wird. Dann das Ergebnis anzuzeigen und den Timer zu starten. 
Und wenn der Timer den Timeout signalisiert, die LEDs abzuschalten und 
sich schlafen zu legen.

Noch besser aus Sicht der Verbrauchsminimierung wäre, den µC per 
Einschalter zu starten. Dann überbrückt er den Einschalter mit einem 
Transistor oder MOSFET und schaltet sich am Ende komplett aus.


XL

Axel Schwenke schrieb:
> Außerdem würde ich darüber nachdenken, den µC per Reset aufzuwecken.

Das ist ziemlich tricky. Der Würfel soll ja nicht dunkel bleiben, 
solange man drückt, also braucht man zusätzlichen Schaltungsaufwand. 
Auch soll er nicht durch Prellen beim Loslassen wieder resetten.
Also besser sein lassen.

Der PCINT funktioniert einwandfrei, wenn man es richtig programmiert.
Z.B.:
Beitrag "AVR Sleep Mode / Knight Rider"

Coder schrieb:
> Ich habe ebenfalls Eindruck, dass der TO bei den LEDs viel Strom
> "verbraucht".

Der Stromverbrauch ist überhaupt kein Problem, die LEDs müssen ja nicht 
ewig leuchten. Ich schalte sie nach 25s aus.

Hier mal mein Würfel mit AT89C2051:

Beitrag "Re: Problem Zufallsgenerator"

Da mußte ich den Reset nehmen, der hatte leider keinen PCINT.
Kostet dann eben 4 Bauteile zusätzlich.

Peter Dannegger schrieb:
> Coder schrieb:
>> Ich habe ebenfalls Eindruck, dass der TO bei den LEDs viel Strom
>> "verbraucht".
>
> Der Stromverbrauch ist überhaupt kein Problem, die LEDs müssen ja nicht
> ewig leuchten.

In der Tat.

Obligatorische Anekdote: ein solcher "elektronischer Würfel" war das 
erste meiner Elektronikprojekte mit IC. TTL. Richtiges TTL. 74 ohne 
irgendwelche Buchstaben in der Typbezeichnung (also im Prinzip, real 
waren es D174, D100 & Co).

Die größte Herausforderung war ein Oszillator, der nach und nach 
langsamer wurde. So konnte man den Würfel "austrudeln" sehen.

Das Problem des Stromverbrauchs war ganz einfach gelöst: der "Würfeln" 
Taster war der Einschalter. Nach dem Einschalten lief das Ding los, 
wurde langsamer, blieb stehen. Und wenn man seine Zahl abgelesen hatte, 
ließ man den Taster los und der Stromverbrauch war wieder 0.


XL

Ich denke das Stromsparen bezieht sich auf den Zeitraum, wenn der Würfel 
nicht gebraucht wird. Also einfach POWER_DOWN und vorher die LED's 
ausschalten reicht vollkommen. Und Ja, man kann mit jedem Pin ein 
Interrupt zu Aufwecken auslösen.

Ich habe selbst einen Würfel konstruiert und gebaut, der mit 
Charly-Plexing arbeitet. Als Versorgung werden zwei Mignon-Zellen 
verwendet. Es leuchten dann maximal 2 LED's gleichzeitig. Bei Low-Power 
LEDs sind das 4mA. Nach 30 Sekunden geht das Ganze auf "Power Down". 
Berechnen wir doch mal die Haltbarkeit der beiden Zellen wenn wir ein 
Stunde am Tag Dauerwürfeln. Die LEDs brauchen in Schnitt durch das 
4-fache Plexing 1,75 mA. Eine Mignonzelle hat eine Kapazität vom ca. 
2800 mAh. 2800 mAh / 1,75 mA sind 1600 Stunden. Bei einer Stunde am Tag 
sin das 1600 Tage oder fast 4,5 Jahre. Das finde ich Sparsam genug. Für 
eine passive LCD-Anzeige sehe ich keinen Bedarf.

P.S.: Ich bin mit einem ATtiny13A, 7 LEDs, 1 Taster und 3 Widerständen 
(zwei für die gleichzeitigen LEDs und einen Widerstand für den 
Reset-Pullup) ausgekommen.

Zur Schaltung:

Hardware:
Normalerweise reicht auch ein ATTiny13A, wenn man die beiden LEDs die 
sowieso immer zusammen leuchten über einen PIN schaltet. Durch 
Charly-Plexing ist sogar ein zweifarbiger Doppel-Würfel möglich.

Software - Programm in Interrupt-Routine:
Es wird empfohlen sich in einer Interrupt-Routine so kurz wie möglich 
aufzuhalten. Bei dir sehe ich das Hauptprogramm in der 
Interrupt-Routine.
Tobe dich lieber in der Main-Schleife aus. Für das Auslösen des Würfelns 
geht es auch problemlos ohne Interrupt. Der Interrupt wird dann nur noch 
zum Aufwecken gebraucht.

Software - Zufallszahl:
Die "rand()" Funktion ist nicht optimal für eine Zufallszahl. Besser man 
benutzt die Dauer des Tastendrucks um einen echten Zufall zu bekommen. 
Dafür einfach eine Zähler schnell hochzählen, solange eine Taste 
gedrückt wird. Dabei aber nicht beim Hochzählen zurücksetzten, wenn es 
mehr als 6 ist. Das kostet Zeit und macht den Zufall "unwuchtig". Besser 
beim Loslassen durch 6 teilen und sich den Rest angucken.

P.S.: Wer hätte gedacht, das so ein bisschen Würfeln eine Wissenschaft 
ist ;-)

Uwe K. schrieb:
> Dabei aber nicht beim Hochzählen zurücksetzten, wenn es
> mehr als 6 ist. Das kostet Zeit und macht den Zufall "unwuchtig". Besser
> beim Loslassen durch 6 teilen und sich den Rest angucken.

Allerdings geht 256 durch 6 nicht auf. D.h. es gibt auch hier eine 
Verteilung, die nicht rein zufällig ist. Die Zahlen 1-4 werden so um gut 
2% bevorzugt.

Uwe K. schrieb:
> Dabei aber nicht beim Hochzählen zurücksetzten, wenn es
> mehr als 6 ist. Das kostet Zeit und macht den Zufall "unwuchtig".

Man kann die Taste auch in einem Timerinterrupt abtasten und hochzählen, 
dann ist jeder Wurf gleich warscheinlich.
Eine kleine Unwucht ergibt sich durch die Latenz von 1..4 Zyklen. Wen 
das stört, der kann den Interrupt in Assembler schreiben und die Latenz 
kompensieren.

Die menschliche Drückdauer liefert einen sehr guten echten Zufall, da 
das Gehirn völlig asynchron zum CPU-Takt ist.

Alexander Schmidt schrieb:

> Allerdings geht 256 durch 6 nicht auf.

Stimmt. Das ist bei einem Integer aber kein Problem mehr. Einen Integer 
zu füllen dauert ein wenig. Das ist auch nicht perfekt, da die 5 und die 
6 zu kurz kommen. Da es aber nur alle 10922 Durchläufe passiert, sollte 
der Fehler (0,01%) tolerierbar sein.

Uwe K. schrieb:
> Stimmt. Das ist bei einem Integer aber kein Problem mehr. Einen Integer
> zu füllen dauert ein wenig. Das ist auch nicht perfekt, da die 5 und die
> 6 zu kurz kommen. Da es aber nur alle 10922 Durchläufe passiert, sollte
> der Fehler (0,01%) tolerierbar sein.

Also eine 16-Bit-Variable. Ein ATmega oder ATtiny muss Operationen mit 
16-Bit-Variablen in mehreren Takten rechnen.
Ich bin mir nicht sicher, ob bei einem Überlauf des unteren Bytes mehr 
Takte gebraucht werden, dann würde es wieder eine "Unwucht" geben.

Alexander Schmidt schrieb:
> Allerdings geht 256 durch 6 nicht auf. D.h. es gibt auch hier eine
> Verteilung, die nicht rein zufällig ist. Die Zahlen 1-4 werden so um gut
> 2% bevorzugt.

Ich muss mich zuerst entschuldigen, ich hab den Thread nicht ganz 
durchgelesen.
Das genannte Problem hatte ich aber schon mal und dann so gelöst, dass 
Ergebnisse zwischen 252 und 255 einfach verworfen werden. In diesen 
Fällen wird "neu gewürfelt".

Alexander Schmidt schrieb:
> Also eine 16-Bit-Variable. Ein ATmega oder ATtiny muss Operationen mit
> 16-Bit-Variablen in mehreren Takten rechnen.
> Ich bin mir nicht sicher, ob bei einem Überlauf des unteren Bytes mehr
> Takte gebraucht werden, dann würde es wieder eine "Unwucht" geben.

Das ist ein berechtigter Einwand. Ich habe deshalb ein Testprogramm 
geschrieben (GCC) um die Zeit beim Überlauf zu messen.

Deine Befürchtung hat sich nicht bestätig.

Sowohl der 8-Bit überlauf (255->256) noch der Gesamtüberlauf (65535->0) 
hat keine längere Bearbeitungszeit benötig. Die Zeit die zum hochzählen 
benötigt wird ist immer gleich.