Timer0 Overflow Interrupt löst nicht aus (ATmega16)

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