Timer0 Overflow Interrupt löst nicht aus (ATmega16)

habs jetzt so in main():

Code:

---

__task void main(void)
{
  uart_init();
       
  __enable_interrupt();  // enable interrupts

  while(1)
  {
    if(!(bTxFlag & TX_M_SEND))
    {
      send_one_byte('T');
    }

                       
    if (bRxFlag & RX_M_DATA)
    {
      bRxFlag &= ~RX_M_DATA;                // Acknowledge
      send_one_byte(bRxByte);                // Echo character
    }
//  __sleep(); // Sleep when waiting for next event


  if(!(bTxFlag & TX_M_SEND))
    {
      send_one_byte('T');
    }
  }
}

---

Sendet vor sich hin, prüft ob Zeichen empfangen, sendet wieder vor sich hin.
Kann leider kein Kreuzchen machen...
Denn er sendet nur vor sich hin, unbeeindruckt davon ob am PC eine Taste gedrückt wurde.
So als wäre INT0 plötzlich gesperrt, was es aber nicht ist (außer wenn man schon in der INT0 ISR drinne ist)[/code]

Ui, na so gut gesichert sind wir noch nicht:

Code:

---

  while(1)
  {
              if (bRxFlag & RX_M_DATA)
              {
                      bRxFlag &= ~RX_M_DATA;      // Acknowledge
                      send_one_byte(bRxByte);      // Echo character
                }
              else
                {
                        if (    !(bTxFlag & TX_M_SEND)
                        &&    !(bRxFlag & RX_M_RECEIVE)  )
                        {
                              send_one_byte('T');
                        }
                }
       
    }

---

Vergiß nicht, while läuft Bitweise mit

Jetzt siehts so aus... (siehe Bild)
die ü's sind durch willkürliches Tastendrücken entstanden.
Echo ist irgendwie falsch. 'T' wird richtig übertragen.
Könnts an dem Preload für INT0 liegen?

Würd' ich sagen. normal hast du 210 (glaub cih)
das sind also 46 bis 256
ein halber wären 23
sollten ja 187 sein, theoretisch also richtig.
praktisch hat er aber ein paar Statements auch noch zu erfüllen, bis er die Bits prüft.

könnt man versuchen, etwas raufzusetzen.

dieses y ist eigentlich 0xFD, also alles oben *think*

Setz einmal das Rxbyte bei der INT0-Routine auf NULL, ob er das Byte überhaupt angreift

Also ehrlich gsagt komm ich mit den Abschätzungen für die Preload Werte noch nicht ganz klar... So ausführlich is das garnich inner AppNote beschrieben...
z.B. über das Zustandekommen der Formel für INT0: 256-(N+N/2)+(29/C)
256 ist halt wegen 8 Bit Timer, C ist Prescaler-Wert (wie kann man das 29/C abschätzen ?) , N müsste 1/Bit sein (N*C ist die Anzahl der Cycles)

Hab in der INT0 - ISR ma das RxByte auf null gesetzt, hat sich aber nix aufs Ergebnis ausgewirkt

Hi, ich bin ein bißchen im Streß bis Sonntag.

Int-Preloads ist so:
normalerweise laden wir 210, da zählt er dann bis 256 und schnackelt.
256-210 = 46 ticks
wenn wir 1.5 Bit brauchen, wären das also 46 + 46/2 --> 69
also 256 - 69 --> 187 (?)

tja. mfg robert

Dann entsprechen also diese 46 Ticks genau einer Bitlänge.
Und diese "Ticks" bekomm man durch XTAL/Baudrate.
Jetzt hatts auch bei mir gschnackelt :P
Warum man einmal 1 Bitlänge benötigt und dann wieder 1.5 für Empfangen war mir schon klar.

Bloß hat jetzt jemand noch ne Idee, wieso Empfangen trotzdem net geht obwohl der Wert für 1.5 Bitlänge theoretisch richtig ist ??

Noch interessehalber:
Im asm-Code von der Atmel AppNote (im C-Code wurde das einfach weggelassen...) steht noch als Kommentar zu den 1.5 Bitlänge in der INT0-ISR folgendes:
29 = time delay that
have already been used in this
interrupt plus the time
that will be used by the time
delay between timer interrupt request
and the actual sampling of the first
data bit.

Wie kommen die drauf, das es ein Time Delay von 29 ist ?
Geht das durch Abschätzen der Cycles der einzelnen Instructions die während dem Programmablauf abgearbeitet werden ?
Woher weis ich dann wieviele Cycles eine Instruction braucht ?

Gruß schamp

Hi, die Atmel-Kollegen haben so richtig die Cpu-Cycles mitgezählt, während denen das Programm sozusagen blind ist. Das ist bei höheren Baudraten natürlich schon ein Faktor. Da muß man so richtig im Disassembler-Listing des C Compiler mitzählen.
Zur VErfügung stehen uns bei einem Bit
(46 Timer-Ticks) x (Vorteiler) --> Cpu Cycles
Was haben wir momentan genau XTAL / Vorteiler / Baudrate ?

Hatte jetzt immer folgende Einstellungen laufen:

// 9600 Baud @3.686MHz (STK500)
#define N 48 // Formula: N = Xtal / (BaudRate * Prescalingfactor)
#define C 8 // Prescalingfactor, NOTE: TCCR0 must also be set correct in
// timer0_init()
#define T0_TRANSMIT_PRELOAD 210 // Formula: 256-N+(14/C)
#define T0_PRELOAD 209 // Formula: 256-N+(8/C)
#define INT0_PRELOAD 188 // Formula: (256-(N+N/2)+(29/C))

Gruß schamp

Hab jetzt ein bischen an dem INT0_PRELOAD 188 "gedreht" und verschiedene Werte ausprobiert, ohne Erfolg... (die y kommen immer noch) :-k