SerWrite, SerRead (keine Angst, Flashen funktioniert)

Hallo allerseits,

bei dem Versuch mich mit meinem Asuro unterhalten zu können bin ich auf ein
ärgerliches Problem gestossen:

Wenn ich direkt nach einem Aufruf von SerWrite() das Gegenstück SerRead()
ausführe werden immer Daten empfangen auch wenn vom PC keine neuen Daten
verschickt wurden. Verhindern kann ich den Effekt indem ich nach dem Aufruf von
SerWrite() eine Pause via wiederholtem Sleep() einbaue. Eine Zehntelsekunde
genügt schon und der Effekt tritt nicht mehr auf, d.h. ein blockierendes Lesen
von seriellen Daten blockiert dann auch wirklich.

Wie kommt es zu dem Effekt und falls wirklich eine Pause zwischen Schreiben und
Lesen nötig ist wie lang muß diese dann sein?

In dem Zusammenhang sind vielleicht auch die letzten zwei Zeilen von SerWrite()
interessant:

Code:

---

for (i = 0; i < 0xFE; i++)
        for(length = 0; length < 0xFE; length++);

---

Hier wird ja nichts anderes gemacht als einige (254*254) Zyklen zu verzögern.
Einen Kommentar dazu gibt es nicht und eine Suche hier im Forum hat auch nichts
ergeben.

Anmerkungen:
Mein Asuro ist nicht modifiziert. Ich benutze einen seriellen Port also keinen
USB-Adapter und, wie im Titel schon erwähnt, habe ich auch keine Probleme den
Bot zu flashen.

Schonmal Danke für erleuchtende Erklärungen!

Grüsse,
Florian

Hi,

der Asuro empfängt zum Teil seine eigenen vorher gesendeten Zeichen. Das läßt sich bei der Art der Übertragung mit Infrarot halt kaum vermeiden.
Man muß das beim Programmieren berücksichtigen, durch ein geeignetes Protokoll mit Checksumme, Halbduplex Mode, Delays beim Umschalten von Senden nach Empfangen usw.

Hallo,

die Warteschleiffe hatte ich mal recherchiert...

https://www.roboternetz.de/phpBB2/ze...ucsra&start=22

Noch dazu: gesendete Karakter werden zuerst im UDR register (zwei Karakter konnen da drin) plaziert und die werden nach einander in dass Schieberegister transportiert. Wenn zwei karkater im UDR sind ist die UDR voll. Wenn die controller ein karakter sendet holt er die aus dem UDR und transportiert es zum Schieberegister und fangt an es bit fur bit nach aussen zu schieben. Wenn dass karakter vom UDR nach Schieberegister transportiert ist (und noch nicht gesendet) kann schon wieder ein neues Karakter in UDR plaziert werden. (So insgesammt konnen 3 Karakter ungesendet im USART Sender anwesend sein, zwei im UDR und eins im Schieberegister)

Da kann mann wahlen wie zu handeln, denn mann kann testen/warten bis ein platz im UDR frei ist oder mann kann testen/warten bis UDR UND Schieberegister zusammen beide leer sind.

Gruss

Henk

Haha,

ja da kannst du noch mehr erzahlen aber es stimmt nicht was der Henk (ich..) geschrieben hat:

im Atmega8 pdf steht:

• Bit 3 – TXEN: Transmitter Enable
Writing this bit to one enables the USART Transmitter. The Transmitter will override normal
port operation for the TxD pin when enabled. The disabling of the Transmitter
(writing TXEN to zero) will not become effective until ongoing and pending transmissions
are completed (i.e., when the Transmit Shift Register (Schieberegister) and Transmit Buffer Register (UDR)
do not contain data to be transmitted). When disabled, the Transmitter will no longer
override the TxD port.

Ubersetztz: wenn die Sender ausgeschaltet wird mittels TXEN dann werden die im UDR und Schieberegister anwesende karakter doch noch gesended und DANACH wird die Sender vom Kontroller richtig ausgeschaltet.

So, nach ausschalten vom Sender und gleichzeitig einschalten vom Empfanger (mittels der software) werden maximal noch drei vom Sender gesendete Karakter wieder zuruck empfangen vom Empfanger.

Mann konnte unterstehende code statt am ende in SerWrite() auch am anfang im SerRead() plazieren.

//warte bis UDR und Schieberegister leer sind
while ( ! ( UCSRA | (1<<TXC) ) );
//reset handmassig den TXC bit durch schreiben einen '1' (ja eine EINS !)
UCSRA |= (1<<TXC);

Gruss nochmal,

Henk

Danke für die Antworten!

Den älteren Thread in dem es auch schon um SerWrite() ging hatte ich leider
übersehen. Ich werde noch ein wenig mit dem Asuro rumspielen und auch mal
testen ob das warten auf TXC die Situation verbessert.

Ist schon seltsam, dass da zum rücksetzten eine 1 geschrieben wird, ich
dachte schon das sei ein Fehler im Manual :)

Viele Grüsse,
Florian