Attiny45, timer tut nichts?

[A. F. (elagil)]

Hallo,

ich habe ein einfaches Programm zum Testen geschrieben:

#include <avr/io.h> 

int main (void) 
{ 
   DDRB |= (1 << PB0);
   PORTB ^= (1 << PB0);

   TCCR1 |= ((1 << CS13) | (1 << CS12)); // ps 4096 -> 2kHz

   for (;;) 
   { 
     
      if (TCNT1 >= 200) // ca 10 Hz
      { 
         PORTB ^= (1 << PB0); // Toggle

         TCNT1 = 0;
      } 
   } 
}

es soll eine led an PB0 flackern lassen, es passiert aber nichts. nach 
dem einschalten ändert sich nichts an der led. mit "_delay_ms" 
funktioniert das togglen einwandfrei, wo liegt denn da der fehler?

der attiny läuft bei 8Mhz mit internem oszillator.

[Electronics'nStuff (Gast)]

Naja was soll da schon passieren?
CTC Mode einstellen vergessen!

[Electronics'nStuff (Gast)]

BTW: Ist ein Bit im TCCR1 Register, welches musst du selber nachschauen, 
das weiss ich nicht auswendig.

[Karl H. (kbuchegg)]

Adrian Figueroa schrieb:


>    TCCR1 |= ((1 << CS13) | (1 << CS12)); // ps 4096 -> 2kHz


das sind aber keine 4096, sondern 2048.

Deine 10Hz sind also eher 20Hz. Und wenn man nicht so genau schaut, dann 
ist das nicht so sehr ein kräftiges Flackern, sondern schon fast ein 
gleichmässiges Leuchten.

[A. F. (elagil)]

> CTC Mode einstellen vergessen!

Aber ich setze doch den counter manuell zurück? Ich möchte selbst 
steuern, wann er sich zurücksetzt.

> das sind aber keine 4096, sondern 2048.

ok, ich hab mal vier bits gesetzt (CS10 bis 13) -> ca. 16k Prescaler
Da sollte ich doch eigentlich was sehen.

[Stefan H. (hohmi)]

schau mal Datenblatt des ATtiny45 ab seite 89. es fehlen noch ein paar 
register einträge.

mfg
Hohmi

Edit: war der falsche Controller^^, jetzt stimmts

[Electronics'nStuff (Gast)]

Ich würde das trotzdem so machen:

#include <avr/io.h> 

int main (void) 
{ 
   DDRB |= (1 << PB0);
   PORTB ^= (1 << PB0);
   OCR1 = 200;  //Max. Zählwert
   TCCR1 |= ((1 << CS13) | (1 << CS12) | (1<< WGM13)); // ps 4096 -> 2kHz
   sei(); //Globale Interrupts erlauben

   for (;;) 
   { 
     
    _delay_ms(1); //Irgend ein Befehl    

    } 
   
}

ISR (TIMER1_COMP_vect)
{
   PORTB ^= (1 << PB0); // Toggle
}

[A. F. (elagil)]

> Ich würde das trotzdem so machen:

das ist ja nur ein beispielprogramm ;) ich möchte später IR-Sequenzen 
auslesen, dazu wird der empfänger einen interrupt erzeugen, der dann den 
aktuellen zählerstand ausliest und dann wieder nullt! dafür muss ich ihn 
manuell setzen können.

> schau mal Datenblatt des ATtiny45 ab seite 89. es fehlen noch ein paar
> register einträge.

ich habe mal alles zu timer1 gelesen. :)

mir fällt kein versäumnis auf. ich will weder vergleichsregister setzen, 
noch pwm nutzen. Ich brauche keine interrupts, auch keinen fast mode 
oder sowas. der zähler soll nur zählen und ich möchte ihn manuell 
auslesen.

[Electronics'nStuff (Gast)]

Adrian Figueroa schrieb:
> ok, ich hab mal vier bits gesetzt (CS10 bis 13) -> ca. 16k Prescaler

CS13? Reden wir vom gleichen Controller?
Der Attiny45 hat nur CS10-CS12 in diesem Register.

[A. F. (elagil)]

auf seite 92 im datenblatt http://www.atmel.com/Images/doc2586.pdf sehe 
ich auch cs13 an bit3

[Electronics'nStuff (Gast)]

Oh Shit, sorry hatte das DB des Attiny48 angekuckt.

[A. F. (elagil)]

ah das erklärt die syntaxfehler beim kompilieren von deinem quelltext ;) 
die register heißen alle anders...

[Electronics'nStuff (Gast)]

Ne, die heissen schon so, müsstest einfach noch:

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

einbinden.

Und statt OCR1 -> OCR1A.

[A. F. (elagil)]

Ich verstehe es nicht! Timer0 läuft einwandfrei, Timer1 nicht... ich 
habe zwei LEDs dran..

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

int main(void) 
{ 
  

  DDRB |= (1 << PB0) | (1 << PB1);
  PORTB |= (1 << PB0)| (1 << PB1);
  
  TCCR1 |= (1 << CS10) | (1 << CS11) | (1 << CS13);
  TCCR0B |= (1<<CS02) | (1<<CS00);


  while(1) { 
  if(TCNT0 > 200) {
    DDRB ^= (1 << PB0);
    TCNT0 = 0;
  }
  }
  
   while(1) { 
  if(TCNT1 > 200) {
    DDRB ^= (1 << PB1);
    TCNT1 = 0;
  }
  }
}

[dosi (Gast)]

Was sollen die zwei while-Schleifen?

[Nico (nico123)]

Der Controller kommt ja auch nicht aus der ersten while-Schleife raus!!!

[Electronics'nStuff (Gast)]

Erstaunt jetzt nicht wirklich, du hast 2 Endlosschleifen.

[A. F. (elagil)]

oha :D ja das war wirklich dumm

[A. F. (elagil)]

wie auch immer, das hier geht nicht:

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

int main(void) 
{ 
  

  DDRB |= (1 << PB0) | (1 << PB1);
  PORTB |= (1 << PB0)| (1 << PB1);
  
  TCCR1 |= (1 << CS10) | (1 << CS11) | (1 << CS13);
  TCCR0B |= (1<<CS02) | (1<<CS00);


  while(1) { 

  if(TCNT1 > 200) {
    DDRB ^= (1 << PB0);
    TCNT1 = 0;
  }
  }
}

das hier schon:

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

int main(void) 
{ 
  

  DDRB |= (1 << PB0) | (1 << PB1);
  PORTB |= (1 << PB0)| (1 << PB1);
  
  TCCR1 |= (1 << CS10) | (1 << CS11) | (1 << CS13);
  TCCR0B |= (1<<CS02) | (1<<CS00);


  while(1) { 

  if(TCNT0 > 200) {
    DDRB ^= (1 << PB0);
    TCNT0 = 0;
  }
  }
}

[Nico (nico123)]

Adrian Figueroa schrieb:
> DDRB ^= (1 << PB0);

So setzt/toggelt man keinen Port!
Sondern so: PORTB ^= (1 << PB0);

Und das funktioniert im zweiten Beispiel?

[Spess53 (Gast)]

Hi

>Und das funktioniert im zweiten Beispiel?

Wahrscheinlich nicht. Aber

PINB = (1 << PB0);

toggled einen Pin beim ATTiny45.

MfG Spess

[dgps (Gast)]

du schmeißt die Timer-Bezeichnungen durcheinander!

Du musst überalle entweder Timer0 ODER Timer1 benutzen.

[A. F. (elagil)]

> So setzt/toggelt man keinen Port!
> Sondern so: PORTB ^= (1 << PB0);

oh ja... hat bei timer0 geklappt, weil ich den ja pin vorher schon 
eingeschaltet habe, ich schalte also zwischen ein- und ausgang hin und 
her, also einmal mit internem pullup und einmal ohne.

> du schmeißt die Timer-Bezeichnungen durcheinander!

naja, wenn ich den timer nicht benutze, ist das ja nicht schlimm, oder?

..die konzentration lässt nach.. neuer versuch ;) das hier läuft 
jedenfalls nicht.

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

int main(void) 
{ 
  

  DDRB |= (1 << PB0) | (1 << PB1);
  PORTB |= (1 << PB0)| (1 << PB1);
  
  TCCR1 |= (1 << CS10) | (1 << CS11) | (1 << CS13);


  while(1) { 
  if(TCNT1 > 200) {
    PORTB ^= (1 << PB0);
    TCNT1 = 0;
  }
  }
}

[Fred S. (kogitsune)]

Was erwartest Du? Du benutzt einen Vorteiler von 1024, bekommst bei 8 
MHz Systemtakt also eine AN/AUS-Dauer von jeweils 25,6 ms -- also 
nichts, was man als Blinken identifizieren würde!

[A. F. (elagil)]

Ich zähle erst noch bis 200!
Mit dem Timer0, den ich auch auf 1024er Prescaler gestellt habe und 
einem Counter von 200, konnte ich das Blinken klar sehen, mit Timer1 
bekomme ich nur ein dauerleuchten!

[Fred S. (kogitsune)]

Adrian Figueroa schrieb:
> Ich zähle erst noch bis 200!
Genau davon bin ich auch ausgegangen:
200*(1024/8000000Hz)= 25,6 ms

> Mit dem Timer0, den ich auch auf 1024er Prescaler gestellt habe und
> einem Counter von 200, konnte ich das Blinken klar sehen, mit Timer1
> bekomme ich nur ein dauerleuchten!
Natürlich kann man ein "Blinken" von 20 Hz wahrnehmen; genau das 
bekommst Du mit Deinem zuletzt oben gezeigten Programm. Schau aber mal 
nach, ob mit der Hardware alles OK ist, also die LED wirklich an PB0 
hängt usw.

[A. F. (elagil)]

Ja, die Hardware stimmt soweit. Ich kann alles schalten.

Wie gesagt, wenn ich TCNT1 durch TCNT0 ersetze und entsprechend den 
Timer0 auf Prescaler 1024 einstelle, klappt alles einwandfrei!

[Fred S. (kogitsune)]

Deine Terminologie finde ich etwas seltsam. 20 Hz "Flimmern" nennst Du 
"Blinken"?

Du zeigst uns wirklich Dein aktuelles Programm (also ohne Setzen der 
PSR1/PCKE Bits)? CKSEL Fuse?

[A. F. (elagil)]

> Du zeigst uns wirklich Dein aktuelles Programm

Ja.

> also ohne Setzen der PSR1/PCKE Bits

ich habe sonst nichts gesetzt. ich habe auch mal zuvor die register zu 
null initialisiert.

> CKSEL Fuse?

CKSEL = 0010, SUT=10, den Taktteiler habe ich ausgeschaltet (CKDIV8=1 
[active low?]).

Die Fuses sind also 0xE2(low) 0xDF(high) 0xFF(ext.)

[Fred S. (kogitsune)]

Die genannten Fuses stimmen. Du bist Dir sicher, dass Du den aktuellen 
Code im Flash stehen hast? Und dass der Compiler für den Attiny45 
kompiliert? Und dass an PB0 sonst nichts mehr hängt? Mal einen anderen 
Pin versucht?

Versuche doch auch einmal einen größeren Divisor als 1024; beim Timer1 
kann man doch bis 16384 gehen.

[A. F. (elagil)]

Hm.. Ja, gerade nochmal neu geflasht.

PB0 funktioniert einwandfrei mit Timer0! Ich habe auch schon PB1 und PB3 
getestet, immer das selbe. Die if Bedingung wird nie erfüllt. Wenn ich 
sowas reinschreibe wie "PORTB |= (1<<PB0)" und die LED vorher aus war, 
geht sie dann nicht an.

Ich habe schon alle möglichen Prescaler benutzt.. fürs erste werde ich 
wohl bei Timer0 bleiben, ich weiß nicht was falsch sein soll.

Ein anderer attiny45 zeigt übrigens das gleiche verhalten ;)

[Digitalism (Gast)]

Ich glaube nicht, dass man dir noch helfen kann wenn ich ehrlich bin.

- Der Code ist fehlerfrei
- Der Controller ist nicht defekt
- Der Systemtakt scheint zu stimmen

Was anderes kommt gar nicht in Frage, ausser dass dein Compiler aus 
irgend einem komischen Grund den Timer1 nicht kennt..

Was benutzt du eig. für eine Entwicklungsumgebung?
Womit flasht du den Controller?

Oder du verarscht uns einfach :P

[A. F. (elagil)]

Wenn ich in die if-Bedingung TCNT1==0 einsetze, dann dimmt er die led, 
ich muss also davon ausgehen, dass der zähler nicht hochzählt.

> Was benutzt du eig. für eine Entwicklungsumgebung?
> Womit flasht du den Controller?

Winavr/avrdude mit einem china-usbasp..

so sieht das aus: ;)

Compiling C: rffb.c
avr-gcc -c -mmcu=attiny45 -I. -gdwarf-2 -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=./rffb.lst  -std=gnu99 -MMD -MP -MF .dep/rffb.o.d rffb.c -o rffb.o 

Linking: rffb.elf
avr-gcc -mmcu=attiny45 -I. -gdwarf-2 -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=rffb.o  -std=gnu99 -MMD -MP -MF .dep/rffb.elf.d rffb.o --output rffb.elf -Wl,-Map=rffb.map,--cref     -lm

Creating load file for Flash: rffb.hex
avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock rffb.elf rffb.hex

Creating load file for EEPROM: rffb.eep
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" \
  --change-section-lma .eeprom=0 --no-change-warnings -O ihex rffb.elf rffb.eep || exit 0
avrdude -p attiny45 -P usb -c usbasp    -U flash:w:rffb.hex 

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9206
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "rffb.hex"
avrdude: input file rffb.hex auto detected as Intel Hex
avrdude: writing flash (86 bytes):

Writing | ################################################## | 100% 0.05s

avrdude: 86 bytes of flash written
avrdude: verifying flash memory against rffb.hex:
avrdude: load data flash data from input file rffb.hex:
avrdude: input file rffb.hex auto detected as Intel Hex
avrdude: input file rffb.hex contains 86 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.02s

avrdude: verifying ...
avrdude: 86 bytes of flash verified

avrdude done.  Thank you.

> Oder du verarscht uns einfach :P

Ich hab besseres zu tun :D

[Fred S. (kogitsune)]

Seh' ich so wie "Digitalism".

Zeig vielleicht auch mal die *.lss Datei (Du hast noch nicht gesagt, 
welche Winavr Version Du verwendest. Ich weiß nicht, ob alte 
Compiler-Versionen jemals mit dem Timer1 Probleme hatten... aber 
trotzdem.).

[A. F. (elagil)]

ich benutze Winavr 20100110 (wohl die neueste).

hier die gewünschte datei:

rffb.elf:     file format elf32-avr

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000054  00000000  00000000  00000054  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .debug_aranges 00000020  00000000  00000000  000000a8  2**0
                  CONTENTS, READONLY, DEBUGGING
  2 .debug_pubnames 0000001b  00000000  00000000  000000c8  2**0
                  CONTENTS, READONLY, DEBUGGING
  3 .debug_info   00000076  00000000  00000000  000000e3  2**0
                  CONTENTS, READONLY, DEBUGGING
  4 .debug_abbrev 00000041  00000000  00000000  00000159  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .debug_line   00000088  00000000  00000000  0000019a  2**0
                  CONTENTS, READONLY, DEBUGGING
  6 .debug_frame  00000020  00000000  00000000  00000224  2**2
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_str    00000083  00000000  00000000  00000244  2**0
                  CONTENTS, READONLY, DEBUGGING

Disassembly of section .text:

00000000 <__vectors>:
   0:  0e c0         rjmp  .+28       ; 0x1e <__ctors_end>
   2:  15 c0         rjmp  .+42       ; 0x2e <__bad_interrupt>
   4:  14 c0         rjmp  .+40       ; 0x2e <__bad_interrupt>
   6:  13 c0         rjmp  .+38       ; 0x2e <__bad_interrupt>
   8:  12 c0         rjmp  .+36       ; 0x2e <__bad_interrupt>
   a:  11 c0         rjmp  .+34       ; 0x2e <__bad_interrupt>
   c:  10 c0         rjmp  .+32       ; 0x2e <__bad_interrupt>
   e:  0f c0         rjmp  .+30       ; 0x2e <__bad_interrupt>
  10:  0e c0         rjmp  .+28       ; 0x2e <__bad_interrupt>
  12:  0d c0         rjmp  .+26       ; 0x2e <__bad_interrupt>
  14:  0c c0         rjmp  .+24       ; 0x2e <__bad_interrupt>
  16:  0b c0         rjmp  .+22       ; 0x2e <__bad_interrupt>
  18:  0a c0         rjmp  .+20       ; 0x2e <__bad_interrupt>
  1a:  09 c0         rjmp  .+18       ; 0x2e <__bad_interrupt>
  1c:  08 c0         rjmp  .+16       ; 0x2e <__bad_interrupt>

0000001e <__ctors_end>:
  1e:  11 24         eor  r1, r1
  20:  1f be         out  0x3f, r1  ; 63
  22:  cf e5         ldi  r28, 0x5F  ; 95
  24:  d1 e0         ldi  r29, 0x01  ; 1
  26:  de bf         out  0x3e, r29  ; 62
  28:  cd bf         out  0x3d, r28  ; 61
  2a:  02 d0         rcall  .+4        ; 0x30 <main>
  2c:  11 c0         rjmp  .+34       ; 0x50 <_exit>

0000002e <__bad_interrupt>:
  2e:  e8 cf         rjmp  .-48       ; 0x0 <__vectors>

00000030 <main>:

int main(void) 
{ 
  

  DDRB |= (1 << PB0);
  30:  b8 9a         sbi  0x17, 0  ; 23
  PORTB |= (1 << PB0)| (1 << PB1);
  32:  88 b3         in  r24, 0x18  ; 24
  34:  83 60         ori  r24, 0x03  ; 3
  36:  88 bb         out  0x18, r24  ; 24
  TCCR1 |= (1 << CS10) | (1 << CS11) | (1 << CS12) | (1 << CS13);
  38:  80 b7         in  r24, 0x30  ; 48
  3a:  8f 60         ori  r24, 0x0F  ; 15
  3c:  80 bf         out  0x30, r24  ; 48

  while(1) { 
  if(TCNT1 == 100) {
    PORTB ^= (1 << PB0);
  3e:  91 e0         ldi  r25, 0x01  ; 1
  DDRB |= (1 << PB0);
  PORTB |= (1 << PB0)| (1 << PB1);
  TCCR1 |= (1 << CS10) | (1 << CS11) | (1 << CS12) | (1 << CS13);

  while(1) { 
  if(TCNT1 == 100) {
  40:  8f b5         in  r24, 0x2f  ; 47
  42:  84 36         cpi  r24, 0x64  ; 100
  44:  e9 f7         brne  .-6        ; 0x40 <__SREG__+0x1>
    PORTB ^= (1 << PB0);
  46:  88 b3         in  r24, 0x18  ; 24
  48:  89 27         eor  r24, r25
  4a:  88 bb         out  0x18, r24  ; 24
    TCNT1 = 0;
  4c:  1f bc         out  0x2f, r1  ; 47
  4e:  f8 cf         rjmp  .-16       ; 0x40 <__SREG__+0x1>

00000050 <_exit>:
  50:  f8 94         cli

00000052 <__stop_program>:
  52:  ff cf         rjmp  .-2        ; 0x52 <__stop_program>

[Thomas E. (thomase)]

Das läuft auf meinem Attiny 25 so, wie du es dir vorstellst:

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

int main(void) 
{ 
  

  DDRB |= (1 << PB0) | (1 << PB1);
  PORTB |= (1 << PB0)| (1 << PB1);
  
  TCCR1 |= (1 << CS10) | (1 << CS11) | (1 << CS13);
  TCCR0B |= (1<<CS02) | (1<<CS00);


  while(1) 
  { 
    if(TCNT0 > 200) 
    {
      PORTB ^= (1 << PB0);
      TCNT0 = 0;
    }

    if(TCNT1 > 200) 
    {
      PORTB ^= (1 << PB1);
      TCNT1 = 0;
    }
  }
}

Mal eine ganz doofe Frage: Ziehst du eigentlich auch deinem Programmer 
ab, um zu testen? PB0 und PB1 liegen nämlich auf MISO/MOSI.

mfg.

[Jörg E. (jackfritt)]

Timer0 hat CS00-02 und Timer1 hat CS10-13 und die Bits liegen auch 
anders. Ich denke hier liegt dein Problem?

[A. F. (elagil)]

> Mal eine ganz doofe Frage: Ziehst du eigentlich auch deinem Programmer
> ab, um zu testen? PB0 und PB1 liegen nämlich auf MISO/MOSI.

Oh! :) den habe ich tatsächlich noch dran :D probier ich demnächst mal 
ohne ;)

> Timer0 hat CS00-02 und Timer1 hat CS10-13 und die Bits liegen auch
> anders. Ich denke hier liegt dein Problem?

nein, ich habe die richtigen bits gesetzt, siehe oben

[A. F. (elagil)]

Ich habe einen attiny45 auf breadboard an ein oszilloskop gehängt (PB0). 
Hier die Bilder und zugehörigen Codes:
Oszi-Einstellung: immer 10ms Timebase (damit komme ich auf ca.40 
ms/Periode, rechnerisch kommen 39ms raus, passt also)
0,1V/cm mit 1:10 Tastkopf -> 1V/cm (passt ungefähr)

Die Timer sind so definiert wie schon immer:
DDRB |= (1 << PB0) | (1 << PB1);
PORTB |= (1 << PB0)| (1 << PB1);

TCCR1 |= (1 << CS10) | (1 << CS11) | (1 << CS13);
TCCR0B |= (1<<CS02) | (1<<CS00);

1................. ganz seltsames bild ...
http://www.abload.de/img/dsc06341qjujl.jpg

if(TCNT1 > 200)
    {
      PORTB ^= (1 << PB0);
    TCNT0=0;
    TCNT1=0;
    }

2................. keine auslenkung ...
http://www.abload.de/img/dsc063421purk.jpg

if(TCNT1 > 200)
    {
      PORTB ^= (1 << PB0);
    TCNT1=0;
    }

3................. das normale rechteck ...
http://www.abload.de/img/dsc06343oxuq3.jpg

if(TCNT0 > 200)
    {
      PORTB ^= (1 << PB0);
    TCNT0=0;
    }

[Fred S. (kogitsune)]

Das *.lss Listing ist in Ordnung: Registeradressen und Code passen zum 
Attiny45.

"thomase" hat Dich auf den noch eingesteckten Programmer aufmerksam 
gemacht. Nachdem Du mir vorher geantwortet hattest, dass an PB0 sonst 
nichts mehr hängt, war wohl doch noch der Programmer dran... Ist er 
jetzt immer noch verbunden?

Bei praktisch jedem Deiner Code-Schnipsel hast Du ++mehrere++ Dinge 
geändert. In der *.lss Datei schreibst Du

 if (TCNT1 == 100)...

Jetzt wieder

 if(TCNT1 > 200)...

.
Mir ist zwar klar, dass das nicht ändern sollte, aber trotzdem ist das 
kein guter Stil für die Fehlersuche. Zusätzlich veränderst Du immer 
wieder den Wert für den Timer-Vorteiler. Das ist im Allgemeinen kein 
guter Ansatz, um einen Fehler einzugrenzen.

Was nötig ist, um hier weiterzukommen:
- Dein aktuelles Programm
- der Aufbau (gutes Foto, Schaltplan, am besten auch mit den 
Verbindungen zum Oszi sichtbar)

[Walter S. (avatar)]

Adrian Figueroa schrieb:
> TCCR1 |= (1 << CS10) | (1 << CS11) | (1 << CS13);
> TCCR0B |= (1<<CS02) | (1<<CS00);

da stimmt doch was mit deinen Bildern nicht, du stellst hier zwei total 
unterschiedliche Teiler ein, aber die sich ergebende Frequenz ist 
gleich???

[Electronics'nStuff (Gast)]

Damit nicht alle immer nachsehe gehen nmüssen..

[Electronics'nStuff (Gast)]

Walter S. schrieb:
> Du stellst hier zwei total unterschiedliche Teiler ein

Nein, beide Male 1024.

@TE Watchdog Fuse gesetzt beim Attiny?

[Fred S. (kogitsune)]

Electronics'nStuff schrieb:
> @TE Watchdog Fuse gesetzt beim Attiny?

Weiter oben hat der TE geschrieben, dass die High Fuse 0xDF ist, also 
ist der WDT aus.

[A. F. (elagil)]

> "thomase" hat Dich auf den noch eingesteckten Programmer aufmerksam
> gemacht. Nachdem Du mir vorher geantwortet hattest, dass an PB0 sonst
> nichts mehr hängt, war wohl doch noch der Programmer dran... Ist er
> jetzt immer noch verbunden?

nein, nicht mehr.


Hier bilder vom Aufbau mit dem Code:

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

int main(void) 
{ 
  

  DDRB |= (1 << PB0) | (1 << PB1);
  PORTB |= (1 << PB0)| (1 << PB1);

  TCCR1 |= (1 << CS10) | (1 << CS11) | (1 << CS13);
  TCCR0B |= (1<<CS02) | (1<<CS00);


  while(1) 
  { 


    if(TCNT1 > 200) 
    {
      PORTB ^= (1 << PB0);
    TCNT1=0;
    }
  }
}

Timebase immer noch 10ms, lange belichtet, damit man die Linie sieht.
Ich bekomme 5V Gleichspannung am Ausgang PB0.

http://www.abload.de/img/dsc0634525urq.jpg
http://www.abload.de/img/dsc06349s6u3u.jpg

[Thomas E. (thomase)]

Adrian Figueroa schrieb:
> Hier bilder vom Aufbau
Am Controller fehlt ein 100nF Stützkondensator.

mfg.

[Jörg E. (jackfritt)]

Hiermit gehts dann. Scheint was wegoptimiert zu werden?

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

int main(void)
{

  DDRB |= (1 << PB0) | (1 << PB1);
  PORTB |= (1 << PB0)| (1 << PB1);

  TCCR1 |= (1 << CS10) | (1 << CS11) | (1 << CS13);
  TCCR0B |= (1<<CS02) | (1<<CS00);

  while(1)
  {
    asm volatile("NOP");
    if(TCNT1 > 200)
    {
      PORTB ^= (1 << PB0);
    TCNT1=0;
    }
  }
}

[Fred S. (kogitsune)]

Thomas Eckmann schrieb:
> Am Controller fehlt ein 100nF Stützkondensator.
Sehe ich auch so. Mit kurzen Leitungen, möglichst direkt von Pin 8 nach 
Pin 4. Und da kein BOD aktiviert ist, gleich noch einen Widerstand (15 k 
oder so) von Pin 8 nach RESET.

[A. F. (elagil)]

> Hiermit gehts dann. Scheint was wegoptimiert zu werden?

Tatsächlich! :D

Im makefile steht: "optimization level s"

[A. F. (elagil)]

ich habe einen hinzugefügt, keine änderung. noch ein bild:

50mV/cm Gleichspannungskompensiert (Amplitude ca. 150mV), Timebase 0,1us 
bei 5-Fach streckung! Das sind dann ca. 17Mhz... ?! Ich weiß ja nicht, 
was das sein soll, ich tippe auf eine wertlose Messung ;)

http://www.abload.de/img/dsc06350v9xoz.jpg

aber es geht mit dem "nop"... seltsam, dass er das für timer0 dann 
drinlässt

[Jörg E. (jackfritt)]

Man kann mal die Profi´s fragen ob das ein Feature oder Bug is.
Hier liest bestimmt keiner mehr von denen mit :)

Sollte sich niemand melden einfach ein neues Thema aufmachen mit
aussagekräftiger Überschrift.

[A. F. (elagil)]

mach ich mal ;) danke für die hilfe :)

[Fred S. (kogitsune)]

Jörg Esser schrieb:
> Hiermit gehts dann. Scheint was wegoptimiert zu werden?
Wie bist Du darauf gekommen, Jörg?

[Walter S. (avatar)]

Adrian Figueroa schrieb:
> if(TCNT1 > 200)

lass das doch mal weg um zu sehen ob der Ausgang richtig toggelt oder ob 
die Abfrage nie erfüllt ist

[A. F. (elagil)]

das läuft einwandfrei

#include <avr/io.h>

int main(void)
{

  DDRB |= (1 << PB0);

  TCCR1 |= (1 << CS10) | (1 << CS11) | (1 << CS13);

  while(1)
  {
    if(1)
    {
      PORTB ^= (1 << PB0);
      TCNT1=0;
    }
  }
}

[Thomas E. (thomase)]

Jörg Esser schrieb:
> Hiermit gehts dann. Scheint was wegoptimiert zu werden?
Unsinn.

Ich weiss ja nicht, was der WAI da veranstaltet. Aber ein 
funktionierendes Programm habe ich ihm schon gestern abend geschickt:

Thomas Eckmann schrieb:
> Das läuft auf meinem Attiny 25 so, wie du es dir vorstellst:

Wenn er das nimmt, für den Attiny45 kompiliert, mit Optimierung -0s, 
dann läuft das auch. So ein Popelkram ist absolut Pillepalle. Dafür 
braucht man 5 Minuten, wenn überhaupt. Und nicht 2 Tage, die das jetzt 
schon dauert.
Da wird nichts wegoptimiert und da wurde jetzt auch kein Compilerbug 
entdeckt.
Es bringt überhaupt nichts an irgendwelchen Einstellungen, sei es an den 
CS-Bits noch an der Optimierung rumzuspielen. Der Fehler liegt irgendwo 
anders. Mit hoher Wahrscheinlichkeit sitzt er vor dem PC.
Weil die Watchdog-Fuse gesetzt ist, das falsche Hexfile geflasht wird, 
irgendein vermurxtes Makefile benutzt wird, an statt sich das erzeugen 
zu lassen oder was auch immer. Nein. Und der Controller ist auch nicht 
kaputt.

mfg.

[A. F. (elagil)]

Was soll ich sagen? Es läuft eben nicht, auch wenn der Code korrekt ist.
Ich habe ein neues makefile gemacht und die fuses neu geflasht...

hier mal das makefile, ist das vielleicht kaputt?

[Thomas E. (thomase)]

Adrian Figueroa schrieb:
> Was soll ich sagen? Es läuft eben nicht, auch wenn der Code korrekt ist.
> Ich habe ein neues makefile gemacht und die fuses neu geflasht...
> hier mal das makefile, ist das vielleicht kaputt?
Warum wurschtelst du dir damit überhaut einen ab? Lass dir das 
automatisch erzeugen.
Womit programmierst du überhaupt? Oder habe ich das irgendwo überlesen?

mfg.

[A. F. (elagil)]

> Warum wurschtelst du dir damit überhaut einen ab? Lass dir das
> automatisch erzeugen.

dafür nehme ich mfile aus dem winavr paket. mit winavr und programmers 
notepad schreibe ich auch.

[Thomas E. (thomase)]

Adrian Figueroa schrieb:
> dafür nehme ich mfile aus dem winavr paket. mit winavr und programmers
> notepad schreibe ich auch.
Installier dir AVR-Studio und du hast diese ganzen Probleme nicht.

mfg.

[Jörg E. (jackfritt)]

Also ich kann das hier nachvollziehen mit Winavr unter eclipse. Basta!
Keine Ahnung was avrstudio macht.
Um das ganz genau zu sehen muss man sich halt mal den ganzen Compile 
Prozess
und Assembler Code anschauen. Einmal mit NOP und einmal ohne.Fertig.

Sorry aufm iPad geschrieben.

[Thomas E. (thomase)]

Jörg Esser schrieb:
> rozess
> und Assembler Code anschauen. Einmal mit NOP und einmal ohne.Fertig.
Wenn der einzige Unterschied dabei, nicht das eingefügte NOP ist, ist 
das Ganze absoluter Müll.

mfg.

[A. F. (elagil)]

ich habe atmel studio ausprobiert. natürlich ist mein usbasp dazu nicht 
kompatibel, deswegen benutze ich avrdude zum flashen der .hex, die der 
debugger erzeugt: kommt das gleiche raus.

ich benutze die vorlage für den attiny45, also kann mein makefile nicht 
falsch sein!

Timer0 geht, Timer1 nicht.

[Walter S. (avatar)]

wenn es mit nop geht dann bitte die beiden assembler listing posten bzw. 
anschauen,
da müsste dann ja ein Unterschied zu sehen sein

[Fred S. (kogitsune)]

Und wo ist das NOP?

[A. F. (elagil)]

ich habe das falsche hochgeladen, darum gelöscht ;)

http://www.diffnow.com/?report=8293e

[Fred S. (kogitsune)]

Und auf den gelöschten Beitrag bezog sich mein Kommentar...!

[A. F. (elagil)]

eben, das mit dem nop habe ich gar nicht hochgeladen!

[F. F. (foldi)]

Jörg Esser schrieb:
> Sorry aufm iPad geschrieben.

:-) Das ist der beste Satz seit langem und nicht nur in diesem Thread.

