Würfel auf Sparsamkeit trimmen

[Wuerfler (Gast)]

Hallo,

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

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.

Ist dass soweit richtig?

Ist es eventuell besser ihn in diesem fall in Standby zu schicken, alle 
250ms hochzufahren und nachzusehen ob der Taster gedrückt wurde?

Kann ich ausser Analog-Comparator, Brown-Out, Refferenz-Aus, WDT-Aus 
noch tun um Energie zu sparen?

Danke

[Alexander S. (esko)]

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.

[Frank M. (frank_m35)]

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.

[Peter D. (peda)]

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.

[Route_66 H. (route_66)]

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!

[Coder (Gast)]

Wie viele uA verbraucht er mehr? Was benötigt die restliche hardware?

[Wuerfler (Gast)]

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, werde es nacher ausprobieren.

[Axel S. (a-za-z0-9)]

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

[Harald W. (wilhelms)]

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 (Gast)]

Ja es ist ein Attiny2313a,
Er sollte aufwachen können, tut er aber nicht, ich kann ihn Power-Down 
schicken, jedoch nicht wider aufwecken.

habe gelesen dass man sofort nach aufwachen externe Interrupts seperen 
soll und dass es einen Low-Level-Interrupt braucht um ihn zu wecken.
Zum Low-Level Interrupt find ich im Datenblatt leider nichts.

Kann ihn scheibar nicht mit Pinchange-Interrupt wecken:

#include <avr/io.h>
#include <avr/interrupt.h>
#include <stdlib.h>
#include <avr/sleep.h>

inline void Init()
{
//------------PORTS------------------------------------
  DDRB&=0xE0;  //Port B auf Eingabe
  
  PORTB&=0xE0;//Kein Pull-Up

  DDRD|=0x7F;  //Port D auf Ausgabe
  
  PORTD|=0x7F;//LED-Quelle, Kein Pull-Up
//-------------TIMER0------------------------------------
  TCCR0A|=0x02;  //CTC-Modus
  
  TIMSK&=0xf8;  //Timer 0 IRQ nicht möglich
  
  TIFR|=0x07;    //IRQ Flags löschen
//------------Timer1--------------------------------------
  TCCR1A&=0x0C;  //CTC-Mode
  
  TCCR1C&=0x3F;  //Kein Output-Compare
  
  TCNT1=0x0000;  //Startwert
  
  OCR1A=0x2000;  //Bis-Zählwert
  
  OCR1B=0x0000;  //Nicht genutzt
  
  ICR1=0x0000;  //Nicht genutzt
  
  TIMSK|=0x40;  //Compare Match A-IRQ
  TIMSK&=0x57;
  
  TIFR|=0xE8;    //Interrupts löschen
  
//----------PIN-CHANGE-IRQ------------------------------
  GIMSK|=0x20;  //PIN Change IRQ-Enable
  
  GIFR |=0x20;  //IRQ nicht löschen
  
  PCMSK0 |= 0x01;  //Pin-Change IRQ für PB0 auswählen
  
//----------Sparsamkeit-------------------
//5,13mA
  ACSR|=0x80;    //Analog-Comparator abschalten
//5,10mA
  //Brown-Out-Off hfuse = 0xD1:m
//5,06mA
  ACSR&=0xFB;    //Keine BG-Refferenz nutzen
//5,1mA
  //Watchdog über Fuses Ausschalten?
  
  //Digital input disable register
  
//---------System Starten-------------------

  sei();      //Globale IRQ Enable
}

int main(void)
{
  //-------Initialisierung------------------------------
  Init();
    while(1)
    {
    if(TIMSK==0x00) //Interrupts wieder enablen, falls Disabled
    {
      TIMSK|=0x41;
      GIMSK|=0x20;
    }
  }
}

