ATtiny13 verstehe Verhalten nicht

[Lukas P. (fuzzhead)]

Hallo,

verstehe das Verhalten meines ATtiny13 nicht. Sieht jemand meinen 
Denkfehler?

Bin am Experimentieren, um externe Interrupts kennen zu lernen.

Habe folgenden Code:

#include <avr/io.h>
#include <avr/interrupt.h>
#include <util/delay.h>

volatile uint8_t int0_flag = 0;

int main (void) {
    /* enable output pin, set low */
    DDRB |= (1<<PB4);

    /* enable pullup on interrupt pin */
    PORTB |= (1<<PB1);
    
    /* allow logic level to rise */
    _delay_ms(500);
    
    /* set interrupt flag for INT0 extern int. */
    GIMSK |= (1<<INT0);
    
    /* enable interrupts globally */
    //sei();

    while(1){
        if (int0_flag) {
            PORTB |= (1<<PB4);
        }
    }

    return 0;
}

ISR(INT0_vect) {
    int0_flag = 1;
}

Der PB4-Pin wird high, obwohl ich erwarten würde, dass er low bleibt.

sei() habe ich auskommentiert, um auszuschließen, dass int0_flag vom 
Interrupt manipuliert wird.

Warum wird der Pin trotzdem high? Wo ist mein Denkfehler?

Liebe Grüße,

Lukas

[Karl H. (kbuchegg)]

Lukas P. schrieb:

> Warum wird der Pin trotzdem high? Wo ist mein Denkfehler?

Der Mechanismus, der Interrupts trackt ist bereits nach Anlegen der 
Versorgungsspannung aktiv. Egal ob du später dann einen Pullup 
dazuschaltest oder nicht. Egal ob du den Interrupt dann frei gibst oder 
nicht. Egal ob du die Interrupts insgesamt frei gibst oder nicht.

Erst mal (noch ehe dein Programm überhaupt eine Chance hat loszulegen), 
ist der Pin ein Eingang. Und je nachdem, was du da extern angeschlossen 
hast, kann das auch ein offener Eingang sein, der sich alles mögliche 
einfängt. Unter anderem auch Pegel, die du zu diesem Zeitpunkt nicht 
haben willst. Das ist aber dem µC egal. Er sieht dort einen Pegel 
und/oder Flanke und setzt dementsprechend das 'Ereignis aufgetreten 
Bit'. Es ist daher sinnvoll, dieses Bit erst mal zurückzusetzen, ehe du 
dann mit einem sei() alles scharf schaltest.

[Jim M. (turboj)]

Lukas P. schrieb:
> Der PB4-Pin wird high, obwohl ich erwarten würde, dass er low bleibt.

Wiso? Den setzt niemand auf Low.

Könntest Du aber selbst machen:

/* enable pullup on interrupt pin */
    PORTB = (1<<PB1);
// ------^^

[Lukas P. (fuzzhead)]

Karl H. schrieb:
> Es ist daher sinnvoll, dieses Bit erst mal zurückzusetzen, ehe du
> dann mit einem sei() alles scharf schaltest.

Vielen Dank für den Hinweis, das werde ich einarbeiten.

[Karl H. (kbuchegg)]

Karl H. schrieb:

> Bit'. Es ist daher sinnvoll, dieses Bit erst mal zurückzusetzen, ehe du
> dann mit einem sei() alles scharf schaltest.

Die Rede ist vom INT0F im Register GIFR
(musste erst mal im Datenblatt nachsehen)

[Karl M. (Gast)]

Lukas P.,

und nicht vergessen die globalen Interrupts frei zu schalten, das hatte 
Karl Heinz schon angemerkt.

[Lukas P. (fuzzhead)]

Karl H. schrieb:
> Die Rede ist vom INT0G im Register GIFR
> (musste erst mal im Datenblatt nachsehen)

Hatte ich verstanden - trotzdem danke fürs extra Nachschauen!

[Karl H. (kbuchegg)]

AChtug: Dieses Bit wird durch Einschreiben einer 1 gelöscht
Also

   ...
   GIFR = (1 << INT0F );  // eventuell bisher aufgetretene Interrupts löschen
   sei();

   while( 1 )
     ....

[Lukas P. (fuzzhead)]

Jim M. schrieb:
> Den setzt niemand auf Low.

Aber auch niemand auf high. So wie ich das Datenblatt verstehe und 
meinen Tests nach ist der Inhalt von PORTB nach dem Start 0x00.

Wenn ich die while-schleife leer lasse, dann bleibt der Pin brav low.


Karl M. schrieb:
> und nicht vergessen die globalen Interrupts frei zu schalten

Die sind grade absichtlich aus.
Ich will verstehen, warum der Pin ohne Interrupt high wird.

[Karl H. (kbuchegg)]

Wenn du keinen sei() hast, dann kann der nicht high werden. Denn dann 
kann die  Variable auch nie 1 werden.

[Lukas P. (fuzzhead)]

Karl H. schrieb:
> Wenn du keinen sei() hast, dann kann der nicht high werden. Denn dann
> kann die  Variable auch nie 1 werden.