[F. F. (foldi)]

Bin noch ziemlich neu in C und mit Timer hab ich auch nichts gemacht 
(kommt bald), aber da ich mit dem Tiny 13 was machen will mit C und 
schon gemacht habe, hab ich natürlich auch schon die Auswirkungen des 
fehlenden 100nF gespürt. Da kommt es zu so manchem komischen Verhalten.
Unter Timer 1 stand, dass er eine Pause von 100 µs braucht um sich zu 
stabilisieren. Kann das auch damit zu tun haben? Oder ist die Frage 
völlig bescheuert?

[A. F. (elagil)]

> Kann das auch damit zu tun haben?

aber dann sollte er doch nach 100us laufen? :)

[F. F. (foldi)]

Adrian Figueroa schrieb:
>> Kann das auch damit zu tun haben?
>
> aber dann sollte er doch nach 100us laufen? :)

Das ist eben die Frage, die ich mir stellte. Kommt er so überhaupt in 
den richtigen Takt?
Auch die 100nF sind so ein Ding. Hatte schon ganz viel mit nem ATmega 
328 gemacht und da gab es nie Probleme auf dem Steckbrett, auch ohne 
einen Kondensator und erst nachdem ich mir nicht erklären konnte, wieso 
der Tiny so ein merkwürdiges Verhalten an den Tag legte, machte ich mal 
die 100nF dazu und siehe da, alles lief wie es erwartet wurde.

