mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ATmega16 mit Timer0 will nicht


Autor: Jey Bee (jeybee)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nabend,

Ich bin hier wirklich gerade am verzweifeln. Ich versuche eine LED mit 
dem Timer0 eines ATmega16 zu Toggeln. Jedoch funktionirt mein Code 
anscheinend nicht. Compilieren kann ich jedoch ohne Probleme.

Wo ist mein Fehler?
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
#include <util/delay.h>

int main(void)
{
   DDRD = 0xFF;

 
     TCCR0 =(1<<WGM01) |(1<<CS01);
     OCR0=125;
 
     TIMSK|=(1<<OCIE0);
     sei();
  
  while(1)
  {

  }
 
}
 

ISR (TIMER0_COMP_vect)
{
  PORTD ^= (1<<PD0);
}


Danke
Greez Jey

Autor: Lord Ziu (lordziu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joel B. schrieb:
> PORTD ^= (1<<PD0);

Probiers mal so:
    PORTD = PIND ^ (1<<PD0);

Ports werden mittels "PINx" eingelesen.

Autor: Hc Zimmerer (mizch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ports werden mittels "PINx" eingelesen.

Man kann genauso gut das zuletzt Geschriebene invertieren, also wie 
ursprünglich PORT nehmen.  Das tut's für diesen Zweck gleich gut.

@jeybee:  Dir ist schon klar, dass (überschlagsweise, 8 MHz-Takt 
angenommen) um die 4 kHz Toggle-Frequenz herauskommen?  Wenn Du nicht 
messen, sondern etwas sehen möchtest, musst Du schon sehr schnell 
schauen :).

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Jedoch funktionirt mein Code anscheinend nicht.

Was heißt er funktioniert nicht? Leuchtet die LED oder nicht?
Ich weiß nicht mit welcher Frequenz der ATmega läuft, aber vieleicht 
siehst du das Toggeln nicht. Rechne mal aus wie schnell die LED toggelt.

Autor: Jey Bee (jeybee)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin

Also, der ATmega16 läuft mit 16MHz. Von dem her sollte die LED ja jetzt 
durchgehend leuchten, oder?

Wenn ich den obigen Code flashe  leuchtet einfach keine LED.

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kannst du dir vorstellen wie schnell die LED toggelt. Du hast eine 
Frequenz von 16MHz und einen Teiler von 8 also kommst du auf 
Timerfrequenz von 2MHz. Wenn du ausrechnest mit welcher Frequenz deite 
LED toggelt, kommst du auf 8kHz, dass heißt deine LED ist 0.25ms an und 
0.25ms aus. Denkst du, du siehst da was?

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nimm doch ein Teiler von 1024 und versuch damit.

Autor: Jey Bee (jeybee)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin

ALso mit Prescale auf 1024 habe ich das selbe ergebnis... eine LED, die 
andauernt aus ist. Das Oszilloskop bringt auch kein sauberes Reckteck 
signal am Ausgang.

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

int main(void)
{
   DDRD = 0xFF;

 
     TCCR0 =(1<<WGM01) | (1<<CS00) | (1<<CS02);
     OCR0=125;
 
     TIMSK|=(1<<OCIE0);
     sei();
  
  while(1)
  {

  }
 
}
 

ISR (TIMER0_COMP_vect)
{
  PORTD ^= (1<<PD0);
}

Autor: Lord Ziu (lordziu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie ist die LED denn angeschlossen?

Autor: Lord Ziu (lordziu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joel B. schrieb:
> ALso mit Prescale auf 1024 habe ich das selbe ergebnis... eine LED, die
> andauernt aus ist. Das Oszilloskop bringt auch kein sauberes Reckteck
> signal am Ausgang.

Was heißt denn kein sauberes Rechteck? Kannst du ein Foto oder 
Screenshot posten?
Hängst du am richtigen Pin? Has das Oszi richtige Masse?

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich bin nicht sicher, aber ich glaube du benutzst die falsche ISR. Ich 
glaube du muss die TIMER1_OVF_vect benutzen (aber wie gesagt, bin mir 
nicht sicher)

Autor: Lord Ziu (lordziu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um erstmal zu testen, ob deine LED richtig angeschlossen ist, kannst du 
auch erstmal auf den Timer verzichten:

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

// CPU Freq definieren
#define F_CPU 16000000UL

int main(void)
{
   DDRD = 0xFF;
  
  while(1)
  {
      PORTD = PIND ^ (1<<PD0);
      // sleep Funktion mit 1000ms
      for(uint8_t i=0; i<10; i++)
      {
          _delay_ms(100);
      }
  }
}

Achtung! DU musst prüfen, ob die Codezeilen so richtig sind, hab es nur aus dem Kopf hingeplottet.


Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hab mich verschrieben, statt der 1 die 0 setzen

Autor: Werner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ISR ist schon ok.
Er benutzt erstens den Timer0, da kann er mit einer Timer1-ISR nix 
anfangen und zweitens will er keinen Interrupt beim Overflow, sondern 
beim Compare-Match.

Autor: Hc Zimmerer (mizch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich glaube du muss die TIMER1_OVF_vect benutzen

Er verwendet aber Timer 0.  Und, wenn ich das richtig sehe, im 
CTC-Modus.  Somit ist der Compare Interrupt schon richtig.

Autor: Werner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht bringt auch ein Schaltplan Licht ins Dunkle.

Ist zwar keine Große Sache, aber wer weiß...

Werner

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist ja gut, ich habe auch geschrieben, dass ich nicht sicher bin und 
dass ich mich verschrieben habe.

Nachdem ich im datenblatt nachgeschaut habe, weiß ich jetzt auch, dass 
er die richtige ISR verwendet.

Autor: Jey Bee (jeybee)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin.

 also die LED ist wie folgt angeschlossen:



   AVR           Resistor       LED

 PortD.0 >------| 150R |---------|>-------|GND



Ohne Timer kann ich die LED auch zum leuchten/blinken bringen, es liegt 
also nicht an der Hardware.

zum Oszi: Kein sauberes Rechteck heisst, dass da nur rauschen zu sehen 
ist.


Greez Jey

Autor: Werner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir ist gerade aufgefallen, dass es mal einen ganz ähnlichen Thread gab:

Damals lag es anscheinend am Compiler!

Beitrag "Atmega 32, 8-Bit Timer(Timer 0)"

Wenn es bei Dir nicht am Code und nicht am Aufbau liegt, könnte das 
weiterhelfen...

Zitat:

[..]

>Hallo zusammen,
>danke für eure zahlreichen Hilfen! Ich habe das Problem endlich gelöst.
>Es lag alles nur an der von mir verwendeten Enwicklungsumgebung!
>Ich benutzte das auf dieser Seite vorgestellte AVR-Plugin für Eclipse
>http://www.mikrocontroller.net/articles/AVR_Eclipse
>den folgenden Hinweis habe ich jedoch übersehen:

>WARNUNG: Bei mir funktionierten Timer-Interrupts mit dem Plugin nicht
>(die jedoch tadellos mit der WinAVR Makefile fuktionierten). Vielleicht
>habe ich nur eine Option übersehen, seid aber auf der Hut. Wenn ihr
>Unregelmäßigkeiten bei IRQs feststellt, versucht's erstmal ohne das
>Eclipse-Plugin (bevor ihr stundenlang an eurem Code und euch selbst
>zweifelt :-) ).

>Habe mich dann nach Alternativen umgeguckt und bin hier fündig geworden:
>http://sourceforge.net/projects/avr-eclipse

>Damit funktioniert alles einwandfrei!

[..]

Autor: Jey Bee (jeybee)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich verwende das AVRstudio4 von Atmel mit den neusten updates.
WinAVR ist auch auf dem aktuellsten Stand der Dinge

Als Programmer nutze ich den AVRISP MKII direkt von Atmel


Greez Jey

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falsche MCU in Makefile eingestellt ? Der Code funktioniert einwandfrei.

Autor: Jey Bee (jeybee)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nope, Makfile stimmt (Mega16 mit 16Mhz)
Es wird auch das richtige .hex geflasht....

Und wie gesagt... an der Hardware liegt es nicht, mit einem Delay in der 
Main geht das ja.


Greez Jey

Autor: MWS (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Na, dann versuch' mal das hex File hier. Oder poste Deins.

Autor: Jey Bee (jeybee)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Dein .hex File tuts auch nicht... :(

Im Anhang ist mal meines dabei.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dein hex File ist ok, tut genau das, was es soll, disassembliert und 
auch simuliert.

Ich seh' auch keine Fuses, die solch eine Wirkung haben können, sicher 
die BOOTRST, aber da würde auch kein Blinken per Delay in der Mainloop 
funktionieren, da würde ohne Bootloader gar nix gehen.

Anderen Portpin ausprobiert, oder mal den OVF Int ausprobiert, natürlich 
dann ohne CTC ?

Wird beim Code für's Blinken per Delay in der Main der gleiche Potrtpin 
verwendet ?

Autor: Jey Bee (jeybee)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jap, es wird mit dem Blinken über ein Delay der selbe Portpin verwendet.
Fuses sind wie folgt:


High: 0xD9
Low:  0xBF


Ich bin echt ratlos :(

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
!!Nur ein Vorschlag!!
Wie währs wenn du OC0 Ausgang verwendes um die LED zu Toggeln.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Probier mal folgendes Programm aus
#ifndef F_CPU
#define F_CPU 16000000
#endif

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

int main(void)
{
   DDRD = 0xFF;

   PORTD |= (1<<PD0);
   _delay_ms( 500 ); 
   PORTD &= ~(1<<PD0);
   _delay_ms( 500 );


     TCCR0 =(1<<WGM01) | (1<<CS00) | (1<<CS02);
     OCR0=125;
 
     TIMSK|=(1<<OCIE0);
     sei();
  
  while(1)
  {

  }
 
}
 

ISR (TIMER0_COMP_vect)
{
  PORTD ^= (1<<PD0);
}

Das schaltet am Anfang die LED für 0.5 Sekunden ein.
Wenn deine LED jetzt scheinbar mit 0.5 Sekunden blinkt, dann wird dein 
µC aus irgendeinem Grund ständig resettet.

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist oder war vielleicht mal der Watchdog aktiviert und jetzt resettet 
sich der Atmega16 bevor es zum Toggeln der LED kommt? Ein einmal 
aktivierter Watchdog überlebt das Neuflashen und futschelt dann in 
Programmen rum, die an sich keine Watchdogaufrufe haben!

Autor: Jey Bee (jeybee)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nun, das Programm von Karl funktioniert einwandfrei... Die LED blinkt im 
500ms Takt, njedoch halt nicht über den timer...
Wie kann es denn sein, das mein Controller immer geresettet wird?
ALso extern habe ich einen Pullup am RESET Pin. Der Watchdog sollte 
standartmässig ausgeschaltet sein und manuel verändert habe ich ihn auch 
nicht.

Zudem haben zig andere Programme auf dem Microcontroller bisher 
funktioniert (LCD Ansteuern, ADC auslesen, normales I/0 etc...).


Greez Jey

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joel B. schrieb:

> Wie kann es denn sein, das mein Controller immer geresettet wird?

> Zudem haben zig andere Programme auf dem Microcontroller bisher
> funktioniert (LCD Ansteuern, ADC auslesen, normales I/0 etc...).

Wenn du tatsächlich 0.5 Sekunden ein / 0.5 Sekunden aus siehst und es 
nicht der Watchdog ist, dann stimmt der INterrupt Vektor nicht. Der ISR 
Aufruf 'geht dann ins Leere', eigentlich auf den Default Handler, und 
der resettet den µC.

Also noch mal kontrollieren:
Im AVR Studio ist der richtige Controller eingestellt?
Der Interrupt Vektor heißt tatsächlich so?
Gibt es Warnungen beim Compilieren?


Edit:
Watchdog kannst du leicht kontrollieren.
Mach aus den 500 Millisekunden mal 5000
Dann hast du 5 Sekunden an/aus
Das ist länger als der Watchdog braucht um zuzuschlagen.
Hast du 5 Sekunden ein/aus, dann ist es nicht der Watchdog.

Autor: Jey Bee (jeybee)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
MCU und deren Taktfrequenz wurden im AVRstudio4 richtig eingestellt. 
Fuses stimmen soweit eigentlich auch.

Im Anhang die .hex
Hier nochmal das Programm:
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
#include <util/delay.h>

#ifndef F_CPU
#define F_CPU 16000000
#endif

int main(void)
{
  DDRD = 0xFF;

  PORTD |= (1<<PD0);
  _delay_ms( 500 ); 
  PORTD &= ~(1<<PD0);
  _delay_ms( 500 );


  TCCR0 =(1<<WGM01) | (1<<CS00) | (1<<CS02);
    OCR0=125;
    TIMSK|=(1<<OCIE0);
    sei();
  
    while(1)
    {

    }
 
}
 

ISR (TIMER0_COMP_vect)
{
  PORTD ^= (1<<PD0);
}

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joel B. schrieb:
> MCU und deren Taktfrequenz wurden im AVRstudio4 richtig eingestellt.
> Fuses stimmen soweit eigentlich auch.

Na denn.
Wenn alles richtig eingestellt ist (was wir nicht kontrollieren können) 
und das Programm richtig ist (was wir kontrollieren können)
kurz und gut: wenn alles richtig ist

dann muss es auch funktionieren.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> High: 0xD9
> Low:  0xBF

Passt auch.

@Karl Heinz,

da wird schon der richtige Vektor angesprochen, aus dem hex File:
+00000000:   940C002A    JMP       0x0000002A     Jump
+00000002:   940C0047    JMP       0x00000047     Jump
+00000004:   940C0047    JMP       0x00000047     Jump
+00000006:   940C0047    JMP       0x00000047     Jump
+00000008:   940C0047    JMP       0x00000047     Jump
+0000000A:   940C0047    JMP       0x00000047     Jump
+0000000C:   940C0047    JMP       0x00000047     Jump
+0000000E:   940C0047    JMP       0x00000047     Jump
+00000010:   940C0047    JMP       0x00000047     Jump
+00000012:   940C0047    JMP       0x00000047     Jump
+00000014:   940C0047    JMP       0x00000047     Jump
+00000016:   940C0047    JMP       0x00000047     Jump
+00000018:   940C0047    JMP       0x00000047     Jump
+0000001A:   940C0047    JMP       0x00000047     Jump
+0000001C:   940C0047    JMP       0x00000047     Jump
+0000001E:   940C0047    JMP       0x00000047     Jump
+00000020:   940C0047    JMP       0x00000047     Jump
+00000022:   940C0047    JMP       0x00000047     Jump
+00000024:   940C0047    JMP       0x00000047     Jump
+00000026:   940C0054    JMP       0x00000054     Jump
+00000028:   940C0047    JMP       0x00000047     Jump
An 54 ist der Comp Handler, der Code simuliert auch korrekt.

Autor: Jey Bee (jeybee)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aus verzweiflung habe ich nun auch schonmal zweimal die MCU getauscht... 
immer mit dem selben ergebnis. Ich werde heute Abend mal den Code zu 
Hause an andere Hardware ansehen.

Ich werd mich melden.


Bis die Tage

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann ist es wohl an der Zeit, mal die etwas "verrückteren" Möglichkeiten 
abzuchecken. Bist du gaaaanz sicher, auch wirklich die HEX-Datei in den 
Chip zu programmieren, und nicht etwa die ELF-Datei? Das hätte nämlich 
auch genau die beobachteten Auswirkungen.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Versuch' mal das hier:
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
#include <util/delay.h>
#include <avr/wdt.h>

int main(void)
{
  wdt_disable();
    DDRD = 0xFF;
   
  PORTD |= (1<<PD0);
  _delay_ms( 500 ); 
  PORTD &= ~(1<<PD0);
  _delay_ms( 500 );   
 
  TCCR0 =(1<<WGM01) | (1<<CS00) | (1<<CS02);
    OCR0=125;
      TIMSK=(1<<OCIE0);
     sei();
  
  while(1)
  {

  }
 
}
 

ISR (TIMER0_COMP_vect)
{
  PORTD ^= (1<<PD0);
}

Autor: Jey Bee (jeybee)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

Also ich habe jetzt mal den Code von MWS geflasht und die LED blinkt 
jetzt im Sekundentakt. Wenn ich folgenden Teil auskomentiere, bleibt die 
LED wieder dunkel:
  PORTD |= (1<<PD0);
  _delay_ms( 500 ); 
  PORTD &= ~(1<<PD0);
  _delay_ms( 500 );  


Sonst noch jemand eine Idee?


Greez Jey

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schön langsam nicht mehr.

Probier mal einen anderen Port. Das Programm an sich ist in Ordnung. 
Aber irgendetwas wirft den µC aus der Bahn. Das kann genausogut ein 
elektrisches Problem sein.

Wie sieht deine µC Beschaltung aus?

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe den Quellcode von MVS auf mein ATmega128 geladen, habe da noch 
was veränder und es funktioniert wunderbar.

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

#ifndef F_CPU
#define F_CPU 16000000
#endif

uint8_t i=0;

int main(void)
{
  DDRD = 0x01;

  TCCR0 =(1<<WGM01)|(1<<CS00)|(1<<CS02)|(1<<CS01);
    OCR0=125;
    TIFR &= ~(1<<OCF0);
    TIMSK|=(1<<OCIE0);
    sei();

    while(1)
    {

    }

}


ISR(TIMER0_COMP_vect)
{
  i++;
  if(i==5)
  {
    PORTD ^= (1<<PD0);
  }
}

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du muss bei dir nur
> |(1<<CS01) wegnehmen.

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Als das Programm geladen habe so wie es war, hat es auch nicht 
funktioniert.
Ich habe nur TIFR &= ~(1<<OCF0); den Flag gelöscht und das Toggeln in 
der ISR verlangsammt. Vielleicht liegt es daran.

Autor: Lord Ziu (lordziu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Wie sieht deine µC Beschaltung aus?

Seh ich genauso. Alles deutet darauf hin, dass dein µC resettet wird. 
Und da wir hier auf der Software- und Fuses-Seite nahezu alles 
ausgeschlossen haben, kann es fast nur noch an der Schaltung liegen.

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also um das Flag zu löschen, muss du es auf 1 setzen und nicht aus 0 
(mein Fehler), hat aber trotzdem funktioniert.

Autor: Jey Bee (jeybee)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich habe jetzt mal mim Oszilloskop am Resetpin (der btw. einen 
Pullup besitzt) nachteschaut -> von Extern wird der AVR nicht 
geressetet.

Autor: Lord Ziu (lordziu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kannst du denn mal einen Schaltplan posten?

Autor: MWS (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Da der Watchdog auch auszuschließen ist, kann's (fast) nur an der 
umgebenden Hardware liegen. Was für ein Aufbau ? Platine, Steckbrett ? 
100n von VCC nach GND am µC ? Welche Stromversorgung ?

Versuch mal anhängende Hexfiles, stack_test schiebt 3 Bytes auf den 
Stack und holt sie wieder. Wenn's dabei einen Fehler gibt, dann geht die 
Led an, wenn's fehlerfrei war bleibt sie aus. Ein falsch initialisierter 
Stack könnte genau solche Fehler wie hier erzeugen. Wobei in dem von Dir 
geposteten Hexfile der Stack für den ATM16 richtig initialisiert wird, 
aber probieren schadet ja nix.

Isr_blink ist das das gleiche Blinkprogramm per ISR, nur in Bascom 
geschrieben. Einfach mal ausprobieren.

Bei 64Hz wäre allerdings nur ein Dimmen wahrnehmbar.

Autor: nobody (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sollte i nicht volatile deklariert sein??

In der Isr passiert nur bei i==5 was, die restlichen 255 Male nichts!

Ist das so gewollt?

Autor: Jey Bee (jeybee)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
beim stack_test.hex ist keine LED am leuchten, leider genausowenig bei 
der isr_blink.hex

Die Schaltung poste ich später, da der Schaltplan nicht auf dieser Kiste 
zu finden ist.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nobody schrieb:
> Sollte i nicht volatile deklariert sein??

Das passt schon so.

> In der Isr passiert nur bei i==5 was, die restlichen 255 Male nichts!

Damit teilt er die ISR Frequenz noch weiter runter, nämlich durch 256. 
Ob da jetzt mit 5 oder mit 0 verglichen wird, spielt nicht mehr so die 
grosse Rolle.

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es sollte in der if-Abfrage auf 0 gesetzt werden. Aber so was passiert, 
wenn man keine Zeit zum Durchlesen hat und schnell was reinstellt.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich schrieb:
> Es sollte in der if-Abfrage auf 0 gesetzt werden. Aber so was passiert,
> wenn man keine Zeit zum Durchlesen hat und schnell was reinstellt.

:-)
Lernen wir alle mal. Egal wie simpel dein Code ist, es gibt immer eine 
Chance für Fehler.

Ich müsste jetzt im Datenblatt nachsehen, aber ich denke die Vorteiler 
Bits vom Mega128 unterscheiden sich nicht großartig vom Mega16. Und bei 
dem hab ich nachgesehen:
TCCR0 =(1<<WGM01)|(1<<CS00)|(1<<CS02)|(1<<CS01);

Aha. Vorteiler: externer Clock an T0

Sicher, das du das willst?

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei dem 128 ist es fcpu/1024. ich habe späteter auch gesehen, dass bei 
dem 16 es ein ext. Clock ist, deswegen habe ich auch geschrieben, dass 
er den CS01 wegnehmen soll.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> beim stack_test.hex ist keine LED am leuchten, leider genausowenig bei
> der isr_blink.hex

Erstes ist gut, zweites weniger, wobei das funktionierender Code ist, 
dann würde ich mal auf HW tippen.

Hab' gerad' noch gesehen, daß Du die BODEN Fuse gesetzt hast, mach' mal 
die raus und probier's nochmal.

Wäre dann Fuses Low = 0xFF & High = 0xD9, wenn ich das richtig sehe.
Sollte es dann gehen, dann wäre es der Brownoutreset der für den 
Neustart sorgt. Der darf natürlich unter normalen Betriebsbedingungen 
nicht auslösen. Tut er's doch, ist's die Elektrik :D

Konfigurier' mal testweise nur den Pin, der auch Ausgang werden soll als 
solchen:
  DDRD = (1<<PD0);

Autor: Jey Bee (jeybee)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, nun habe ich wieder Zeit.

Der Schaltplan liegt leider nur stückweise im Anhang, da ich i-wie 
unfähig bin, das "Print to file" .prn in ein jpg umzuwandeln (was ja 
auch nicht sinn und zweck ist).

Ansonsten biete ich auch gerne direkt das gesamte OrCAD File an. Wie man 
jedoch sieht, ist da nichts spezielles mit an Board. Zudem kann ich ja 
alles andere "per Hand" zum blinken bringen.

Auch das deaktivieren des BODEN Fuses hat nichts gebracht.


hier nochmal der aktuelle Code:
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
#include <util/delay.h>

int main(void)
{
    DDRD = 0xFF;
     

  TCCR0 =(1<<WGM01) | (1<<CS00) | (1<<CS02);
  OCR0=125;
  TIMSK=(1<<OCIE0);
  sei();
  
  while(1)
  {

  }
 
}

ISR (TIMER0_COMP_vect)
{
  PORTD ^= (1<<PD2);
}



Gruss Jey

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab mir nur mal kurz den Schaltplan angesehen, am µC könnte bzw. sollte 
man noch an VCC ein 100nF Kondensator gegen Masse führen und am Resetpin 
wäre ein Elko mit 4,7µF gegen Masse auch nicht falsch.

Grüße
Chris

Autor: Jey Bee (jeybee)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klar könnte das nicht schaden, aber bisher ging es ja auch...
Dennnoch habe ich nun 100nF gegen Masse und auch dem Resetpin einen 
Kondensator spendiert. Doch noch immer herst dunkelheit.


Gruss Jey

Autor: seiner einer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So funtioniert dieser Timermodus nicht!
Du brauchst die ISR nicht. Ließ dir mal das Datenblatt genau durch.
Die Zeile TIMSK = ... verhindert in diesem Fall das die LED getoggelt 
wird

Gruß

Autor: seiner einer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich seh gerad das du Timer 0 verwenden möchtest. Da gibt es kein WGM01 
bit.
Wenn du Timer 1 verwendest wird das PORT vom Timer wie gesagt 
automatisch getoggelt ohne ISR

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joel B. schrieb:
> TCCR0 =(1<<WGM01) | (1<<CS00) | (1<<CS02);
>   OCR0=125;
>   TIMSK=(1<<OCIE0);


sollte das nicht heißen
TCCR0 |= (1<<WGM01) | (1<<CS00) | (1<<CS02);
TIMSK |= (1<<OCIE0);

hast du da nicht vor dem = den Operator |  vergessen?

Ohne die setzt er bei mir die Bits auch nicht.

@ seiner einer
WGM01 gibt es laut Datenblatt

grüße

Autor: MWS (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Dir ist schon klar, daß wenn die 12V Versorgungsspannung anliegt, Relais 
LS1 mit einer Frequenz von 62Hz beaufschlagt wird ?

Willst Du eine Teslaspule bauen ? :D
Du  produzierst wahrscheinnlich solche Störungen, daß Dir der µC schon 
bei den ersten Takten aussteigt.

Klemm die 12V Versorgung mal ab und probier's nochmal.
Bzw. nimm das angehängte Hex, das toggelt den Pin in 
Relais-verträglichen Raten, aber per Timer0 ISR.

Autor: Jey Bee (jeybee)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Chris:  Oh! du hast ja recht, wie peinlich! :(

Jedoch war das leider NICHT die Lösung... Ich habe es inzwischen auch 
mit- und ohne ISR probierte... beides erfolglos....


@seiner einer: Also da sehe ich kein Problem?!

Hier nochmals der Aktuelle Code:
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
#include <util/delay.h>

int main(void)
{
    DDRD = 0xFF;
     

  TCCR0 |= (1<<WGM01) | (1<<CS00) | (1<<CS02);
  OCR0=125;
  TIMSK |= (1<<OCIE0);

  sei();
  
  while(1)
  {

  }
 
}

ISR (TIMER0_COMP_vect)
{
  PORTD ^= (1<<PD2);
}




Greez Jey

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris:
> hast du da nicht vor dem = den Operator |  vergessen?
Den "|=" ODER Zuweisungsoperator nimmt man nur, wenn das Register 
bereits konfiguriert wurde, und man zusätzlich ein Bit setzen will.

Wenn das Register dagegen das erste Mal beschrieben wird, dann ist sogar 
ein "=" besser, denn das sorgt für einen definierten Anfangszustand.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte auch mal ein Programm da hab ich diese zuerst weggelassen. Das 
Programm lieft nicht. Dann habe ich sie hinzugefügt und das Programm 
lief.
Seit dort schreibe ich es immer nur noch so. Da sich der Fehler auch 
immer wieder so herstellen lies.

Grüße

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris:
> Ich hatte auch mal ein Programm da hab ich diese zuerst weggelassen.
> Das Programm lieft nicht. Dann habe ich sie hinzugefügt und das
> Programm lief.

Das hängt vollständig vom Aufbau Deines Programmes ab. Wenn z.B. irgend 
eine eingebundene und vorab aufgerufene Funktion bereits das Register 
konfiguriert hat, dann führt ein "=" natürlich zum Überschreiben der 
Konfiguration.

Beim hier vorgestellten Code ist das jedoch nicht der Fall, der ist sehr 
einfach. Das "|=" schadet nicht, denn nach dem Einschalten ist TIMSK 
gleich 0 und damit wird einfach ein ODER mit 0 vorgenommen.

Wenn man aber wirklich eindeutig festlegen möchte, daß ein Register 
einen bestimten Inhalt hat und keinen weiteren, möglicherweise vorher 
abgelegten, dann nimmt man die "=" Version.

Deshalb war es ganz sicher kein Fehler von Joel.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Relais LS1 mit einer Frequenz von 62Hz beaufschlagt wird ?

Korrektur, nach dem letztem Codebeispiel quälst Du Relais LS2 :D

Autor: Jey Bee (jeybee)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ne, da geht ja nix... man hört nix und das Oszi zeigt sich auch 
unbeeindruckt :(

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jey Bee schrieb:

> Jedoch war das leider NICHT die Lösung... Ich habe es inzwischen auch
> mit- und ohne ISR probierte... beides erfolglos....

Wie ist das zu verstehen: Du hast es ohne ISR probiert.
Du hast WAS ohne ISR probiert?

: Wiederhergestellt durch Moderator
Autor: Jey Bee (jeybee)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
seiner einer schrieb:
> Ich seh gerad das du Timer 0 verwenden möchtest. Da gibt es kein WGM01
> bit.
> Wenn du Timer 1 verwendest wird das PORT vom Timer wie gesagt
> automatisch getoggelt ohne ISR

Auf disen Post hin habe ich einfach mal die ISR auskommentiert....

Nur so by the way: das Relais ist zur Zeit eh nicht aufgelötet.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jey Bee schrieb:
> seiner einer schrieb:
>> Ich seh gerad das du Timer 0 verwenden möchtest. Da gibt es kein WGM01
>> bit.
>> Wenn du Timer 1 verwendest wird das PORT vom Timer wie gesagt
>> automatisch getoggelt ohne ISR
>
> Auf disen Post hin habe ich einfach mal die ISR auskommentiert....

Oh Mann
Du kannst nicht einfach eine ISR auskommentieren.

Ein freigegebener Interrupt benötigt eine ISR.
Hast du sie nicht, dann gibt es auf jeden Fall einen Reset.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also
Zusammendassend:

Eine LED-Blinkschleife in main() funktioniert. Die LED blinkt. Du kannst 
auch ausschliessen, dass das Blinken durch Reset erfolgt.

Dieselbe LED Ansteuerung in einer ISR vom Timer 0 funktioniert nicht.


Kann man das so sagen.
Speziell der Punkt: ... ohne das ein Reset erfolgt
ist wichtig.

Autor: MWS (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Du hast ein Problem im Schaltplan, erst einmal muss der µC Pin PD1, wenn 
Du den ganzen Port als Ausgang setzt, gegen den TXD Ausgang des FT232RL 
anarbeiten, wenn der TXD auf 1 steht.

Zweitens ist der FT232RL falsch angeschlossen, RXD zu RXD und TXD zu 
TXD. Keine Ahnung, ob das sich hier mit Restarts auswirkt, nur wird 
Deine USB Schnittstelle so sicher nie laufen.

Im angehängten Hex hab' ich mal nur PD2 als Ausgang gesetzt und lass' 
per ISR mit 1Hz blinken.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Oh Mann
> Du kannst nicht einfach eine ISR auskommentieren.

Natürlich kann Oh Mann das ;-)

Manche Programmkonzepte muß man sich halt schwer erarbeiten.

Oliver

Autor: Jey Bee (jeybee)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da mir das mit dem FT232RL schon aufgefallen ist, habe ich hier schon 
lange die zwei Leitungen getrennt. Dies dürfte also keinen Einfluss 
nehmen.


Beim Programm von MWS passiert wiederum nix.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jey Bee schrieb:
> Da mir das mit dem FT232RL schon aufgefallen ist, habe ich hier schon
> lange die zwei Leitungen getrennt. Dies dürfte also keinen Einfluss
> nehmen.

Keine AHnung, ob es anderen auch so geht wie mir:
Aber bei deinem Schaltplan blick ich nicht mehr durch. Zudem hast du das 
alles offenbar auch schon modifiziert.

Mein Vorschlag:
Nimm den Mega16 aus seiner Fassung.
Dann misst du die Spannung am Sockel am besagten Pin.
Dort sollte eigentlich 0V sein und wenn du mit 5V drauf gehst, müsste 
deine LED leuchten (Stromaufnahme messen)

Zudem würde ich mir an deiner Stelle den programmierten Mega16 in einen 
einzelnen Sockel setzen, den freihand verdrahten (den Mega auf internen 
RC-Oszillator umfusen) und nachsehen ob die LED blinkt. Für diese 
Freihandverdrahtung reicht es allemal aus, einfach nur die 
Versorgungsspannung (und noch 100nF zwischen Vcc und GND) anzulegen. 
Mehr braucht es nicht, damit das Teil läuft.

Ziel der Übung ist es, den Mega ohne deine ganze Rundumschaltung (die 
offenbar nicht getestet wurde) in Betrieb zu nehmen um zunächst alle 
Einflüsse aus der Umgebungsbeschaltung auszuschliessen.

Sonst suchst du (und wir) uns hier noch einen Wolf.

Autor: MWS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Beim Programm von MWS passiert wiederum nix.
Du hast ein schwerwiegendes Hardware Problem. Jedesmal, wenn ich ein Hex 
gepostet hab', lief das vorher als Simulation durch's AVR Studio, das 
funktioniert also sicher.

Ich finde die 33pF am Quarz ein wenig zu dick geraten, DB empfiehlt 
12-22pF. Möglicherweise arbeitet der Quarzoszillator nicht stabil, 
sollte eigentlich zu keinem Reset führen.

Wenn Du die CKOPT Fuse programmierst, bekommst Du auf alle Fälle eine 
kräftigere Schwingung, das solltest Du noch ausprobieren.

Vom Schaltplan her wäre der aktuelle Ist-Stand wichtig, und nicht der 
Soll-Stand. Noch dazu wenn der Schaltplan als Patchwork gepostet wird, 
dann wird das hier nur noch zum Rätselraten.

Autor: Jey Bee (jeybee)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe nun mal folgenden alten Code ausgegraben:
#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
#include <util/delay.h>
#include "lcd.h"


volatile unsigned int  millisekunden=0;
volatile unsigned int  sekunde=0;
volatile unsigned int  minute=0;
volatile unsigned int  stunde=0;
unsigned char buffer[10];

int main(void)
{
  DDRD = 0xFF; 

 
   TCCR0  =(1<<WGM01) |(1<<CS01);
   OCR0     =  128;
   TIMSK  =  (1<<OCIE0);
   sei();
   
   
   
   lcd_init(LCD_DISP_ON);
   lcd_clrscr();
   
   
   
   
   while(1)
   {
   lcd_clrscr();
   lcd_home();
   lcd_puts(itoa(stunde,buffer,10));
   lcd_puts(":");
   lcd_puts(itoa(minute,buffer,10));
   lcd_puts(":");
   lcd_puts(itoa(sekunde,buffer,10));
   _delay_ms(300);
   }
 
}
 

ISR (TIMER0_COMP_vect)
{
   millisekunden++;
   if(millisekunden==1000)
   {
      sekunde++;
      millisekunden=0;
      if(sekunde==60)
      {
         minute++;
         sekunde=0;
      }
      if(minute ==60)
      {
        stunde++;
        minute=0;
      }
   }
   PORTD ^= (1<<PD7);

}

Der Code funktioniert soweit, dass die LED an PD7 immer an ist, aber das 
LCD sichtbar die Zahlen hochzählt (nicht im sekundentakt)
Wenigstens weiss ich jetzt, dass der Timer läuft, wo der Hardwarefehler 
mit PD7 ist, weis ich trotzdem nicht (das Relais ist angeschlossen)

Nunja, danke für euere Hilfe und euere Gedult


Gruss Jey

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jey Bee schrieb:
> wo der Hardwarefehler
> mit PD7 ist, weis ich trotzdem nicht (das Relais ist angeschlossen)

Wie wärs mal mit: nicht raten, sondern messen.

Oliver

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.