Das hätte ich auch gedacht, wird er aber.

Habe nochmal kompiliert, geflasht und gemessen, Pin wird high.

Mist :(

[Karl H. (kbuchegg)]

Durchcompiliert?

änder mal 1 Zeichen im Programm und achte drauf, dass auch wirklich 
alles compiliert und gelinkt wird.

richtiges Hex-File geflasht?

[WebDeveloper (Gast)]

Du könntest das Programm mal wie folgt abändern und dann ausprobieren:

#include <avr/io.h>
#include <avr/interrupt.h>
#include <util/delay.h>

volatile uint8_t int0_flag = 0;

int main (void) {
    /* enable output pin, set low */
    DDRB = (1<<PB4);

    /* enable pullup on interrupt pin */
    PORTB = (1<<PB1);
    
    /* allow logic level to rise */
    _delay_ms(500);
    
    /* set interrupt flag for INT0 extern int. */
    if (GIFR != 0) {
        GIFR = (1<<INTF0);
    }
    GIMSK |= (1<<INT0);

    int0_flag = 0;
    
    /* enable interrupts globally */
    sei();

    while(1){
        if (int0_flag) {
            PORTB |= (1<<PB4);
        }
    }

    return 0;
}

ISR(INT0_vect) {
    int0_flag = 1;
}

[Beobachter #42 (Gast)]

so mal testen:

DDRB |= (1<<PB4);
PORTB &= ~(1<<PB4);

g
#42

[Lukas P. (fuzzhead)]

@ WebDeveloper & 42:

habe eure Vorschläge eingepflegt, leider ohne Erfolg.

Der Pin wird trotzdem high.

Wenn ich die Zeile

PORTB |= (1<<PB4);

 in der while-Schleife auskommentiere, bleibt er low.

Diese Zeile wird also ausgeführt. Aber warum?

[WebDeveloper (Gast)]

Poste doch mal das .lss-File.

[Lukas P. (fuzzhead)]

Der Vollständigkeit halber hier nochmal der Code:

#include <avr/io.h>
#include <avr/interrupt.h>
#include <util/delay.h>

volatile uint8_t int0_flag = 0;

int main (void) {
    /* enable output pin, set low */
    DDRB = (1<<PB4);
    PORTB &= ~(1<<PB4);

    /* enable pullup on interrupt pin */
    PORTB = (1<<PB1);
    
    /* allow logic level to rise */
    _delay_ms(500);
    
    /* set interrupt flag for INT0 extern int. */
    if (GIFR != 0) {
        GIFR = (1<<INTF0);
    }
    GIMSK |= (1<<INT0);

    int0_flag = 0;
    
    /* enable interrupts globally */
    sei();

    while(1){
        if (int0_flag) {
            //PORTB |= (1<<PB4);
        }
    }

    return 0;
}

ISR(INT0_vect) {
    int0_flag = 1;
}

und das Makefile

BINARY=klotimer
OBJS=main.o

PREFIX  = avr
CC    = $(PREFIX)-gcc
LD    = $(PREFIX)-gcc
OBJCOPY    = $(PREFIX)-objcopy
OBJDUMP    = $(PREFIX)-objdump

CFLAGS    += -Os -Wall -Wextra -mmcu=attiny13 -DF_CPU=1200000UL -fdata-sections -ffunction-sections -Wl,-gc-sections
LDFLAGS    = 

.SUFFIXES: .elf .bin .hex .list

all: flash

images: $(BINARY).images
flash: $(BINARY).flash

%.images: %.bin %.hex %.list
  @#echo "*** $* images generated ***"

%.bin: %.elf
  $(OBJCOPY) -Obinary $(*).elf $(*).bin

%.hex: %.elf
  $(OBJCOPY) -Oihex -j .text -j .data $(*).elf $(*).hex

%.list: %.elf
  $(OBJDUMP) -S $(*).elf > $(*).list

%.elf: $(OBJS)
  $(LD) -o $(*).elf $(OBJS) $(LDFLAGS)

%.o: %.c Makefile
  $(CC) $(CFLAGS) -o $@ -c $<

clean:
  rm -f *.o
  rm -f *.elf
  rm -f *.bin
  rm -f *.hex
  rm -f *.list

%.flash: %.hex
  avrdude -P usb -p t13 -c usbtiny -v -B 10 -U flash:w:$(*).hex

.PHONY: images clean

[Lukas P. (fuzzhead)]

WebDeveloper schrieb:
> Poste doch mal das .lss-File.

Jenes?

cat klotimer.list 

klotimer.elf:     file format elf32-avr


Disassembly of section .text:

00000000 <__ctors_end>:
   0:  20 e0         ldi  r18, 0x00  ; 0
   2:  a0 e6         ldi  r26, 0x60  ; 96
   4:  b0 e0         ldi  r27, 0x00  ; 0
   6:  01 c0         rjmp  .+2        ; 0xa <.do_clear_bss_start>

00000008 <.do_clear_bss_loop>:
   8:  1d 92         st  X+, r1

0000000a <.do_clear_bss_start>:
   a:  a1 36         cpi  r26, 0x61  ; 97
   c:  b2 07         cpc  r27, r18
   e:  e1 f7         brne  .-8        ; 0x8 <.do_clear_bss_loop>

00000010 <main>:
  10:  80 e1         ldi  r24, 0x10  ; 16
  12:  87 bb         out  0x17, r24  ; 23
  14:  c4 98         cbi  0x18, 4  ; 24
  16:  82 e0         ldi  r24, 0x02  ; 2
  18:  88 bb         out  0x18, r24  ; 24
  1a:  2f eb         ldi  r18, 0xBF  ; 191
  1c:  84 ed         ldi  r24, 0xD4  ; 212
  1e:  91 e0         ldi  r25, 0x01  ; 1
  20:  21 50         subi  r18, 0x01  ; 1
  22:  80 40         sbci  r24, 0x00  ; 0
  24:  90 40         sbci  r25, 0x00  ; 0
  26:  e1 f7         brne  .-8        ; 0x20 <main+0x10>
  28:  00 c0         rjmp  .+0        ; 0x2a <main+0x1a>
  2a:  00 00         nop
  2c:  8a b7         in  r24, 0x3a  ; 58
  2e:  88 23         and  r24, r24
  30:  11 f0         breq  .+4        ; 0x36 <main+0x26>
  32:  80 e4         ldi  r24, 0x40  ; 64
  34:  8a bf         out  0x3a, r24  ; 58
  36:  8b b7         in  r24, 0x3b  ; 59
  38:  80 64         ori  r24, 0x40  ; 64
  3a:  8b bf         out  0x3b, r24  ; 59
  3c:  10 92 60 00   sts  0x0060, r1
  40:  78 94         sei
  42:  80 91 60 00   lds  r24, 0x0060
  46:  fd cf         rjmp  .-6        ; 0x42 <__SREG__+0x3>

00000048 <__vector_1>:
  48:  1f 92         push  r1
  4a:  0f 92         push  r0
  4c:  0f b6         in  r0, 0x3f  ; 63
  4e:  0f 92         push  r0
  50:  11 24         eor  r1, r1
  52:  8f 93         push  r24
  54:  81 e0         ldi  r24, 0x01  ; 1
  56:  80 93 60 00   sts  0x0060, r24
  5a:  8f 91         pop  r24
  5c:  0f 90         pop  r0
  5e:  0f be         out  0x3f, r0  ; 63
  60:  0f 90         pop  r0
  62:  1f 90         pop  r1
  64:  18 95         reti

[WebDeveloper (Gast)]

Dein Compiler tut da scheinbar etwas, was du nicht möchtest. Poste bitte 
mal das .lss-File, in dem man nachsehen kann, was vom Code geblieben und 
was entfernt wurde.

[WebDeveloper (Gast)]

Genau das. Leider wird dein C-Code nicht eingebaut, aber ich schaue mal, 
ob ich was finde.

[Lukas P. (fuzzhead)]

Oh Mist, das war mit dem Auskommentierten if-Inhalt (

PORTB |= (1<<PB4);

).

Hier nochmal richtig:

cat klotimer.list                       

klotimer.elf:     file format elf32-avr


Disassembly of section .text:

00000000 <__ctors_end>:
   0:  20 e0         ldi  r18, 0x00  ; 0
   2:  a0 e6         ldi  r26, 0x60  ; 96
   4:  b0 e0         ldi  r27, 0x00  ; 0
   6:  01 c0         rjmp  .+2        ; 0xa <.do_clear_bss_start>

00000008 <.do_clear_bss_loop>:
   8:  1d 92         st  X+, r1

0000000a <.do_clear_bss_start>:
   a:  a1 36         cpi  r26, 0x61  ; 97
   c:  b2 07         cpc  r27, r18
   e:  e1 f7         brne  .-8        ; 0x8 <.do_clear_bss_loop>

00000010 <main>:
  10:  80 e1         ldi  r24, 0x10  ; 16
  12:  87 bb         out  0x17, r24  ; 23
  14:  c4 98         cbi  0x18, 4  ; 24
  16:  82 e0         ldi  r24, 0x02  ; 2
  18:  88 bb         out  0x18, r24  ; 24
  1a:  2f eb         ldi  r18, 0xBF  ; 191
  1c:  84 ed         ldi  r24, 0xD4  ; 212
  1e:  91 e0         ldi  r25, 0x01  ; 1
  20:  21 50         subi  r18, 0x01  ; 1
  22:  80 40         sbci  r24, 0x00  ; 0
  24:  90 40         sbci  r25, 0x00  ; 0
  26:  e1 f7         brne  .-8        ; 0x20 <main+0x10>
  28:  00 c0         rjmp  .+0        ; 0x2a <main+0x1a>
  2a:  00 00         nop
  2c:  8a b7         in  r24, 0x3a  ; 58
  2e:  88 23         and  r24, r24
  30:  11 f0         breq  .+4        ; 0x36 <main+0x26>
  32:  80 e4         ldi  r24, 0x40  ; 64
  34:  8a bf         out  0x3a, r24  ; 58
  36:  8b b7         in  r24, 0x3b  ; 59
  38:  80 64         ori  r24, 0x40  ; 64
  3a:  8b bf         out  0x3b, r24  ; 59
  3c:  10 92 60 00   sts  0x0060, r1
  40:  78 94         sei
  42:  80 91 60 00   lds  r24, 0x0060
  46:  88 23         and  r24, r24
  48:  e1 f3         breq  .-8        ; 0x42 <__SREG__+0x3>
  4a:  c4 9a         sbi  0x18, 4  ; 24
  4c:  fa cf         rjmp  .-12       ; 0x42 <__SREG__+0x3>

0000004e <__vector_1>:
  4e:  1f 92         push  r1
  50:  0f 92         push  r0
  52:  0f b6         in  r0, 0x3f  ; 63
  54:  0f 92         push  r0
  56:  11 24         eor  r1, r1
  58:  8f 93         push  r24
  5a:  81 e0         ldi  r24, 0x01  ; 1
  5c:  80 93 60 00   sts  0x0060, r24
  60:  8f 91         pop  r24
  62:  0f 90         pop  r0
  64:  0f be         out  0x3f, r0  ; 63
  66:  0f 90         pop  r0
  68:  1f 90         pop  r1
  6a:  18 95         reti

Bei 0x46 ist jetzt halt noch die Abfrage hinzugekommen, die war vorher 
leer, also wegoptimiert.

[WebDeveloper (Gast)]

Also wie folgt:

00000000 <__ctors_end>:
   0:  20 e0         ldi  r18, 0x00  ; 0
   2:  a0 e6         ldi  r26, 0x60  ; 96
   4:  b0 e0         ldi  r27, 0x00  ; 0      // Lade Adresse int0_flag in X-Register
   6:  01 c0         rjmp  .+2        ; 0xa <.do_clear_bss_start>

00000008 <.do_clear_bss_loop>:
   8:  1d 92         st  X+, r1      // Speicher Wert aus r1 (ist nicht gesetzt?) in int0_flag und erhöhe Adresse in X um 1

0000000a <.do_clear_bss_start>:
   a:  a1 36         cpi  r26, 0x61  ; 97
   c:  b2 07         cpc  r27, r18
   e:  e1 f7         brne  .-8        ; 0x8 <.do_clear_bss_loop>

00000010 <main>:
  10:  80 e1         ldi  r24, 0x10  ; 16  
  12:  87 bb         out  0x17, r24  ; 23  // DDRB4 auf Ausgang
  14:  c4 98         cbi  0x18, 4  ; 24    // PORTB4 auf low
  16:  82 e0         ldi  r24, 0x02  ; 2
  18:  88 bb         out  0x18, r24  ; 24   // PORTB1 auf high
  1a:  2f eb         ldi  r18, 0xBF  ; 191
  1c:  84 ed         ldi  r24, 0xD4  ; 212
  1e:  91 e0         ldi  r25, 0x01  ; 1
  20:  21 50         subi  r18, 0x01  ; 1
  22:  80 40         sbci  r24, 0x00  ; 0
  24:  90 40         sbci  r25, 0x00  ; 0
  26:  e1 f7         brne  .-8        ; 0x20 <main+0x10>
  28:  00 c0         rjmp  .+0        ; 0x2a <main+0x1a>
  2a:  00 00         nop
  2c:  8a b7         in  r24, 0x3a  ; 58      // GIFR einlesen
  2e:  88 23         and  r24, r24
  30:  11 f0         breq  .+4        ; 0x36 <main+0x26>    // Springe wenn Zero
  32:  80 e4         ldi  r24, 0x40  ; 64          // Sonst setze INTF0 auf 1
  34:  8a bf         out  0x3a, r24  ; 58
  36:  8b b7         in  r24, 0x3b  ; 59          // Lese GIMSK
  38:  80 64         ori  r24, 0x40  ; 64          // Verodere mit (1<<INT0)
  3a:  8b bf         out  0x3b, r24  ; 59
  3c:  10 92 60 00   sts  0x0060, r1
  40:  78 94         sei              // Ints aktriv
  42:  80 91 60 00   lds  r24, 0x0060        // Lade Daten aus Speicheradresse 0x0060 
  46:  88 23         and  r24, r24          // Ist der Wert 0?
  48:  e1 f3         breq  .-8        ; 0x42 <__SREG__+0x3>    // Loope
  4a:  c4 9a         sbi  0x18, 4  ; 24        // Setze PORTB2  ????
  4c:  fa cf         rjmp  .-12       ; 0x42 <__SREG__+0x3>

In der folgenden ISR wird eine 1 in die Adresse 0x0060 (int0_flag) 
geschrieben.

Dein Assemblercode sieht logisch genauso aus wie er C-Code.


:-(.

[WebDeveloper (Gast)]

4a:  c4 9a         sbi  0x18, 4  ; 24

Ist naturlich PORTB4

[Lukas P. (fuzzhead)]

Gut, so verstehe ich das auch.

Dann werde ich mal einen anderen tiny13 und eine andere Spannungsquelle 
testen, irgendwo muss der Fehler ja sein.

[Lukas P. (fuzzhead)]

Lukas P. schrieb:
> Dann werde ich mal einen anderen tiny13 und eine andere Spannungsquelle
> testen, irgendwo muss der Fehler ja sein.

Ergebnis:

Beim neuen Tiny geht die LED nicht an, auch nicht, wenn ich PB1 mit 
einem Taster low ziehe.

Beim alten geht nachwievor die LED an. Wenn ich PB1 low ziehe, geht sie 
aus und geht nach dem loslassen von PB1 mit einer kleinen Verzögerung 
wieder an.
Beides nicht, wie es sein sollte ...

Muss jetzt leider weg, Ideen und Erleuchtungen sind weiterhin willkommen 
;)

Vielen Dank für eure bisherige Hilfe!

[WebDeveloper (Gast)]

Ich schätze mal:

deine LED geht an, wenn PB4 low ist und sie geht aus, wenn PB4 high ist. 
Wenn du den Taster betätigst und PB1 auf Masse gezogen wird, wird PB4 
high gesetzt und die LED geht aus, weil dann in deine If-Abfrage 
gesprungen wird.

Ein Zurück setzen ist nicht vorgesehen in der Schleife, passiert aber 
trotzdem. Das Teil macht nicht zufällig ständig Resets?

Bei nächster Gelegenheit wären ein Schaltplan und/oder zumindest 
ein/zwei gute Bilder vom Aufbau toll ;-).

[Lukas P. (fuzzhead)]

WebDeveloper schrieb:
> Bei nächster Gelegenheit wären ein Schaltplan und/oder zumindest
> ein/zwei gute Bilder vom Aufbau toll ;-).