ISR (PCINT0_vect)  //Jemand hat auf den Knopf gedrückt
{  
  GIMSK=0x00;    //Alle Externen Interrupts Disable
  TIMSK=0x00;    //alle Timer-Interrupts Disable
  uint8_t wertneu=0;
  uint8_t wertalt=0;
  //Schnelles Würfeln während gedrücktem Taster
  while (PINB & (1<<PINB0) )    
  {
    switch (rand()%6)
    {
      case 0: PORTD = 0x08; break;
      case 1: PORTD = 0x41; break;
      case 2: PORTD = 0x49; break;
      case 3: PORTD = 0x55; break;
      case 4: PORTD = 0x5d; break;
      case 5: PORTD = 0x77; break;
    }
  }
  //langsames Ausrollieren
  do{
    wertneu=rand();
    if(wertneu>wertalt)      //Der würfel läuft immer langsamer
    {
      wertalt=wertneu;
      TCNT0=0x00;    //Startzeit = 0
      OCR0A=wertneu;  //Zeit für neuen Zufallswert längere Zeit
      TCCR0B|=0x05;  //Prescaler=1024, Timer-Start
      do{
        ;
      }while(!(TIFR&(1<<OCF0A)));//Warten bis Timer abgelaufen
      TCCR0B&=0x30;    //Timer Anhalten
      TIFR|=(1<<OCF0A);  //Flag löschen durch 1-Schreiben
    }
    switch (rand()%6)
    {
      case 0: PORTD = 0x08; break;
      case 1: PORTD = 0x41; break;
      case 2: PORTD = 0x49; break;
      case 3: PORTD = 0x55; break;
      case 4: PORTD = 0x5d; break;
      case 5: PORTD = 0x77; break;
    }
  }while(wertalt<200);    //So oft neu würfeln bis Zufallswert >200
//-------------------Endgültiger Wert-----------------------------
  
//-------------------10 Sek Wert anzeigen-----------------------
  
  TCCR1B|=0x0D;  //CTC / Prescaler = 1024 , Timer Starten
}

ISR (TIMER1_COMPA_vect)  //Energiesparen.....
{
  PORTD = 0x00;
  set_sleep_mode(SLEEP_MODE_PWR_DOWN);
  sleep_mode();
  GIMSK=0x00;    //Alle Externen Interrupts Disable  
  TIMSK=0x00;    //alle Timer-Interrupts Disable
}

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

[Peter D. (peda)]

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.

[Axel S. (a-za-z0-9)]

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

[Peter D. (peda)]

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"

[MaWin (Gast)]

Wuerfler schrieb:
> Ich möchte einen Würfel welcher mti einem Attiny2313 arbeitet möglichst
> energiesparsam realisieren.
>
> Da ich den IRQ0 als Ausgang für eine LED verwendet

Häh? Eine LED (vermutlich 7 LEDs in 4 Gruppen) für ein "möglichst 
energiesparsames" Gerät ?

Du hast da irgendwas missverstanden.

Dafür verwendet man passive LCD, und falls du keins mit 7 Punkten 
findest, kannst du es ähnlich einer Platine selbst machen:

 http://fluessigkristalle.com/selbstbau.htm

Falls du unbedingt bei den LEDs bleiben willst für einen Würfel den man 
nur im dunklen ablesen kann, und aus irgendwelchen Gründen einen 
ATTiny10 mit nur 6 Pins verwenden willst, und trotz der nur insgesamt 6 
Pins nicht mit 4 sondern mit 3 auskommen willst, geht das dank 
Charlyplexing, und hast deinen Aufwachpin für den Taster übrig.

 http://ww1.microchip.com/downloads/en/AppNotes/91029a.pdf

Aber wie ich höre, bist du nur zu faul zum umlöten, und das mangelnde 
Aufwachen nur ein Programmierfehler.

[Coder (Gast)]

Ich habe ebenfalls Eindruck, dass der TO bei den LEDs viel Strom 
"verbraucht". Der Strom, den er durch das "Schlafen legen" des uC, 
einspart ist da marginal. Weiterhin ist von einem Taster die Rede; 
wahrscheinlich ein dauerhafter Pull-Up dran?

[Peter D. (peda)]

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.

[Axel S. (a-za-z0-9)]

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

[Uwe K. (ukhl)]

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.

[Uwe K. (ukhl)]

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 ;-)

[Alexander S. (esko)]

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.

[Peter D. (peda)]

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.

[Uwe K. (ukhl)]

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.

[Alexander S. (esko)]

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.

[Markus W. (Firma: guloshop.de) (m-w)]

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 (esko) (Gast)]

Markus Weber schrieb:
> 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".

Und den Zufall holst du über eine c-Funktion? Oder bittest du den 
Benutzer nochmal die Würfeltaste zu drücken?
Woher holst du im ersten Fall den Seed?

[Uwe K. (ukhl)]

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.

[Alexander Schmidt (esko) (Gast)]

Uwe K. schrieb:
>> 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.
Alles klar, dann ist es tatsächlich eine gute Lösung.