Timer0 Overflow Interrupt löst nicht aus (ATmega16)

[PicNick]

Irgendwie glaub' ich, wir sind voll in einer Panikattacke und neigen zu sinnlosen Aktionen

Wir haben doch ein Programm gehabt, mit einem Timer, der offenbar in der richtigen Zeit mit der richtigen Baudrate auch längere Daten tadellos wegschicken konnte. (ich hab das zu Hause auch mit längeren Strings versucht).
Wenn der also prinzipiell im richtigen Bitraster tickert (TIM0_PRELOAD), geht's doch nurmehr darum, durch das Start-Bit das Lesen zu starten und die Ticks so zu verschieben (INT0_PRELOAD), daß die Timer-ISR immer die Mitte der Datenbits erwischt. Punkt.

Das hatten wir eigentlich auch, insofern, daß INT0 ausgelöst und TIME0 freigegeben hat, diese hat auch pipifein bis 9 gezählt und einen Flag gesetzt.
Also funktionell eigentlich alles richtig, bis auf das "y".

Was KANN denn falsch sein ?
Prescale u. normaler Preload muß wohl stimmen. (--> senden geht ja)

Es kann doch nur darum gehen, daß INT0 entweder
falsch getriggert wird
unerwünscht mehrfach getriggert wird
den TImer nicht richtig enabled
sein 1 1/2 Bit Preload falsch ist
den Timer funktionell irgendwie beeinflußt

Vielleicht sollten wir die ursprüngliche "y" Version wieder herstellen und uns das nochmal in Ruhe genau anschauen

Kannst du mir die HEX file dann mal posten, damit ich sie analysieren kann (ich hab da was spezielles)

[schamp]

"y"-Version wieder hergestellt.
Was dabei noch auffällt ist, das bei Sonderzeichen, Zahlen und Steuerzeichen statt nem "y" auch öfters ma ein "þ" kommt.
Bei Buchstaben dagegen nur "y".

[PicNick]

Kannst du noch die HEX posten ?

[schamp]

Hexfile ist im Intel extended Format.
Was hast du da für ein Programm und wie kann man damit Hexfiles analysieren ??

args ich benenns ma schnell in *.txt um, dann gehts wahrscheinclih
ok geht... mußt dann wieder in *.a90 umbenennen

[PicNick]

Das ist von mir eine Art Disassembler, der aber mehr nach logischen Aspekten angelegt ist und mehr parametrisierbar ist.

[PicNick]

Ui, mit dem Format komm' ich und auch der AVR-Studio nicht zurecht.
Kannst du nicht das normale intel Hex erzeugen ?

[schamp]

Hm komisch mit AVR Studio programmier ich auch immer Hexfile aufn Controller..
Habs ma in Intel Standard erzeugt, vielleicht gehts jetzt
Ist allerdings auch wieder nen *.a90

[PicNick]

Sodala.

Ich hab jetzt im Programm rumgezangelt und auch mit dem Datsheet abgematcht.
Es ist jetzt die SW- Echo Version, die wir in etwa haben wollen

Ein paar enables-disables haben nicht gestimmt

Zusatz: die Funktion send_one_byte kommt erst zurück, wenn senden fertig ist
Und erst NACH dem gesendeten Echo wird INT0 wieder enabled, damit uns keiner reinpfuscht.
Die INT0-ISR wird auch nur tätig , wenn NICHT gesendet UND NICHT empfangen wird. (für's erste mal)



Übrigens ich mußte doch erst die Hex mit dem Pony einlesen und dann wieder wegschreiben, weil AVR-Studio hat gemeint, das Zeugs wäre irgendwo Korrupt. is egal.

EDIT: noch was: das direkte echo ist ein bißchen im Programm verteilt,

[schamp]

Was für enables und disables warn des dann ??
Kannst du den Code noch posten ?

[PicNick]

*ähem* irgendwie hast du recht

In der INT0-ISR hat er durch setzen statt löschen den Timer SOFORT ausgelöst, d.h. INT0-Preload ist unwirksam, wir lesen das Startbit mit
das ist woanders auch vorgekommen, daher hab ich mir diese enable-disable-orgien dann alle einzeln zur Brust genommen.

Naja, schau'n wir, ob wir vom Y wegkommen. Aber ab jetzt versuchen wir ruhig zu bleiben.