Ich gelobige Besserung :)

WebDeveloper schrieb:
> deine LED geht an, wenn PB4 low ist und sie geht aus, wenn PB4 high ist.
> Wenn du den Taster betätigst und PB1 auf Masse gezogen wird, wird PB4
> high gesetzt und die LED geht aus, weil dann in deine If-Abfrage
> gesprungen wird.

Die Pegel sind mit dem Multimeter gemessen, die LED ist gegen GND 
geschaltet.

Evtl habe ich beim Fummeln dem ersten Tiny den PORTB zerzappt (ESD) und 
der resetted wirklich durch den an PB1 hängenden Taster.

Aber der neue Tiny lässt garnichts leuchten, das ist auch faul. Ist der 
INT0-Taster gedrückt, wird der Pin auf 0.2V = 0.04*VCC runtergezogen. 
Laut Datenblatt sind für low nur 0.1*VCC nötig. Der Interrupt sollte 
also auslösen.

Ist doch alles haarig ...

[Marco G. (grmg2010)]

WebDeveloper schrieb:
> if (int0_flag) {
>             PORTB |= (1<<PB4);
>         }

Müsste dies nicht anders lauten: if (int0_flag != 0)... oder wird in 
dieser Form auf 1 abgefragt?

Nutze testweise mal einen externen Pullup am !Reset-Pin.

