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.

Geh mal mit der Baudrate runter, solange du die grauslichen Rechnungen noch in der ISR hast, sonst geht sich die ganze Geschichte nicht in der Zeit aus.

Irgendwas stinkt da ganz gewaltig :-s
Denn wenn ich nun mit der Baudrate auf 9600 @1MHz runter geh, funktioniert die ISR wieder nicht mehr... :cry:

Au weia, d.h. die diversen Routinen sind nicht richtig synchronisiert und kommen sich, je nach timing, gegenseitig in die Quere oder manchmal nicht.
Ich muß mir mal deinen Code genauer anschauen, hilft nix.

ogottogott. wieso straft die leute keiner ?

was soll das nu heissen... :?: :?:

Das heißt, daß in der Appnote äußerst seltsame Dinge stehen.
Beispiel:
Beim Transmitten setzt er

Code:

---

  glob.u_status = (1<<BUSY)|(1<<TD);

---

(Und es ist ihm vollkommen wurst, ob er vielleicht gerade empfängt)

In der ISR fragt er aber ab:

Code:

---

  if(!(glob.u_status & TD))    STATT
  if(glob.u_status & (1<<TD))   
        wenn er senden will

---

*seufz* Wo find' ich die original AppNote ?



[/code]

Jo die Abfrage inner ISR fandsch auch scho etwas strange.. ist aber original so inner AppNote drinne. Habs nicht geändert!

siehe
http://www.atmel.com/dyn/resources/p...nts/AVR304.zip

http://www.atmel.com/dyn/resources/p...ts/DOC0941.PDF

Gut, ist verziehen, ich muß jetzt heim, vielleicht kann ich heut noch reinschauen. Sonst halt bis morgen.
(Die Beispiele in Appnotes sind manchmal nicht funktionsfähig)

es gibt eine einfache lösung.
lade dir die bascom-demo runter.
programmierst ein software-uart (geht in bascom) und wertest ihn mit avr-studio 4.0 aus. geht wunderbar. dann setzt du ihn in winavr-c . evtl kannst du die abgeänderte asm-datei direkt in winavr-c einbinden. geht auch klasse.
mfg pebisoft

Weis net mit bascom.. findst nich bissl umständlich ?? Würd ganz gern bei C bleiben, zumal ich mit Basic so gut wie nie gearbeitet hab.
Mich wundert auchn bissl, das hier sonst noch keiner die AVR304 AppNote versucht hat umzusetzen und auf die selben Probleme gestoßen ist... :-s
Naja irgndwie muß es doch eine Lösung dafür geben..

Guten Morgen !
Das spezielle an der Appnote ist die Interrupt-Lösung. BasCom arbeitet mit Zeitschleifen.
Ich hab mir die Asm-Version genau durchgelesen (meist besser ausgeführt als C), jetzt ahne ich, wessen Geistes Kind die Sache ist (etwas anders, als gedacht).
Ein grundsätzlichses Problem: Wenn du grad am senden / empfangen bist, killt die eine Funktion die andere, d.h der Host (Terminal) muß mitspielen mit der 1/2 Duplex Geschichte.
Also so locker im Hintergrund rennt das nicht.
Frage: Um was gehts denn in etwa auf dem eigentlichen Zielsystem (Tiny)?

Moin Moin !
Vorerst müßt ich eigntlich nur Daten Senden können, es ist aber durchaus für später vorgesehen auch mal was empfangen zu können (Mein erstes Ziel ist vorerst, die Daten, die ich später vom A/D Wandler bekomme ans Terminal zu schicken)
Hab grad eben auch nochmal angefangen die AppNote genauestens durchzulesen und es ist wirklich so vorgesehen, dass der externe Interrupt disabled ist, wenn gerade transmittet wird... (also kein Empfangen während Senden)
Meinst du Hyperterminal arbeitet Fullduplex und deswegen geht nix ??
Kann ich des irgndwie auf Halfduplex-Betrieb schalten ?
Aber wieso springt er bei manchen Einstellungen (Baud und Osc) in die ISR und wieso dann wieder nicht ?