Ohne, dass ich jetzt hier zur Schlacht um die Entwicklungsumgebung 
aufrufen will, aber ich schließe mich einem Vorredner an und finde es 
auch richtig das Atmel Studio zu nehmen.
Es ist ein Monster und auf meinem Netbook braucht es etwas, bis alles da 
ist, aber da das nun mal die neuste Software und das Zugpferd von AVM 
ist, finde ich sollte man das nehmen. Zumindest für Testzwecke, wenn es 
auf anderen Umgebungen Fehler gibt.

[A. F. (elagil)]

> finde es auch richtig das Atmel Studio zu nehmen.

ja, das überleg ich mir, nur wird mein programmer sowieso nicht direkt 
unterstützt (auch wenn das nicht unbedingt tragisch ist)

[F. F. (foldi)]

Adrian Figueroa schrieb:
>> finde es auch richtig das Atmel Studio zu nehmen.
>
> ja, das überleg ich mir, nur wird mein programmer sowieso nicht direkt
> unterstützt (auch wenn das nicht unbedingt tragisch ist)


So ein "Dragon" ist eine feine Sache und kostet nicht viel. Damit ist 
dann auch debuggen ne feine Sache.

Da ich selbst noch ein blutiger Anfänger bin, hat es was gebraucht bis 
ich beim Drachen war. Ist jetzt mein "Lieblingsspielzeug".