[Dennis S. (eltio)]

Marco G. schrieb:
> Müsste dies nicht anders lauten: if (int0_flag != 0)... oder wird in
> dieser Form auf 1 abgefragt?

Nein (oder fast): die Form testet auf "ungleich 0".

[WebDeveloper (Gast)]

Als Lebenszeichentest könntest du mal die LED nach deinen 500ms Delay 
anschalten und dann testen, ob der Reset(taster) funktioniert. Danach 
kann man dann weiter überlegen, was das noch sein kann.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Lukas P. schrieb:
> Beim neuen Tiny ...
> Beim alten ...
Watchdog unterschiedlich eingestellt?
Oszillator verbogen?
Tut der uC überhaupt noch was?
Ich würde während der Entwicklung auch immer in der Mainloop eine LED 
vor sich hinblinken lassen. Wenn die mal nicht mehr blinkt, dann hängt 
das Programm...

BTW: wenn das tatsächlich ein "Klotimer" werden soll, wozu sind dann 
Interrupts nötig?

Marco G. schrieb:
> Müsste dies nicht anders lauten: if (int0_flag != 0)...
if() testet seinen Parameter sowieso schon auf 0. Und so wird der Code 
in der if-Bedingung nur dann ausgeführt, wenn der Parameter ungleich 0 
ist. Ergo ergibgt "if (irgendwas!=0){}" genau das selbe wie "if 
(irgendwas){}"

