Timer0 Overflow Interrupt löst nicht aus (ATmega16)

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)

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

Kannst du noch die HEX posten ?

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

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

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

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

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

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,

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

*ähem* irgendwie hast du recht :oops:

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.

Lief nicht gleich auf Anhieb, hab aber noch geändert:

TCCR0 &= ~(1<<CS00);
und
TCCR0 &= ~(1<<CS02);

~ haben gefehlt

Und jetzt ganz ruhig bleiben: hÐÿâþaÿøþlÿlØÿoÞÿ 8-[

Tilde vergessen, pfui gack. :Haue

Keep cool: du mußt jetzt mal auf bestimmte Zeichen wechseln, damit wir die richtige Richtung kriegen
Probier mal einfach <ENTER> drücken, das ist 0x0D. und dann shauen wir, was rauskommt.
geht darum, hauptsächlich die LSBits zu setzen

Zitat:

---

Zitat von PicNick

In der INT0-ISR hat er durch setzen statt löschen den Timer SOFORT ausgelöst, d.h. INT0-Preload ist unwirksam,...

---

Damit meinst du schon das Overflow Flag oder ? Dachte erst man muss das durch setzen einer logisch 1 löschen, so stand glaubsch im Datenblatt..
Habs jetzt aber nicht nochmal geändert

Zur Taste ENTER --> da kommt genau ein ÿ

Eigentlich bei allen interrupts isses so, daß dann, wenn Global enable = 1 UND specific enable = 1 UND specific signal = 1 die ISR ausgelöst wird.
(datasheet)
ENTER jetzt sollt man wissen, aber welchen Zeichen NICHT y kommt.


EDIT interessant sind auch single Bit-Zeichen
<space> "@"

4x Space-Taste:

@þSPACEÿ`þSPACEÿ`þSPACEÿ@þSPACEÿ
also immer in 4er Päckchen

werd da nicht unbedingt schlau draus, vorallem läuft das net nach einem bestimmten Muster

Nochmal:
auf EINMAL <leertaste>
kriegst du z.B.
@þSPACEÿ

also 0x'40' und noch drei andere ?

by the way: hast du beim Terminal VT100 Mode eingestellt ?

Jep auf einmal Leertaste 4 Zeichen (0x20 eigntlich, im Post jetzt als SPACE angedeutet. Sorry wenns nicht ganz klar war/ist)
das @ (0x40) kommt ab und zu als erstes Zeichen

Jo beim Terminal ist VT100 eingestellt. Für was ist das gedacht ?

VT100 : wegen den Sonderzeichen. diese komischen "b" mit verlängerung find ich bei mir nicht
Wenn er 0x20 als 0x40 liest, ist er eigentlich zwei Bits zu weit. ( Hat zur Folge, daß er sofort ein neues Byte beginnt-und sendet-und ein paar Bytes braucht, bis er sich wieder erfangen hat)
Da T0-Preload ja wohl nicht auf einmal falsch sein kann, muß es einen anderen Grund geben.
ein falsches INT0-Preload würde das eigentlich nicht erklären.
*denk*

Halt, stop, retour: das erste Zeichen, das du siehst, ist ja das direkte echo. das TERMINAL ist schon beim 4.Bit

kannst du das direkte echo auskommentieren, das verwirrt jetzt

EDIT (und schauen, was jetzt auf <space> kommt ?

das komische verlängerte b ist 0xfe oder 0xde (nach der Tabelle http://www.manderby.com/informatik/a...ines/ascii.php)

Tilden eingefügt, direkt-echo entfernt.

(wir produzieren ja damit einen 50% Baudraten fehler durch das 0.5 Bit

´Sorry musste wech vorhin..
Habs jetzt nomma ausprobiert:

HÿAÿLÿLÿOÿ ÿ?ÿ?ÿ?ÿ?ÿ?ÿ ÿtÿeÿsÿtÿ ÿ.ÿ.ÿ.ÿ.ÿ.ÿ ÿ@ÿ@ÿ@ÿ@ÿ@ÿ@ÿ@ÿ ÿ ÿ ÿ ÿ ÿ ÿ

waren jetzt meine Testeingaben.
Wenn ma aber Direkt-Echo entfernen sollt doch eigentlich nur noch 1 Zeichen kommen oder bin ich jetzt ganz doofy... :|

Traraaa !
Ich hab bei mir eine Teststellung aufgebaut und darf dir sagen, dass das Zeugs funktioniert. ich schick dir noch heute die adaptierte Source. Erläuterung folgt, zum Mäusemelken !

Cool !!! 8) \:D/
Aber an was hatts dann die ganze Zeit gelegen ??

Ich hab das eben so aufgebaut, daß ich PD2 u. PD0 (rx) verbunden habe und halt das ganze prescale u. preload f. 8 MHZ angepaßt habe. Senden hatt' ich ja schon ("hello, world") also habe ich das ganze INT0 -Zeugs eigentlich mit cut & paste aus unserem Programm übernommen. Und hatte auch bei der ersten Versuchen prompt ein ähnliches Ergebnis. Nämlich nix. d.h es schien so, als würde INT0 zwar anspringen, aber die TImer-ISR irgendwie nicht laufen (rxcount 0). Dann hab ich die ganze INT0 wieder auskommentiert und das Start-Bit in der Main-Schleife abgefragt. Und wieder war nix mit rxcount. Da ich die Timer-routine aber eigentlich nie disable, und senden ging ja immer, war das rätselhaft.
Dann stieg in mir ein Verdacht auf, und sieh, es ging auf einmal ruckartig.
und zwar hab ich rx- u. txflag zusammengelegt und die bit-names umdefiniert
TX_M_SEND 1
RX_M_RECV 4
RX_M_DATA 8
d.h mit edit replace hab ich aus bRxFlag ebenfalls bTxFlag gemacht.

ich hab zwar noch irgendwo den Fehler, daß mein echo immer zusätzlich ein zweites Zeichen ausgibt, aber das Problem find ich.

Jetzt hol ich mir nochmal dein HEX um auch dein Programm in der Richtung zu kontrollieren (wer rechnet mit sowas) also irgendwie ist das kein Beweis, daß das bei dir das gleiche Problem ist.
(die Timer-ISR kriegt den Flag RX_M_RECEIVE einfach nicht mit)

aber es ist mal eindeutig der Beweis da, daß das Programm-Konzept mit Timing, 1 u. 1.5 Bit und alles drumherum) stimmt und nur solche Idiotien der Grund für das Massaker sind.
Also die Version Sw-uart-2 von gestern paßt, nur eben die obige Änderung müßtest du mal versuchen.

Ich such mal jetzt den Grund für das doppel-Echo und versuch das ganze noch zu beweisen.

Hab die Änderungen jetzt auch vorgenommen. Bleibt so wie beim letzten Stand. Erst richtiges Echo und dann noch ein Zeichen mit. Wie sieht denn dein Doppel-Echo aus ?

Aber echt supi, das ma jetzt schon davon ausgehen können, das Timing etc. richtig ist.

Bei mir geht, scheinbar, einfach der Cursor einen schritt zu weit. So wie wenn man gesperrt schreiben würde. Wie gesagt, das erste Zeichen stimmt, dann sendet er wahrscheinlich ein (pseudo) Startbit zu viel oder sowas, also eigentlich kein wirkliches Zeichen.
Ich hab eine Terminalemulation, die würde auch binärcode darstellen, zeigt aber nix.
Das macht mir aber keine Sorgen, ich werd' das jetzt testen.

So. Ich mußte doch tatsächlich von dem 1.5 Bit umsteigen auf 0.5 Bit.
d.h. ich bin mitten im Startbit, wenn es eines ist. Erst wenn hier die Leitung auch low ist, gilt das ganze.
Eigentlich war es das. Ziemlich hartnäckiges Zeugs.
Ich habe meine Source attached, is für Winavr und Meg32 mit 8 MHZ.
Du bist so lieb, und übersetzt das selbst in deine Syntax und in deinen Quarz, mit graut aus begreiflichen Gründen schon vor allem, was mit "UA" anfängt.
Das Programm ist funktionsfähig und echoed was man schreibt

0.5 Bit --> bei dir , glaub ich (256 - 210) /2 --> 23

also TIM0_preload --> 210
INT0_preload --> 210 + 23 = 233 !!!!!

Versuch's mal und laß bitte hören.

Hi !
Funzt einwandfrei, nachdem ich nochn bischen mit dem INT0 Preload Wert rumgespielt hab !!
BIG THX FOR HELP !!! 8) \:D/
Hab selber viel gelernt dabei !

Tätarätääää !

Hört man gerne, war auch wirklich eine schwere Geburt und ein drei Meter langer Thread.
Lernen: Klar, am meisten lernt man bei dem, was NICHT geht.
also, keep codin' and let them robbies roll !