Timer0 Overflow Interrupt löst nicht aus (ATmega16)

Weis gerade nicht mehr weiter.
Versuche die AppNote AVR304: Half Duplex Interrupt Driven Software UART
auf einem ATmega16 zu implementieren (Ich weis das ATmega16
Hardware-UART hat, muß aber später auf einen Tiny umsteigen)

Nun zu meinem Problem:
Ich kann weder Zeichen senden, noch empfangen. Zumindest erscheint am
Terminal nichts (habe Hyperterminal und Tera Term ausprobiert).
Einstellungen sind/waren jeweils 38400 Baud, 8 Datenbits, 1 Stopbit,
kein Paritätsbit, keine Flusssteuerung.
Für die Übertragung nutze ich die RXD/TXD Pins (richtig gesteckt ;-))
und den RS232 Spare Port auf dem STK500. Dann gehts weiter an den COM2 Port meines PC's.
Als Clock benutze ich jetzt die STK500 @3.686 MHz.
Fuse (Ext. Clock; Start-up time: 6 CK + 0 ms; [CKSEL=0000 SUT=00]) und
Jumper (XTAL1 Jumper mounted, OSCSEL auf default) auf dem STK500
sollten laut "Help" (AVR Tools User Guide) richtig gesetzt sein.
Nutze den mitgelieferten C-Code von Atmel und compile mit IAR Embedded Workbench Kickstart.

Die Software habe ich etwas anpassen müssen (Registerbezeichnungen,
etc.). Habe zusätzlich ein paar Zeilen, die LED auf dem STK500 blinken lässt (zum testen) geschrieben, welche in der Overflow Interrupt-Routine ausgeführt werden sollten.
Leider wird diese aus mir unerklärlichen Gründen nie ausgeführt.. bin mir aber eigentlich schon sicher, das ich den Timer0 richtig initialisiert habe.
Please Help, weis nicht mehr weiter O:)
Thx !

Hab den Quellcode mit angehängt !
In main() sollte testweise nur ein "Hallo" ans Terminal gesendet werden..

Ich schreibe normalerweise unter AVR-Gcc da werden anstelle von _interrupt die Makros SIGNAL verwendet. Evtl gibts die da auch?!
Ist __enable_interrupt eine Funktion der Lib? Hast du einen Max dazwischen? Sind Rx und Tx gedreht? Was kommt dabei raus wenn du ein Scope oder Fox anschliesst?Für meinen Geschmack ist die Interruptroutine tim0_ovf ein bisschen lang. Evtl kannst du das mit in die Hauptroutine nehmen...aber das nurso nebenbei ;-)

Gruss
Michael

Hi !
Das mit __interrupt und __enable_interrupt ist mit IAR schon ok so.
Ein Max ist auf dem STK500 Board mit drauf und RX bzw TX sind richtig rum. Oszi oder ähnliches hab ich leider nicht zur Verfügung.
Hab das Programm nochmals "Schritt für Schritt" aufgebaut und geschaut, wo es hängt. Sobald ich etwas ins TCNT0 Register lade (in der uart_transmit() die Zeile mit TCNT0 = (256-N+(14/C)); // Set timer delay to first bit) wird nicht mehr in die ISR gesprungen.
Kann sein, das die Interrupts einfach wieder disabled werden ???
Wenn ich die Zeile testweise auskommentiere wird die ISR durchlaufen allerdings auch nur einmal.
Kann mir jemand erklären warum dem so ist ?
Die Software sollte doch eigentlich einwandfrei laufen. Denke die Leute bei Atmel werden sich bei der AppNote schon was gedacht haben und nicht einfach fehlerbehaftete Software publizieren. Vom eigentlichen Ablauf und Aufbau des Codes sind für mich auch keine groben Fehler ersichtlich...
Fällt noch jemanden was diesbezüglich auf ??
Bin für jede Hilfe dankbar !

Gruß
schamp

Hallo,

ich hab mal so ein bischen schnell die code durchgeguckt

GIFR = (1<<INTF0); // clear Interrupt Flag
GICR = (1<<INT0);

hier werden zB die ganze bytes geschrieben und nicht nur die einzelne bits!

sollte mann nicht '|=' nutzen statt '='?

GIFR |= (1<<INTF0); // clear Interrupt Flag
GICR |= (1<<INT0);

damit die andere 7 bits von GIFR und GICR ungeandert bleiben...

gruss

Henk

Hi !

Hab das jetzt mit GICR und GIFR ausprobiert, aber hat sich leider nichts geändert. Ich befürchte irgndwas stimmt nicht mit Timer0 und TCNT0...
Keine Idee wie man das lösen könnte...

Deine Konstanten solltest du vom Precompiler vorher ausrechnen lassen, so ist ja das Tierquälerei
EDIT Schau mal in der .Lss-File, was du dem armen Kerl damit antust

Datentypen: Der C neigt dazu, das Zielfeld als type für alles zu nehmen.
Also
TCNT0 = (256-N+(14/C));
Type ist char , also ist 256 schon mal nurmehr NULL

Hallo,

da bin ich wieder...

dass mit
TCNT0 = (256-N+(14/C));
glaube ich nicht so direct dass es falsch ist, aber konnte so sein

innerhalb die timer0 overflow interrupt wird die overflow-interrupt-enable
wieder ausgeschaltet
TIMSK = 0;
weshalb? jetzt wird durch die timer0 kein neuer overflow-interrupt generiert.

Dass clearen der interrupt flag innerhalb die interrupt function
GIFR = (1<<INTF0)
braucht mann hier nicht den durch das nutzen/anwenden vom interrupt function wird diesen Flag hardwaremassig ge-cleared.

Zitat:

---

The flag is cleared when the interrupt routine is executed.

---

Seite 68 vom .pdf


gruss mal wieder

Henk

Laut Datsheet (wie du es sagst), macht er das selber (Wenn ISR-Routine)
Also nur den Counter refreshen.

Was er genau wie rechnet etc., kann man im Listing kontrollieren.
Laß es aber so oder so den Precompiler machen.

Jo das mit precompiler werd ich mir noch anschauen.
TIMSK = 0 in der ISR habe ich jetzt mal gelassen. Hab die TIMSK Initialisierung aus der uart_init() rausgeschmissen und dafür in die uart_transmit(). Somit dürfte es mit TIMSK = 0 in der ISR keine Probs geben.
Hab jetzt auch testweise Fuse auf int. RC Osz und 1 Mhz (anstatt die 3.686 MHz vom STK500) geändert und siehe da, die LEDs blinken....
Hyperterminal zeigt aber weiterhin nichts an, außer das der Cursor plötzlich nicht mehr gleichmäßig blinkt 8-[

Werden vielleicht die RX / TX Leitungen zu vertauschen sein (ausgekreuzt)
Denn wenn irgendwas reinkommt, schreibt er zumindest irgendeinen Müll auf den Schirm
Ich hab aber deine hand-made-uart nicht nachgecheckt, das geb' ich zu.