Das kann man dann auch gut für leserliche Programme verwenden:

if (daten_da) {
  daten_auswerten();
  if (!bereit_zum_senden) {
     daten_vorbereiten();
  else
     daten_senden();
  }
}

[Holger L. (max5v)]

Habe es gerade eben aufgebaut und getestet. Der einzige mögliche Fehler 
der mir am Aufbau aufgefallen ist wäre der Taster, den kann man leicht 
mal falsch verdrahten. Ein 100nF zwischen VCC+GND kann nicht schaden 
ebenso wie ein 10k Pullup am Resetpin.

Die Software (die letzte Version) lief sofort Problemlos. Das einzige 
was fehlte war #define F_CPU 1200000.
Die .hex ist angehängt, wenn du es damit versuchen möchtest.
(9.6MHz + Ckdiv8 = 1.2 MHz)

[Ingo L. (corrtexx)]

Ich hatte mal mangels Lust auf nem Steckbrett keinen 100nF an der 
Versorgung und das Ding machte was es wollte, nur nicht was es sollte. 
100nF dran und alles lief einwandfrei...

mach mal:

while(1){
        if (int0_flag) {
            PORTB |= (1<<PB4);
            int0_flag--;
            _delay_ms(200);
        }else{
            PORTB &= ~(1<<PB4);
        }
}

