ATTINY26 Timer0-Interrupt kommt nicht

Laut http://www.atmel.com/dyn/resources/prod_documents/1477S.pdf ist PB7 
gleichzeitig der /RESET Pin.

Ob dies das Problem ist, kannst du durch die Änderung der folgenden 
Zeile herausfinden. Dabei wird PB7 (= /RESET) nie auf LOW (= RESET) 
gezogen.

alt:    PORTB = g_i;
neu:    PORTB = (1<<PB7) | g_i;

Es ist dort auch angegeben, was man machen kann, wenn man den PB7 als 
I/O Pin benutzen will. Obacht: Du kannst dich dabei so aussperren, dass 
keine ISP Programmierung mehr möglich ist!

Hallo,

wenn er Reset ist, also die RSTDSBL-Fuse nicht gesetzt ist, ist er nur 
Reset.
NUR wenn Reset per Fusebit abgeschaltet ist, benimmt er sich wie ein 
I/O-Pin.

Dein Änderungsvorschlag wird sein Problem also wohl nicht lösen.

Gruß aus Berlin
Michael

Also du meinst, der Attiny26 kann sich nie dadurch selbst resetten, dass 
auf PB7 LOW ausgegeben wird, richtig?

Ich hatte vorgeschlagen diese Frage auszuprobieren. Leider hat sich 
Wolfgang nicht mehr gemeldet und ich habe keinen Attiny26 zur Hand.

Stefan B. wrote:
> Also du meinst, der Attiny26 kann sich nie dadurch selbst resetten, dass
> auf PB7 LOW ausgegeben wird, richtig?

Richtig.

Der Code ist ok und funktioniert im Simulator auch tadellos.
Hast du auch den richtigen µC eingestellt?

Hab noch mal extra nachgesehen
ist ein ATtiny26-10PU

Ja, aber hast du das auch dem Compiler entsprechend mitgeteilt?

ich denke ja
> avr-gcc -mmcu=attiny26 -Os -Wall test.c -o timer.bin

hab noch mal den code von oben reingeladen, bekomme immer wieder resets

ich hab inzwischen mal versucht timer1 zu verwenden, da kommen keine 
resets
aber immer noch kein interrupt

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


volatile uint8_t g_i = 255;


ISR(TIMER1_CMPA_vect)
{
  PORTB |= (1 << PB0);
}

ISR(TIMER1_CMPB_vect)
{
  PORTB |= (1 << PB5);
}

ISR(TIMER1_OVF1_vect)
{
  PORTB &= ~((1 << PB5) | (1 << PB0));
}
int main(void)
{
  //set portA to output
  DDRA = 0xFF;
  //init portA with 01010101
  PORTA = 0x55;

  //set portB to output
  DDRB = 0xFF;
  //init portB with 10000000
  PORTB = ((1 << PB7) | 0x00);

  //set OCRpin to toggle
  TCCR1A |= ((1 << COM1A0) | (1 << COM1B0));
  TCCR1A &= ~((1 << COM1A1) | (1 << COM1B1));

  //set prescaler to 1
  TCCR1B |= (1 << CS10);
  TCCR1B &= ~((1 << CS13) | (1 << CS12) | (1 << CS11));

  //set OCR1A Register
  OCR1A = 70;

  //set OCR1B Register
  OCR1B = 127;

  //set OCR1C
  OCR1C = 255;

  //activate global interrupts
//  sei();
  SREG |= 0x80;

  while(1)
  {
          g_i--;
      PORTA = g_i;
        }



return 0;
}

timer.bin? Bei dem Namen befürchte ich fast, dass du das dann direkt in 
den µC lädst.

Ich hab die datei so benat weil ponyprog das file dann sofort findet

aber ja ich kompiliere es und lade es dann mit ponyprog in den µC

wie sollte ich sonst machen ?

Was der Compiler ausspuckt ist kein BIN-File, dass du direkt in den 
Controller schreiben kannst, sondern ein ELF-File. Die Daten zum 
Programmieren des µC musst du daraus erst noch extrahieren.
Ein HEX-File mit den Daten für das Flash bekommst du z.B. so:

1

avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature timer.bin timer.hex

PS: Und dann natürlich timer.hex in den Controller laden (nicht 
timer.bin).

okay hab ich gemacht, jetzt sieht das
speicherabbild in ponyprog anders aus,
aber an der funktion hat sich leider
nichts geändert

sag hast du icq oder skype ?
oder schick mir einfach ein mail an wol@gmx.at

Wolfgang Huber wrote:

> sag hast du icq oder skype ?

Sorry, keine Privataudienzen.

Poste bitte mal das HEX-File (als Anhang!).

Hier nochmal der sourcecode


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


volatile uint8_t g_i = 255;
volatile uint8_t g_switch = 0;


ISR(TIMER0_OVF0_vect)
{
  PORTA = g_switch;
  TCNT0 = 0X7f;
}

int main(void)
{
  //set portA to output
  DDRA = 0xFF;
  //init portA with 01010101
  PORTA = 0x55;

  //set portB to output
  DDRB = 0xFF;
  //init portB with 00001111
  PORTB = 0x0F;


  //set prescaler to 1
  TCCR0 &= ~((1 << CS02) | (1 << CS01));
  TCCR0 |= (1 << CS00);

  //activate timer0 overflow interrupt
  TIMSK |= ((1 << TOIE0));
  TCNT0 = 0X7f;

  //activate global interrupts
  sei();


  while(1)
  {
          g_i--;
    PORTB = g_i;
        }



return 0;

Das HEX-File ist in Ordnung und funktioniert.
Du hast also entweder ein Problem mit der Hardware oder mit dem 
Programmieren des Controllers (wirklich das HEX-File genommen?). Ich 
sehe sonst weiter keine Möglichkeit.

hab jetzt das file noch mal aus dem forum genommen

okay dann muss meine hardware was haben, ist zwar komisch
dass nur die interrupts nicht gehen
aber ich hol mir mal einen anderen controller
und probiere es morgen dann aus

danke für deine zeit


PS: hab gerade gesehen dass ich die variable im interrupt nicht ändere
jetzt funktionierts, war vermutlich die geschichte mit dem hex file ;-)

Wolfgang Huber wrote:

> PS: hab gerade gesehen dass ich die variable im interrupt nicht ändere
> jetzt funktionierts, war vermutlich die geschichte mit dem hex file ;-)

Wie jetzt? Die Änderung von 0x55 nach 0x00 hat stattgefunden, und dein 
"Interrupt funktioniert nicht" bezog sich darauf, dass danach nichts 
mehr passiert ist?

volatile uint8_t g_switch = 0;


ISR(TIMER0_OVF0_vect)
{
  PORTA = g_switch;
  TCNT0 = 0X7f;
}


bei der letzten änderung hab ich vergessen dass ich g_switch
erhöhe
das um und auf war das extrahieren des hex-files


entschuldige dass ich deine zeit verschwendet habe

ich danke dir dass du mir geholfen hast,
ich war schon am verzweifel weil ich mich schon
4 Tage damit spiele

Wolfgang Huber wrote:

> entschuldige dass ich deine zeit verschwendet habe

Ach, schon gut. Das Überprüfen des HEX-Files war nicht sooo ein großer 
Aufwand.

hast du ein programm das dir aus dem hex file ein asm
macht oder schaust du das hexfile so durch ?

nur damit ich das nächste mal weis wie ich das anstelle :-)

Ich habe es in den Simulator vom AVR-Studio geladen.

achso

na das sollte ich mir noch anschaun

danke
du kannst heute sicher gut schlafen
denn du hast eine gute Tat vollbracht

gute nacht
wol