[Markus M. (adrock)]

Der Drachen ist das Schweizer Taschenmesser überhaupt... hatte mit dem 
STK-500 angefangen und mir dann bald den Dragon wg. USB geholt...

Programmieren (SPI, HV, JTAG, [PDI]), Onboard-Debuggen (JTAG, DebugWire) 
und das für fast alle AVRs von Tiny über Mega bis XMega. Was will man 
mehr?

Grüße
Markus

[holger (Gast)]

Echt Geisterstunde hier;)

C Code sieht gut aus, Assembler Listing sieht gut aus.
ATTin45 hat da sicher keinen Bug, das hätte man schon früher gemerkt.

Das einzige was scheisse aussieht ist der kleine einsame Käfer
auf dem Steckbrett. Man muss kein Hellseher sein um da
schlimmes zu denken.

Vieleicht hat er ja Timer1 per Fuse auf ATTiny15 kompatibel
gefused? Aber das würde es auch nicht erklären.

Ich bin mal gespannt ob hier noch irgendeine sinnvolle
Erklärung zu dem Phänomen rauskommt.

[Fred S. (kogitsune)]

Thomas Eckmann schrieb:
> Wenn er das nimmt, für den Attiny45 kompiliert, mit Optimierung -0s,
> dann läuft das auch. .....
Du lässt Dich hier ja ganz schön überheblich über den TE aus.
Ich hatte auch massive Zweifel, konnte die Ergebnisse des TEs aber mit 
einem Attiny45-20PU mit den o.g. Fuses (siehe 
Beitrag "Re: Attiny45, timer tut nichts?" ) 100% verifizieren.
Einen Attiny25 habe ich nicht da, kann also Dein Ergebnis hinsichtlich 
des Attiny25 nicht testen. Mit dem Attiny85 erhalte ich identische 
Ergebnisse wie unten beschrieben.
Kompiliert mit -Os (-O1 ändert nichts), Atmel Studio 6.0.1882, d.h. 
AVR_8_bit_GNU_Toolchain_3.4.0_663.
Hardware: Mit 5V betriebener Attiny45-20PU (Date code (?) 1108, auf der 
Unterseite steht noch "L8  TAIWAN 16") auf einem STK500.