ISR(INT0_vect) {
    int0_flag = 10;
}

EDIT:
Die 1k Vorwiderstand sind schon grenzwertig, eher weniger
Die 1k in Reihe zum Taster würde ich eher so auf 100R setzen

[Frank M. (ukw) (Moderator)]

Lukas P. schrieb:
> Ist doch alles haarig ...

Du hast den 100nF Kerko (Abblockkondensator) vergessen. Deine 
geschilderten Probleme (der eine ATTiny123 funktioniert, der andere 
nicht) passen wie Topf auf Deckel.

Löte ihn an und schon werden Deine Probleme verschwinden.

[Lukas P. (fuzzhead)]

Heureka!

Abblockkondensator hinzugefügt, Holgers Firmware geflashed -> kein 
Erfolg.

Alles vom Steckbrett gerissen und neu verkabelt -> jetzt läufts.

Komme mir grade doof vor…

Jetzt arbeite ich mal alle Vorschläge ein und poste dann den 
resultierenden Code.

Vielen, vielen Dank für eure große Hilfsbereitschaft und Geduld - 
wirklich toll hier :)

[Ingo Less (Gast)]

Ein Steckbrett hat auch seine Tücken

[Lukas P. (fuzzhead)]

Jaja ... es war anscheinend nicht das Steckbrett alleine.

Ich bekomme den Code nachwievor nicht funktionstüchtig compiliert.

Flashe ich Holgers hex-file, läufts. Nehme ich mein eigenes, läufts 
nicht.

Habe ihm schon eine PN geschrieben und um die Befehle gebeten, die er 
benutzt.

[Lukas P. (fuzzhead)]

Der Wurm steckte im Makefile.

Habe dem Linker nicht -mmcu=attiny13 übergeben. Jetzt läufts.

kopfgegenwandhau


Implementierte Änderungsvorschläge:

- zusätzliche LED in der Main-Schleife blinken lassen, um zu sehen, ob 
die läuft (Lothar)

- 100nF Abblockkondensator eingebaut. Die Lektion habe ich mir gemerkt … 
(Holger, Ingo und Frank)

- 10k Pullup am Reset-Pin (Holger)

- F_CPU hatte und habe ich im Makefile als Compileroption definiert. Ist 
das unsauber? (Holger)

- Codefragment eingefügt. (Ingo)

- LED-Vorwiderstand 1k habe ich gelassen, weil die LED sonst sehr 
blendet. Ist eine klare, blaue, fließen ca. 3mA. (Ingo)

Hier der resultierende Code:

cat main.c

#include <avr/io.h>
#include <avr/interrupt.h>
#include <util/delay.h>

volatile uint8_t int_flag = 0;

int main (void) {
    /* enable output pin, set low */
    DDRB = (1<<PB2) | (1<<PB4);

    /* enable pullup on interrupt pin */
    PORTB = (1<<PB1);    
    /* allow logic level to rise */
    _delay_ms(500);
    
    /* clear INT0 interupt flag if set*/
    if (GIFR != 0) {
        GIFR = (1<<INTF0);
    }
    /* set interrupt enable flag for INT0 extern int. */
    GIMSK |= (1<<INT0);
    
    /* reset interrupt signaling variable */
    //int_flag = 0;
    
    /* enable interrupts globally */
    sei();

    while(1){
        _delay_ms(200);
        
        if (int_flag) {
            PORTB ^= (1<<PB4);
            int_flag--;
        } else {
            PORTB &= ~(1<<PB4);
        }

        /* blink LED to monitor execution */
        PORTB ^= (1<<PB2);
    }

    return 0;
}

ISR(INT0_vect) {
    int_flag = 10;
}

cat Makefile

BINARY=klotimer
OBJS=main.o

PREFIX  = avr
CC    = $(PREFIX)-gcc
LD    = $(PREFIX)-gcc
OBJCOPY    = $(PREFIX)-objcopy
OBJDUMP    = $(PREFIX)-objdump
# Uncomment this line if you want to use the installed (not local) library.

CFLAGS    = -Os -Wall -Wextra -mmcu=attiny13 -DF_CPU=1200000UL
LDFLAGS    = -mmcu=attiny13

.SUFFIXES: .elf .bin .hex .list

all: flash

images: $(BINARY).images
flash: $(BINARY).flash

%.images: %.bin %.hex %.list
  @#echo "*** $* images generated ***"

%.bin: %.elf
  $(OBJCOPY) -Obinary $(*).elf $(*).bin

