ATmega16 mit Timer0 will nicht

[Jey B. (jeybee)]

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

[Lord Z. (lordziu)]

Joel B. schrieb:
> PORTD ^= (1<<PD0);

Probiers mal so:

    PORTD = PIND ^ (1<<PD0);

Ports werden mittels "PINx" eingelesen.

[Hc Z. (mizch)]

> 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 :).

[ich (Gast)]

> 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.

[Jey B. (jeybee)]

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.

[ich (Gast)]

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?

[ich (Gast)]

Nimm doch ein Teiler von 1024 und versuch damit.

[Jey B. (jeybee)]

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

[Lord Z. (lordziu)]

Wie ist die LED denn angeschlossen?

[Lord Z. (lordziu)]

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?

[ich (Gast)]

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)

[Lord Z. (lordziu)]

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.

[ich (Gast)]

hab mich verschrieben, statt der 1 die 0 setzen

[Werner (Gast)]

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.

[Hc Z. (mizch)]

> 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.

[Werner (Gast)]

Vielleicht bringt auch ein Schaltplan Licht ins Dunkle.

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

Werner

[ich (Gast)]

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.

[Jey B. (jeybee)]

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

[Werner (Gast)]

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!

[..]

[Jey B. (jeybee)]

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

[MWS (Gast)]

Falsche MCU in Makefile eingestellt ? Der Code funktioniert einwandfrei.

[Jey B. (jeybee)]

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

[MWS (Gast)]

Na, dann versuch' mal das hex File hier. Oder poste Deins.

[Jey B. (jeybee)]

Dein .hex File tuts auch nicht... :(

Im Anhang ist mal meines dabei.

[MWS (Gast)]

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 ?

[Jey B. (jeybee)]

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 :(

[ich (Gast)]

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

[Karl H. (kbuchegg)]

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.

[Stefan B. (stefan)]

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!

[Jey B. (jeybee)]

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

[Karl H. (kbuchegg)]

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.

[Jey B. (jeybee)]

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

[Karl H. (kbuchegg)]

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.

[MWS (Gast)]

> 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.

[Jey B. (jeybee)]

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

[Stefan E. (sternst)]

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.

[MWS (Gast)]

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

[Jey B. (jeybee)]

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

[Karl H. (kbuchegg)]

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?

[ich (Gast)]

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

[ich (Gast)]

Du muss bei dir nur
> |(1<<CS01) wegnehmen.

[ich (Gast)]

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.

[Lord Z. (lordziu)]

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.

[ich (Gast)]

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

[Jey B. (jeybee)]

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

[Lord Z. (lordziu)]

Kannst du denn mal einen Schaltplan posten?

[MWS (Gast)]

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.

[nobody (Gast)]

Sollte i nicht volatile deklariert sein??

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

Ist das so gewollt?

[Jey B. (jeybee)]

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.

[Karl H. (kbuchegg)]

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.

[ich (Gast)]

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.

[Karl H. (kbuchegg)]

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?

[ich (Gast)]

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.

[MWS (Gast)]

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

[Jey B. (jeybee)]

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

[Chris (Gast)]

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

[Jey B. (jeybee)]

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

[seiner einer (Gast)]

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ß

[seiner einer (Gast)]

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

[Chris (Gast)]

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

[MWS (Gast)]

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.

[Jey B. (jeybee)]

@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

[MWS (Gast)]

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.

[Chris (Gast)]

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

[MWS (Gast)]

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.

[MWS (Gast)]

> Relais LS1 mit einer Frequenz von 62Hz beaufschlagt wird ?

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

[Jey B. (jeybee)]

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

[Karl H. (kbuchegg)]

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?

[Jey B. (jeybee)]

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.

[Karl H. (kbuchegg)]

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.

[Karl H. (kbuchegg)]

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.

[MWS (Gast)]

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.

[Oliver (Gast)]

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

[Jey B. (jeybee)]

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.

[Karl H. (kbuchegg)]

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.

[MWS (Gast)]

> 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.

[Jey B. (jeybee)]

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

[Oliver (Gast)]

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