Wie schon der TE fand, geht dies:

  while(1) {
    asm volatile("NOP");    
  6a:  00 00         nop
    if(TCNT1 > 200) {
  6c:  8f b5         in  r24, 0x2f  ; 47
  6e:  89 3c         cpi  r24, 0xC9  ; 201
  70:  e0 f3         brcs  .-8        ; 0x6a <main+0x14>
      PORTB ^= (1 << PB0);
  72:  88 b3         in  r24, 0x18  ; 24
  74:  89 27         eor  r24, r25
  76:  88 bb         out  0x18, r24  ; 24
      TCNT1 = 0;
  78:  1f bc         out  0x2f, r1  ; 47
  7a:  f7 cf         rjmp  .-18       ; 0x6a <main+0x14>

Das aber nicht:

  while(1) {
    //asm volatile("NOP");    
    if(TCNT1 > 200) {
  6a:  8f b5         in  r24, 0x2f  ; 47
  6c:  89 3c         cpi  r24, 0xC9  ; 201
  6e:  e8 f3         brcs  .-6        ; 0x6a <main+0x14>
      PORTB ^= (1 << PB0);
  70:  88 b3         in  r24, 0x18  ; 24
  72:  89 27         eor  r24, r25
  74:  88 bb         out  0x18, r24  ; 24
      TCNT1 = 0;
  76:  1f bc         out  0x2f, r1  ; 47
  78:  f8 cf         rjmp  .-16       ; 0x6a <main+0x14>

Bei identischer Initialisierung funktioniert (d.h. 20Hz Rechteck an PB0) 
auch Folgendes:

  while(1) {    
    if (TCNT1 > 200) {
      PORTB^=(1<<PB0);
  68:  91 e0         ldi  r25, 0x01  ; 1
{
  DDRB |= (1 << PB0) | (1 << PB1);
  PORTB |= (1 << PB0)| (1 << PB1);
  TCCR1 |= (1 << CS10) | (1 << CS11) | (1 << CS13);
  while(1) {    
    if (TCNT1 > 200) {
  6a:  8f b5         in  r24, 0x2f  ; 47
  6c:  89 3c         cpi  r24, 0xC9  ; 201
  6e:  e8 f3         brcs  .-6        ; 0x6a <main+0x14>
      PORTB^=(1<<PB0);
  70:  88 b3         in  r24, 0x18  ; 24
  72:  89 27         eor  r24, r25
  74:  88 bb         out  0x18, r24  ; 24
      TCNT1=0;
  76:  1f bc         out  0x2f, r1  ; 47
      asm volatile("NOP");
  78:  00 00         nop
  7a:  f7 cf         rjmp  .-18       ; 0x6a <main+0x14>

Relevant scheint das Nullen des TCNT1 zu sein, denn mit

  while(1) {    
    if (TCNT1 > 200) {
  6a:  8f b5         in  r24, 0x2f  ; 47
  6c:  89 3c         cpi  r24, 0xC9  ; 201
  6e:  e8 f3         brcs  .-6        ; 0x6a <main+0x14>
      PORTB^=(1<<PB0);
  70:  88 b3         in  r24, 0x18  ; 24
  72:  89 27         eor  r24, r25
  74:  88 bb         out  0x18, r24  ; 24
  76:  f9 cf         rjmp  .-14       ; 0x6a <main+0x14>

bekomme ich das erwartete Signal (schnelles Umschalten an PB0 bei jedem 
Durchgang wenn TCNT1>200) -- siehe Bild.
Dies wird auch bestätigt durch korrektes Funktionieren (Rechteck an PB0 
und Rechteck der halben Frequenz an PB1) hiervon:

  while(1) {    
    PORTB=TCNT1;  
  68:  8f b5         in  r24, 0x2f  ; 47
  6a:  88 bb         out  0x18, r24  ; 24
  6c:  fd cf         rjmp  .-6        ; 0x68 <main+0x12>

Die Ergebnisse bleiben entsprechend, wenn man für das Toggle des PB0

      PINB|=(1<<PB0);  
  6e:  b0 9a         sbi  0x16, 0  ; 22

schreibt, so dass nicht 3 Maschinenbefehle nötig sind.

Ich kann mich nicht erinnern, in den letzten Jahren je die Notwendigkeit 
gesehen zu haben, einen TC manuell auf Null zu setzen, wo es doch den 
CTC-Modus gibt! Das wird der größten Mehrheit der Entwickler so gegangen 
sein...
Ein Prozessor-Bug ist durchaus als Ursache denkbar, insbesondere da das 
Zusammenspiel der Verzögerungen beim TimerCounter1 beim Attiny45 im 
Datenblatt doch etwas kryptisch beschrieben ist.
Im Netz fanden sich Hinweise auf ein Problem mit dem TC1 beim Attiny45 
mit BASCOM. Da ich von BASCOM keine Ahnung habe und die entsprechenden 
Themen nicht verfolgt habe, weiß ich nicht, ob das ein reines BASCOM 
Problem ist/war, oder ob die BASCOM Entwickler auf das hier diskutierte 
mögliche Problem mit dem ATtiny45 hereingefallen sind.

[F. F. (foldi)]

@ Fred S. (kogitsune)
Hab auch noch ein paar von den Tinys. Danke für die deutlichen 
Ausführungen.
Dann weiß ich ja woran ich denken muss,  wenn ich mit den Timern 
Probleme kriege.

[Jörg E. (jackfritt)]

Ich konnte das bei mir auch mit einem atiny85 nachstellen.Sorry hatte 
ich vergessen zu erwähnen. Sogar auf einem Testboard, also nix mit 100nf 
etc.

[Jörg E. (jackfritt)]

Thomas schrieb er würde AVR-Studio nehmen. Was passiert dort?

[Markus M. (adrock)]

Hi,

Im Datenblatt steht beim TCNT1 Register...

"Timer/Counter1 is realized as an up counter with read and write access. 
Due to synchronization of the CPU, Timer/Counter1 data written into 
Timer/Counter1 is delayed by one and half CPU clock cycles in 
synchronous mode and at most one CPU clock cycles for asynchronous mode"

Das hört sich zumindest schonmal ein bisschen "verdächtig" an.

Evtl. läuft da wirklich etwas schief, wenn in sehr kurzen Abständen 
hintereinander auf das TCNT1 lesend/schreibend zugegriffen wird.

Normalerweise würde ich es auch immer vermeiden, schreibend auf den 
Counter zuzugreifen während er läuft.

Im Errata steht nix, aber das hat ja nichts zu sagen...

Grüße
Markus

[Adrian (Gast)]

> Normalerweise würde ich es auch immer vermeiden, schreibend auf den
> Counter zuzugreifen während er läuft.

Im Grunde macht der CTC Mode ja nichts anderes?

Beim Timer0 ist es zwar auch nicht weiter problematisch, das Nop bringt 
aber immerhin einen ganzen Takt mehr, das ist vielleicht genug.

[Fred S. (kogitsune)]

Noch eine Ergänzung:
Im Attiny15-Kompatibilitätsmodus (low Fuse 0xF3 [SUT1:0=0b11, 
CKSEL=0b0011], high Fuse 0xDF und extended Fuse 0xFF) führt dieser Code 
(Timer- und Port-Initialisierung wie oben, d.h.

  DDRB |= (1 << PB0) | (1 << PB1);
  PORTB |= (1 << PB0)| (1 << PB1);
  TCCR1 |= (1 << CS10) | (1 << CS11) | (1 << CS13);

) zu einem Rechtecksignal an PB0:

  while(1) {    
    if (TCNT1 > 200 ) {
  68:  8f b5         in  r24, 0x2f  ; 47
  6a:  89 3c         cpi  r24, 0xC9  ; 201
  6c:  e8 f3         brcs  .-6        ; 0x68 <main+0x12>
      PINB|=(1<<PB0);  
  6e:  b0 9a         sbi  0x16, 0  ; 22
      TCNT1=0;  
  70:  1f bc         out  0x2f, r1  ; 47
  72:  fa cf         rjmp  .-12       ; 0x68 <main+0x12>

Ändert man die low Fuse auf 0xE2, ist wieder ein NOP erforderlich, damit 
ein Rechtecksignal (natürlich anderer Frequenz!) entsteht:

  while(1) {    
    if (TCNT1 > 200 ) {
  68:  8f b5         in  r24, 0x2f  ; 47
  6a:  89 3c         cpi  r24, 0xC9  ; 201
  6c:  e8 f3         brcs  .-6        ; 0x68 <main+0x12>
      PINB|=(1<<PB0);  
  6e:  b0 9a         sbi  0x16, 0  ; 22
      TCNT1=0;  
  70:  1f bc         out  0x2f, r1  ; 47
      asm volatile("NOP");
  72:  00 00         nop
  74:  f9 cf         rjmp  .-14       ; 0x68 <main+0x12>

[Fred S. (kogitsune)]

Und noch ein Detail: Im asynchronen Clock-Modus geht's ohne NOP!

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

int main(void)
{
  // set async mode, wait until locked, make PLL clock for TC1 
  PLLCSR=(1<<PLLE);
  _delay_us(200); // datasheet: 100us should suffice
  while (!(PLLCSR&(1<<PLOCK)));
  PLLCSR|=(1<<PCKE);
  
  DDRB |= (1 << PB0) | (1 << PB1);
  PORTB |= (1 << PB0)| (1 << PB1);
  TCCR1 |= (1 << CS10) | (1 << CS11) | (1 << CS13);
  while(1) {    
    if (TCNT1 > 200 ) {
      PINB|=(1<<PB0);  
      TCNT1=0;  
      //asm volatile("NOP");
    }    
  }
}

(*.lss siehe Anlage; kompiliert mit F_CPU=8000000UL).
An PB0 steht ein 158 Hz Signal an. Das passt genau zum asynchronen 64 
MHz Takt für den TC1.

[Jörg E. (jackfritt)]

Um das Thema nochmal aufzuwärmen.
Es handelt sich um einen Bug im alten GCC.
Mit GCC 4.8 funktioniert nun der folgender Code.

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

int main(void)
{

  DDRB |= (1 << PB0) | (1 << PB1);
  PORTB |= (1 << PB0)| (1 << PB1);

  TCCR1 |= (1 << CS10) | (1 << CS11) | (1 << CS13);
  TCCR0B |= (1<<CS02) | (1<<CS00);

  while(1)
  {
    //asm volatile("NOP");
    if(TCNT1 > 200)
    {
      PORTB ^= (1 << PB0);
    TCNT1=0;
    }
  }
}

Wer sein WINAVR updaten möchte, für den gibts hier ne Anleitung
Beitrag "Update von Winavr2010 auf gcc 4.8 Howto"

[Fred S. (kogitsune)]

Hallo Jörg,

zeigst Du bitte auch die zugehörige *.lss? Das ursprüngliche Beispiel in 
c hatte ich mit Atmel Studio 6 (GCC 4.6.1) kompiliert.

Allerdings lässt sich das Problem auch mit Assembler nachweisen:

  .org 0        ; interrupt vectors not required, program starts right here 
            ; stack initialization not required
  eor r1,r1      ; clear reg
  sbi DDRB, 0
  sbi PORTB, 0
  ldi r16, (1 << CS10)|(1<<CS12) ; timer at F_CPU/16 = 500 kHz
  out TCCR1, r16
  
testcnt:
  in r16, TCNT1
  cpi r16, 201
  brcs testcnt
  sbi PINB, 0
  out TCNT1, r1    ; zero counter value
  //nop          ; 1 cycle
  rjmp testcnt    ; 2 cycles for jump

Mit auskommentiertem "nop" (wie im Listing oben) erhalte ich an PB0 das 
Signal "2 cycles", füge ich das "nop" ein, erscheint das Signal "3 
cycles" an PB0.

Gruß

Fred

[Fred S. (kogitsune)]

Vergessen zu erwähnen: Attiny im Beispiel läuft mit 8 MHz.