%.hex: %.elf
  $(OBJCOPY) -Oihex $(*).elf $(*).hex

%.list: %.elf
  $(OBJDUMP) -S $(*).elf > $(*).list

%.elf: $(OBJS)
  $(LD) -o $(*).elf $(OBJS) $(LDFLAGS)

%.o: %.c Makefile
  $(CC) -c $(CFLAGS) -o $@ $<

clean:
  rm -f *.o
  rm -f *.elf
  rm -f *.bin
  rm -f *.hex
  rm -f *.list

%.flash: %.hex
  avrdude -P usb -p t13 -c usbtiny -v -B 10 -U flash:w:$(*).hex

.PHONY: images clean

Jetzt zur allentscheidenden Frage, warum man für einen Klotimer 
Interrupts benötigt:

Habe vor einem Monat eine WG mitgegründet. Wir haben ein recht kleines 
Bad, man muss nach dem Duschen lüften. Jetzt ist es uns schon ein paar 
mal vorgekommen, das wir das Fenster vergessen haben und erst eine 
Stunde später in ein klapperkaltes Bad mit rödelnder Heizung kamen.

Der „Klotimer“ soll das verhindern. An Fensterrahmen und Fenster kommen 
Kontakte aus Alu-Tape als kruder Taster. Wird das Fenster geöffnet, so 
wird der Kontakt unterbrochen, was den ATtiny aus dem Stromsparschlaf 
wecken soll. Dieser startet einen 1 Sek. Timer, nach dessen Ablauf er 
überprüft, ob der Kontakt immernoch unterbrochen ist. Trifft dies zu, 
wird ein 5min Timer gestartet, nachdem ein lauter Alarm ertönt. Wird in 
der Zwischenzeit das Fenster wieder geschlossen, bricht der Timer ab und 
der ATtiny legt sich wieder schlafen. Das Ganze kommt in das Gehäuse 
eines defekten Rauchmelders, wird von einer 3V Lithium-Batterie versorgt 
und benutzt die Lärmerzeugungsmaschinerie des Rauchmelders. Mit dem 
Stummschaltungsknopf des Rauchmelders kann man den Alarm pausieren.

Der aktuelle Code ist dabei nur um grundlegende Funktionen zu testen, 
nicht Versuch einer Implementation.

Sobald das Projekt fertig ist, stelle ich hier den vollständigen 
Schaltplan, Code und Fotos ein.

Liebe Grüße,

Lukas

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Lukas P. schrieb:
> Wird in der Zwischenzeit das Fenster wieder geschlossen, bricht der
> Timer ab und der ATtiny legt sich wieder schlafen.
Was du brauchst ist ein simples Monoflop (oder auch zwei). Da hättest du 
dann auch keinerlei Probleme mit dem Batterieverbrauch.

Und wenn es unbedingt ein uC sein muss: weil die "5 min." absolut 
unkritisch sind, würde ich da allein mit dem Watchdog arbeiten. Der löst 
z.B. alle 5 sec. einen Reset aus, du siehst nach dem Kontakt und zählst 
in einem Zählerbyte das offene Fenster mit. Wenn dieser Zähler auf 60 
ist, schaltest du die Hupe ein (und nach 5 min. wieder aus, sonst hupt 
das ding die ganze Nacht, bis morgens um halb 6 der erste wieder nach 
Hause torkelt)...

[Holger L. (max5v)]

Schönes Projekt.