EDIT:
Hab auch erst überlegt, ob ein polled Software UART sinnvoller wäre (gibt da auch eine AppNote) , aber ich kann ja net ständig abfragen ob ich was empfange..
Beim Senden isses egal, da ich die Werte in festen Intervallen senden werde.

Hi, ganz locker, keine Hypotenusen, solange wir nix wissen.
Ich schlag vor, wir ziehen auch mal das Senden durch (is einfacher) und sehen dann weiter.
Diese Art halfduplex müßten sich die UARTs untereinander ausmachen, da bleibt nur XON/XOFF, das geht immer und das kann auch jedes Terminal. (Oder Hardware-Handshake, ist aber unbequem, mehr Draht und mehr Arbeit)
Jetzt blasen wir mal "hello" rüber, ich bin drauf

Oki. Also die RX Routinen rausschmeissen und XON/XOFF probieren..

Ich will nicht verschweigen, daß da noch eine Ecke ist. Wenn du transparente Daten (binäre Meßwerte) überträgst, ist das mit der gleichzeitigen Verwendung von ASCII-Steuerzeichen nicht ganz trivial.
Egal, .---> "Hello" or bust

Versteh ich jetzt nicht so ganz, wie du das meinst mit den Steuerzeichen...

Hab die RX Routine mal rausgeschmissen. Auch die Initialisierung des externen Interrupts.
Die Zeile:
if(!(glob.u_status&TD)) // Transmit section
in der ISR hab ich ebenfalls raus, da ja nicht mehr geprüft werden muß, ob TX oder RX.

Funktionieren tuts trotzdem net, auch kein blinken oder so..

Steuerzeichen: Wenn du als Meßwert ein short ( 0- 1023) auf die Reise schickst, kannst du dir vorstellen, daß da bald mal ein Steuerzeichen drin vorkommt, das ja gar keins sein soll. Und eine Umwandlung short--> Ascii ist mühsam.

Ich schau mir timer0 gleich an

Es ist leider auch nirgends beschrieben, wie der TCNT0 und der Reload Wert zustande kommt... müßte man evtl anpassen ?? :|

Das steht in der AppNote.
Vorschlag: Step by Step

Machen wir mal nix, als irgendeinen Timer0-Interrrupt, der nix tut, außer LED blinken. Nix senden, garnix. Nur aufsetzen, enablen. In der ISR nur den TCNT0 nachladen, nix herumswitchen.

Prescaler --> 8
TCNT0 = 48
das gibt bei 16 MhZ eine frequenz von 9600

Oder andere XTAL ?

Auf jeden Fall muß mal der Timer schnackeln, das ist ja lächerlich

Sorry Mittagessen !! O:)

Mir wären die 3.686 MHz vom Board fürs erste lieber (kann leider keine 16 MHz)
D.h. also für die Einstellungen:
C = 8 (Prescaler)
XTAL = 3.686 MHz
Baudrate = 9600
--> N = Xtal / (BaudRate*C) = 3.686 MHz / ( 9600*8 ) = ~ 48

--> TCNT0 = 256 - N + (14/C) = 256 - 48 + 14/8 = ~ 210

Hier das simple Prog:
Die LED's blinken (noch... :wink:)

So. Ich hab' mal einfach dazugeschrieben, was ich meine.

Konzept: Pfeif' auf alle Extras. Back to the roots.
der Timer tickt einfach in der Baudrate, (9600 /sec)
(ev. basteln mit preload)
Will man was senden, schreibt man das Zeichen hin, und setzt einen Flag
und den Status "start"

Durch den Flag wird die ISR lebendig und macht je nach Status was anderes

1 x Start Bit
8 x Datenbit
1 x Stop
1 x stopbit stehenlassen, clear flag

Ich kann es hier nicht probieren, vielleicht fehlt wo ein semikolon, ein bißchen Liebe braucht das halt.

Is klar, wie's gemeint ist ?

Jo ist klar wie's gemeint ist, habs mir gerade angeschaut! THX !!
Wo hast das so schnell hergezaubert :-)

