Timer0 Overflow Interrupt löst nicht aus (ATmega16)

Na ich hoff doch, du hast PD2 und PD0 verbunden ?

RX Pin aufm Board mit PD2 sollt ja auch gehn..

klaro, INT0 (PD2) muß mithören können

Das gibsch nich.. jetzt hab ich nochmal "umgepfrimelt" von PD0 auf PD2 anstatt glei von RX auf PD2
Und INT0 springt net an...
HW Uart geht *krise* :cry:

Also RX_M_RECEIVE wird in der INT0 definitiv nicht gesetzt, habs jetzt in der HW-UART ISR abgefragt..
keine Zeichen am Terminal

Wenn INT0 anspringt, setzt er auch _M_receive, da kommt er nicht vorbei.
Vielleicht ist da auch ein Gedankenfehler drin und INT0 wird irgendwie erst NACH der Uart ausgeführt.
Setz vielleicht in der HW-UART-ISR einen anderen Flag (RX_M_MUHKUH), frag den in der Mainroutine ab und schau, ob JETZT Receive gesetzt ist

Erstma so halbe Entwarnung.. wenn ich die Status LED jetzt in der INT0 drinne hab leuchtets, also schon ma gut.

Wenn ich se stattdessen jetzt inne Receive Routine in der Timer ISR reintu leuchtets net.
Anscheinend lösch ma irgndwo ausversehen RX_M_RECEIVE... ?!

while(1)
{
if(bRxFlag & RX_M_DATA)
{

bRxFlag &= ~RX_M_DATA;
//bRxFlag &= ~RX_M_RECEIVE;
hw_transmit_byte(bRxCount + 0x30);
}
}

So auskommentiert: //bRxFlag &= ~RX_M_RECEIVE; gehts..
Counter ist immer 0 im Terminal
Das wirklich sehr komische ist... RX_M_DATA wird vorher nie gesetzt.....
Count müßte daher eigentlich auf jedenfall > 0 sein (bzw. solltns eigentlich 8 sein...) bevor in der while-Schleife hw_transmit_byte(bRxCount + 0x30);
ausgeführt wird.

wenn int0 _M_receive setzt, kann die Timer routine was tun.
wenn sie zählt, könnte sie M_data setzen und ggf. wieder INT0 enablen.
der wiederum würde den count zurücksetzen, und nur _data bliebe über

Nimm aus der Timer routine mal alles raus, außer zählen


if (bRxCount & 0x08) // is this the stop-Bit (9th)
{
bRxFlag &= ~RX_M_RECEIVE; // receiving sequence done
bRxFlag |= RX_M_DATA; // signal data
GICR |= 1<<INT0; // re-enable int0 for next

}

Alles sehr sehr komisch....
Wenn ich alles aus der Timer-ISR rausschmeiss ausser dem bRxCount
Also so:

Code:

---

#pragma vector=TIMER0_OVF_vect
__interrupt void tim0_ovf(void)
{
  TCNT0 = T0_PRELOAD;                // Refresh preload                   


// ==========================================================================
//        receive
// ==========================================================================
        if (bRxFlag & RX_M_RECEIVE)                //        receive ?
        {
                        DDRB |= (1<<PB2); // Status LED initialization
          PORTB ^= (1<<PORTB2);                // toggle status LED

/*          if (bRxCount & 0x08)                // is this the stop-Bit (9th)
          {
              bRxFlag &= ~RX_M_RECEIVE;  // receiving sequence done
              bRxFlag |= RX_M_DATA;        // signal data
              GICR |= 1<<INT0;  // re-enable int0 for next

            }
            else */
 //          {
            // bRxByte >>= 1;          // Shift right data
              bRxCount++;
              bRxFlag |= RX_M_MUHKUH;


/*            if(PIND&(1<<PD2))  //set bit or leave it
            {
              bRxByte |=0x80;                       
              bRxCount++;

            } */

//          }
        }
}

---

while-Schleife:

Code:

---

while(1)
  {
    if(bRxFlag & RX_M_MUHKUH)
    {

      //bRxFlag &= ~RX_M_DATA;
      bRxFlag &= ~RX_M_RECEIVE;
      bRxFlag &= ~RX_M_MUHKUH;
      hw_transmit_byte(bRxCount + 0x30);
    }
  }

---

wird kein INT0 ausgelöst. d.h. nur HW-Uart Echo, kein bRxCounter Stand.

Kommentiere ich aber bRxFlag &= ~RX_M_RECEIVE; und bRxFlag &= ~RX_M_MUHKUH; aus, wird INT0 ständig ausgelöst (ein Tastendruck reicht...)
Was dann gesendet wird:
!+5?IS]gq{…�™£*·ÁËÕßéóýCMWaku‰“�§±»ÅÏÙãí÷
)3=GQ[eoyƒ�—¡«µ¿ÉÓÝçñû#-7AKU_is}‡‘›¥¯¹Ã

also nur Müll halt...