Druckbare Version
Hab jetzt mal weiter programmiert...
ext. INT0 Initialisierung und sonstige Inits sollten eigentlich stimmen.
in main() will ich jetzt einfach ein character echo ausführen.
In der Receive-Routine (zu finden in der Timer0 ISR) hab ich aber noch ein Problem. Wie kann ich die Bits, die über die RX Leitung kommn und ext. Int0 auslösen zur Weiterverarbeitung einlesen/puffern ?? Steh grad auffer Leitung.. :shock:
Schau'n wir gleich rein.
Übrigens, meinen Pegel hab ich auch gefunden, Blödheit tut gottseidank nicht weh ( DDRD = Bit <> DDRC |= Bit).
Nja so einfach gehts irgndwie doch nicht mit Empfangen... 8-[
Einlesen funzt über PINx (nicht PORTx) soweit ich das jetzt feststellen konnte.
Bloß wie feststellen, welches empfangene Bit jetzt Datenbit, Start - bzw. Stopbit ?? Müsste man wieder mit "State" wie bei Senden machen oder ??
Aber müßte man das nicht auch gleich inner INT0 Routine auswerten, anstatt inner Timer0 ISR ??? (wär doch logisch, da mir sonst bits verloren gehen.. :-s)
Is mir gestern abend noch so durchn Kopf gegangen
Gruß schamp
Hi, ich grad in deinem Programm rumgekrixelt.
Die Int0-ISR zeigt, daß der Absender gerade mit dem Start-Bit anfängt.
Um mit der nächsten Time-ISR genau in die Mitte vom ersten Datenbit zu kommen, brauchen wir also einen Preload von 1.5 Bit. ab dann gehts wieder normal, auch das Stop Bit nehmen wir mit, aber dann re-enablen wir Int0 und setzen "daten da"
schau mal
Sicherheitstest: Beim INT0 alles in Ruhe lassen, nur ein Flag setzen, und in der Mainroutine aufgrund des Flags irgendwas senden.
Dadurch wissen wir, daß int0 überhaupt funktioniert
irgdnwie ist da was wahres dran *tehe* O:)Zitat:
Zitat von PicNick
habs ma compiliert, raufgeladen und tera term angeschmissn. Also empfangen tut er (int0 wird ausgelöst) aber Zeichen stimmt noch net. Egal welche Taste man drückt es kommen immer zwei: ÿÿ
Ev. In der INT0-ISR nur aktiv werden, wenn RX_M_RECEIVE NICHT gesetzt ist.
Aber in der INT0-ISR musst du doch RX_M_RECEIVE setzen sonst gehts im "Receive-Teil" vonner Timer0-ISR nicht weiter... :-sZitat:
Zitat von PicNick
Ja, ja. Aber aber vorher fragen, ob der Flag nicht schon vorher gesetzt wurde.
Weil dann läuft ja schon die Empfangs-Sequenz, und während der nächsten 9 Timer-Interrupts wollen wir ja nix mehr sehen oder hören.
du meinst so ?
edit: funkt trotzdem noch nichtCode:#pragma vector=INT0_vect
__interrupt void ext_int0(void)
{
if(!(bRxFlag & RX_M_RECEIVE))
{
GICR = 0; // Disable external interrupt
bTxFlag &= ~TX_M_SEND; // Deactivate Transmit-Mode
bRxCount = 0; // Clear Receive Counter
TIFR |= (1<<TOV0); // clear T/C0 overflow flag
TIMSK |= (1<<TOIE0); // enable T/C0 overflow interrupt
TCNT0 = INT0_PRELOAD; // Set timer reload-value (to 1.5 bit len). 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.
bRxFlag |= RX_M_RECEIVE; // Activate Receive-Mode
}
}
Ja, so mein' ich das. Ist auf jeden Fall gut, und würde das enablen/disablen des INT0 erübrigen, aber das klappt ja ohnehin ?
*murmel*
Dzt.Stand: Int0 spricht an, Timer offenbar auch,_M _DATA wird ja irgendwann gesetzt, aber es kommt auf ein Input-Zeichen üü irgendwas an. Stimmt das so ?
d.h. es kann beides fehlerhaft sein, Empfang & Senden, das ist nix
Also:
Sende irgendwas vor dich hin, bis _DATA kommt (+ECHO), und dann sende wieder irgendwas, so wie vorher
Ergebnis:
A Senden geht überhaupt nicht mehr ---> ?
B Senden geht, aber ab dem Moment, wenn daten kommen, geht's nicht mehr
C Nur das Echo ist falsch
Bitte machen sie ihr Kreuzchen
habs jetzt so in main():
Sendet vor sich hin, prüft ob Zeichen empfangen, sendet wieder vor sich hin.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');
}
}
}
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:
Vergiß nicht, while läuft Bitweise mitCode: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');
}
}
}
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
Hi, was mich etwas verwundert, ist, daß immer genau das Gleiche daherkommt. Bei Timingfehlern würde man zwar Mist erwarten, aber differenzierten Mist.
Wenn du zb "blank" (0x20) schickst, ist grad mal 1 Bit gesetzt, der Rest null. da sollt' er doch mehr nuller erwischen.
Ob 8/C oder 29/C, da gehts doch nur um Zahlen von 1-4
Geh, nur um das dann vergessen zu können: dreh dich mal den Int0 von falling auf rising.
bringt auch nix.... :(
(INT0 auf rising)
Momemt, moment: bringt er genau das Gleiche ? (türkisches Ypsilon ?)
jo... das ist eben des komische...
seid neuestem auch ma nen Balken, mehrere y hintereinander oder Fragezeichen (wenn man auf der Taste bleibt).
(EDIT: nja nur y's, wenn man das Senden abschält und nur auf Zeicheneingabe wartet)
siehe Bild -->
Da gibt's nur eine Erklärung: da alle Müllzeichen offenbar > 128 sind und das Msb ja am Ende kommt, sind wir zu langsam.
Er nimmt den Pegel NACH dem Stop-Bit als Daten und kriegt da immer Einser, außer bei autorepeat, da kommt dann halt schon das nächste Byte.
Also irgendwie bringt der INT0 den Timer0 nicht rechtzeitig in Schwung.
Tscha, *grübel*
Aber dann würd ma trotzdem nicht immer die selbe "Kombination" bzw. Bitfolge bekommen (türk. y is 0x9fh, 10011111b).
Oder versteh ich dich jetzt irgendwie falsch ? :-s
Na gemeint ist, daß er das ganze Byte eigentlich versäumt und erst dann zum Lesen kommt, wenn der Pegel nach dem Stop-Bit schon wieder oben ist.
Wenn er irgendwas von dem Byte wirklich lesen täte, könnt's nicht immer das gleiche sein.
Probier' mal folgendes:
Laß den Timer0 immer enabled, tu' aber beim INT0 (falling) nur das Bit RX_M_RECEIVE setzen.
Hm Timer0 ist eigentlich immer enabled ? (uart_init())
Hab jetzt nur
// bTxFlag &= ~TX_M_SEND; // Deactivate Transmit-Mode
und
// TIFR |= (1<<TOV0); // clear T/C0 overflow flag
// TIMSK |= (1<<TOIE0); // enable T/C0 overflow interrupt
auskommentiert
Es wird nur das RX_M_RECEIVE gesetzt. Die y kommen immer noch...
Code:#pragma vector=INT0_vect
__interrupt void ext_int0(void)
{
if(!(bRxFlag & RX_M_RECEIVE))
{
GICR = 0; // Disable external interrupt
// bTxFlag &= ~TX_M_SEND; // Deactivate Transmit-Mode
TCNT0 = INT0_PRELOAD; // Set timer reload-value (to 1.5 bit len). 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.
// TIFR |= (1<<TOV0); // clear T/C0 overflow flag
// TIMSK |= (1<<TOIE0); // enable T/C0 overflow interrupt
bRxCount = 0; // Clear Receive Counter
bRxFlag |= RX_M_RECEIVE; // Activate Receive-Mode
}
}
Morgen !
Ich denke, wir bellen irgendwie den falschen Baum an.
Wenn in der Timer-ISR zwar mit Baudrate, aber ansonsten willenlos der Rx-Pin abgefragt wird, kann nicht immer der gleiche Schrott rauskommen.
Zeit, den Kopf schief zu halten, damit das Hirn in einer Ecke zusammenläuft und man besser denken kann.
Da das Senden, so scheint's, ja funktioniert, könnten wir und auf das reine Echo beschränken, dann läuft der Schirm nicht immer voll.
Back to the roots: kommentiere das Echo senden mal aus.
1 In der Hauptschleife ignoriere alles, und kopiere einfach IMMER den RX -Pin in den TX-Pin (ohne timing, ohne Nix). Dann sollten wir doch ein tadelloses Echo senden können. DAS MUSS GEHEN
2 mach das gleiche, aber nur, während RX_M_RECEIVE gesetzt ist, dadurch kontrollieren wir unser Frame
zu 1
Du meinst inner Hauptschleife nur so:
while(1)
{
if (bRxFlag & RX_M_DATA)
{
bRxFlag &= ~RX_M_DATA; // Acknowledge
send_one_byte(bRxByte); // Echo character
}
}
Nein, ich mein
while(forever)
if (pinx.Rx) portx.Tx = 1; else portx.Tx = 0;
ganz brutal.
Und dann
while(forever)
if (bTxFlag & RX_M_REVEICE)
if (pinx.Rx) portx.Tx = 1; else portx.Tx = 0;
( RX_M_Receive wird ja vom int0 gesetzt und im Timer nach 9 Bit gelöscht, also theoretisch genau ein Byte lang )
--M_DATA is mal wurst
Echo mag jetzt, wenn ma's echt so brutal macht :D
while(1)
{
// if (PD2.Rx) PORTD4.Tx = 1; else PORTD4.Tx = 0;
if(PIND&(1<<PD2))
{
PORTD |=(1<<PD4);
}
else
{
PORTD &= ~(1<<PD4);
}
}
Jetzt probier ich gleich mit RX_M_RECEIVE
(muss das nich if(bRxFlag & RX_M_RECEIVE) sein ??)
if(bRxFlag & RX_M_RECEIVE)
{
if(PIND&(1<<PD2))
{
PORTD |=(1<<PD4);
}
else
{
PORTD &= ~(1<<PD4);
}
}
}
Geht auch... also wird sozusagen Frame eingehalten...
Irgendwo wird zuviel Zeit verbraten ?? :-s
Also in der INT0 - ISR hab ich Timer0 auch weggelassen
Ah ja.
Jetzt machen wir INT0 wieder scharf wie vorgesehen
d.h (fast) alles wir vorher, nur das eigentliche Pind.2 -> Byte lesen in der Timer-ISR lassen wir mal weg, das Echo bleibt in der while-schleife
sollt ja gehen
Next: In der echo-kopie im while setzen wir nicht nur das tx-Pin, sondern auch das bRxByte.7 (das MSB). rotieren lassen wir aber die Timer-iSR
Und dann schicken wir in der while schleife das nun entstandene Byte auch mit der sende-routine weg
haben wir jetzt ein echo o.k und wieder ein türk y ?
(war das verständlich ? )
Hm Step 1 ok. Einfach inner Timer-ISR auskommentieren. Funkioniert auch.
Aber das mit 7. Bit setzen (bRxByte |=0x80;) inner while-Schleife, versteh ich grad net so ganz.. also was es bringt...
Jetzt ists ja so, das alles was an Bits bei PD2 ankommt gleich wieder an PORTD4 rausgschickt wird.
EDIT: Meinst du den ganzen Receive-Block von der Timer-ISR in die while-Schleife ziehen ?
der Gedanke ist:
Wir können die Bits in der while schleife offenbar richtig erkennen
wir brauchen diese Bits aber im rxbyte an der RICHTIGEN Stelle.
in der while schleife setzten wir das 7 Bit, und der Timer rotiert das Bit nach rechts, wenn baudratenmäßig das nächste dran ist.
Das wird zwar nicht stimmen, sonst hätten wir ja kein Problem, aber vielleicht können wir durch Vergleich Bit-Kopie-Echo und timermäßiges Byte-Echo das Problem einkreisen.
Receive-Block inner Timer-ISR:
while-Schleife:Code:if (bRxFlag & RX_M_RECEIVE) // receive ?
{
if (bRxCount == 9) // 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
/* if(PIND&(1<<PD2)) set bit or leave it
{
bRxByte |=0x80;
bRxCount++;
} */
Code:while(1)
{
if(bRxFlag & RX_M_RECEIVE)
{
if(PIND&(1<<PD2))
{
PORTD |=(1<<PD4);
bRxByte |=0x80;
bRxCount++;
}
else
{
PORTD &= ~(1<<PD4);
}
}
}
Alles perfekt, aber das rxCount++ bleibt in der ISR
Ok, Echo funktioniert immer noch einwandfrei.
Probier jetzt die send_one_byte() aus
Gut, aber was steht jetzt im bRxByte ?
(zusätzlich in der while)
if (bRxFlag & RX_M_DATA)
{
bRxFlag &= ~RX_M_DATA;
_send (bRxByte);
}
Wie fast erwartet...
Bit-Kopie Echo passt mit send_byte wieder y