Nur falls du es noch nicht gelesen haben solltest (Electrical 
Characteristics im Datenblatt):
Die 1.2 MHz oder sogar 9.6 MHz sollten für dieses Projekt ein wenig 
übertrieben sein, man kann den Tinny intern mit 128kHz betreiben  was 
noch ein wenig Strom spart. (http://www.engbedded.com/fusecalc/)
Allerdings sollte man vorher kontrollieren ob das Programmiergerät das 
noch stemmen kann, die ISP-Frequenz sollte immer 1\4 des Cpu-Taktes 
betragen.

Das mit der Aluminiumfolie als Taster ist eine tolle Idee.
Man kann übrigens mit einem einfachen Kondensator, oder einem Transistor 
und weiteren einfachen Bauteilen eine Temperaturmessung durchführen, nur 
falls die Alufolie sich nicht beweisen sollte.

Lukas P. schrieb:
> - F_CPU hatte und habe ich im Makefile als Compileroption definiert. Ist
> das unsauber? (Holger)

Ich persönlich schreibe es immer direkt in den Code, das ist einfach 
übersichtlicher. Nach einem halben Jahr weiß man meißt nicht mehr was 
man dort für Einstellungen hatte, dann ist es auf einen Blick 
ersichtlich.
Nutze allerdings auch nur das AtmelStudio, dadurch muß man sich um das 
Makefile nicht kümmern.

[Lukas P. (fuzzhead)]

Lothar M. schrieb:
> Lukas P. schrieb:
>> Wird in der Zwischenzeit das Fenster wieder geschlossen, bricht der
>> Timer ab und der ATtiny legt sich wieder schlafen.
> Was du brauchst ist ein simples Monoflop (oder auch zwei). Da hättest du
> dann auch keinerlei Probleme mit dem Batterieverbrauch.

Interessante Idee, damit habe ich noch nie gearbeitet. Habe etwas 
überlegt und glaube, eine Monoflop&Flipflop-Lösung gefunden zu haben. 
Schreibe den Schaltplan die Tage auf und poste ihn, dann kannst Du 
kommentieren.

Fürs fertige 'Produkt' würde ich immernoch den uC bevorzugen, weil ich 
so nur einen IC verbauen muss und viel flexibler bin. Schön wäre zum 
Beispiel ein kurzes 'Pieps' alle 20s, als 'Fenster-offen-Indikator'. 
Beim hastigen Verlassen des Bades und Hauses auf dem Weg zur Party merkt 
man es dann vllt. grade noch.

> Und wenn es unbedingt ein uC sein muss: weil die "5 min." absolut
> unkritisch sind, würde ich da allein mit dem Watchdog arbeiten. Der löst
> z.B. alle 5 sec. einen Reset aus, du siehst nach dem Kontakt und zählst
> in einem Zählerbyte das offene Fenster mit. Wenn dieser Zähler auf 60
> ist, schaltest du die Hupe ein.

Wird das Zählerbyte vom Reset nicht gelöscht? Oder meinst Du im EEPROM?

Werde das mal so und mal mit Timerinterrupts implementieren und den 
Verbrauch messen. Sobald ich mir nach Weihnachten ein Speicherscope 
gekauft habe, versteht sich. ;) Mutmaße aber, dass es keinen 
nenneswerten Unterschied für die Batterielaufzeit machen wird, da der 
Piezo-Treiber im zeitlichen Mittel um Größenordnungen mehr Leistung 
verbraucht.

Dessen reverse'den Schaltplan gibts auch die Tage.

[Lukas P. (fuzzhead)]

Holger L. schrieb:
> Schönes Projekt.
>
> Nur falls du es noch nicht gelesen haben solltest (Electrical
> Characteristics im Datenblatt):
> Die 1.2 MHz oder sogar 9.6 MHz sollten für dieses Projekt ein wenig
> übertrieben sein, man kann den Tinny intern mit 128kHz betreiben  was
> noch ein wenig Strom spart. (http://www.engbedded.com/fusecalc/)
> Allerdings sollte man vorher kontrollieren ob das Programmiergerät das
> noch stemmen kann, die ISP-Frequenz sollte immer 1\4 des Cpu-Taktes
> betragen.

Werde ich ausprobieren. Danke für den Hinweis!

> Das mit der Aluminiumfolie als Taster ist eine tolle Idee.
> Man kann übrigens mit einem einfachen Kondensator, oder einem Transistor
> und weiteren einfachen Bauteilen eine Temperaturmessung durchführen, nur
> falls die Alufolie sich nicht beweisen sollte.

Ok, ist notiert :)

[chris_ (Gast)]

Bei 128kHz brauch der Attiny wirklich sehr wenig Strom. Wenn ich mich 
recht erinnere ca. 50uA ( wenn die meiste Peripherie aus ist ).

Ich hatte das für die Solarvögel verwendet. Die laufen schon bei sehr 
schwachem Licht los:

http://www.hobby-roboter.de/forum/viewtopic.php?f=5&t=43

[Lukas P. (fuzzhead)]

Interessantes Projekt! Vielen Dank für den Hinweis.

Das werd ich auch mal zusammenwerfen :)

[Holger L. (max5v)]

Lukas P. schrieb:
> Wird das Zählerbyte vom Reset nicht gelöscht? Oder meinst Du im EEPROM?

Der Watchdog kann so programmiert werden das er statt einem Reset einen 
ISR-Aufruf durchführt, in dem kann dann eine volatile Variable erhöht 
werden.

Lukas P. schrieb:
> Mutmaße aber, dass es keinen
> nenneswerten Unterschied für die Batterielaufzeit machen wird, da der
> Piezo-Treiber im zeitlichen Mittel um Größenordnungen mehr Leistung
> verbraucht.

Der muß doch nicht die ganze Zeit über an der Versorgung hängen, den 
könnte man mit einem Transistor zuschalten wenn er benötigt wird.

[Lukas P. (fuzzhead)]

Holger L. schrieb:
> Der Watchdog kann so programmiert werden das er statt einem Reset einen
> ISR-Aufruf durchführt, in dem kann dann eine volatile Variable erhöht
> werden.

Cool!

Holger L. schrieb:
>Lukas P. schrieb:
>> Mutmaße aber, dass es keinen
>> nenneswerten Unterschied für die Batterielaufzeit machen wird, da der
>> Piezo-Treiber im zeitlichen Mittel um Größenordnungen mehr Leistung
>> verbraucht.
> Der muß doch nicht die ganze Zeit über an der Versorgung hängen, den
> könnte man mit einem Transistor zuschalten wenn er benötigt wird.

So ist es auch implementiert. Aber wenn er mal piept (und das wird er), 
verbraucht er bestimmt auf einen Schlag so viel Energie wie der uC in 
zwei Wochen.