Beim compilieren gibts noch "expected an expression" wegen dem TX_M_SEND..
brauch ich doch bloß #define TX_M_SEND 0 ??
als Bit 0 von bTxFlag quasi..

Haltaus nein, _M_ ist eine Maske (privater standard)

#define TX_M_SEND 1 // oder 2 , 4, 8 etc.

Nix zu danken, erst wenn's funzt, gibt's du einen aus

kannst die asm-datei von bascom dann gedanklich in winavr-c umsetzen.
bisschen denken musste schon. so setze ich auch lösungen teilweise von bascom in c um wenns nichts anderes gibt.
mfg pebisoft

@schamp: Ich schau mir das am Wochenende mit dem Oszi an, das sind ein paar Sachen seltsam.
Laß es inzwischen gut sein.
Ich rühr mich zuverlässig

hm ok !! thanks a lot !! osci hab ich leider keines daheim.
wollt morgen nochmal weiter probieren

Hi, schamp, Zwischenbericht:
Ich hab bei meiner RNBFRA (Mega32) elegant die Hw-Uart deaktiviert und versuche, den Pin TxD zu Fuß zu bedienen. (dort hängt ja der Max drauf).
Super Idee, geht aber nicht, weil ich auf dem Pin den Pegel nicht auf Low bekomme, ergo geht das Ganze mal nicht. Auf einem Anderen ist das kein Problem, aber da ist kein Max drauf. Zum Mäusemelken !
Vom Timing etc. schaut das gut aus, TImer Interrupt macht kein Problem.
Auch die Rs232 Signale schauen ja nicht schlecht aus, d.h. der Weg stimmt, aber eben--> der Pegel.
Ich hab im Datasheet nix gefunden, warum das so sein könnte, hast du eine Idee ? Irgendwas funkt mir dazwischen.
*nerv*
Egal, von so einem Kistel laß' ich mich nicht verschaukeln, das ziehen wir durch.

Moin Moin !!
Und es läuft *juhuu* 8)
Bin das ganze Programm nochmals durchgegangen. 2 Zeilen geändert und dann isses gelaufen

beim case TX_C_START, das Startbit auf LOW

PORTD &=~(1<<PD4); // Set Start Bit (LOW)

und case TX_C_STOP, Stopbit auf HIGH

PORTD |=(1<<PD4); // Set Stopp Bit (High)

(siehe auch Atmel AppNote !)

Stells gleich online, kommentier es noch ein bissl ausführlicher

btw:
Jetzt könnt ma eigentlich eine eigene AppNote schreiben und diese veröffentlichen :mrgreen:
_C_ steht bei dir für CASE oder ?

nochwas: mit Hyperterminal funktionierts nicht... nehmt lieber Tera Term...

Moin ! Ich hab gehofft (befürchtet) daß daß ein Pseudoproblem ist ,d.h. nur bei mir, weil ich den TxD Pin verwende.
In der App-Note ist ein Durcheinander, was Hi und Lo betrifft. TTL ist ja active HIGH, Rs232 Active LOW, also start und stop genau verkehrt.
Das hast du ja Gottseidank gesehen. Freu mich auf deine Doku.

Jetzt brauchen wir nurmehr das Empfangen gescheit einzubauen.

Hyperterm ist die Strafe des Herrn für schwere Sünden.

Richtig gesehn, ich hab die Konvention
_C_ Konstante Zahl (z.b. für select u. vergleiche/Parameter 0 - juchuu)
_V_ für Bit-Offset 0-32
_M_ Bit maske ( MUH_M_KUH = (1<< MUH_V_KUH)
u. alles, was mit #define definiert ist, schreib ich in Uppercase
Sind so Hilfen, damit ich auch in einem Jahr meine Programme noch lesen (nachvollziehen) kann.
Ich freu mich !

So.. kurz Zeit gehabt zu kommentieren und ein paar Baudraten-Einstellungen zu testen. :)
Ab 38400 Baud macht er nimmer mit.. (reicht aber völlig aus, wie ich finde)
Mach mich dann an die Receive-Routinen ran.