Forum: Compiler & IDEs Register UCSR0C Bit 7


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Fritz T. (haderlump)


Lesenswert?

Das Bit 7 im Register UCSR0C  Bit 7 signalisiert ja dass ein Datenbyte 
im UDR vorliegt. Laut Manual wird dieses Bit 7 gelöscht, sobald das Byte 
aus dem UDR0 gelesen wird.
Hat bisher im Studio 4 auch gut geklappt.
Nun, in Studio 7 wird dieses Bit nicht immer automatisch gelöscht. Bei 
mir nach 2 Lesevorgängen.
Handelt es sich dabei um einen Debuggerfehler? Ist da etwas bekannt?

Der Befehl:
1
lds  temp4,UDR0
sollte doch das Bit7 löschen.
Wäre es sinnvoll das UDR0 2x hintereinander auszulesen?

von Oliver S. (oliverso)


Lesenswert?

Ich sag mal so: was die Simulatoren in irgendwelchen Studios machen, 
spielt eigentlich keine Rolle.

Wichtig ist, was der reale Prozessor  macht. Das steht im Datenblatt.

Oliver
P.S. UCSR0C Bit 7 tut mit an Sicherheit grenzender Wahrscheinlichkeit 
nicht das, was du beschreibst.

: Bearbeitet durch User
von Peter D. (peda)


Lesenswert?

Nun, die AVR-UART ist 2-fach gepuffert. Es kann daher gut sein, daß man 
3-mal lesen muß, bis man alle empfangenen Bytes hat.
1
void flush_rx_UART0( void )
2
{
3
  UDR0;
4
  UDR0;
5
  UDR0;
6
}

von Peter D. (peda)


Lesenswert?

Hier nochmal die Erklärung:
"The receiver Shift Register can now act as a third buffer level. This 
is done by allowing the received data to remain in the serial Shift 
Register (see Figure 69) if the Buffer Registers are full, until a new 
start bit is detected."

D.h. sind beide Puffer noch voll, wird beim 4. Startbit das 
Schieberegister gelöscht und nach dem Stopbit steht das 4. Byte im 
Schieberegister.

von Fritz T. (haderlump)


Lesenswert?

Vielen Dank für die Antworten.
Also folgendes:
Im Simulator empfange ich ja keine echten Telegramme. D.H der Puffer ist 
ja leer. Ich setze das Bit 7 im Simulator, um den Interrupt auszulösen.
Die Routine liest das Byte dann das UDR-Register in temp4. Der Inhalt 
ist natürlich 0. Zur Weiterverarbeitung ändere ich im Whatch den Wert 
von temp 4.
Das alles ist klar, und funktioniert auch. Der Puffer sollte jetzt aber 
leer sein, und das Bit 7 gelöscht werden. Ich leese jetzt beim Debugen 
das UDR nochmals in ein nicht gebrauchtes Register, und dann klappt das 
auch mit dem Reset von Bit 7.
In Echt ist durch die Interruproutine das gelesen Byte schon lange 
verarbeitet, bis das nächste Byte eintrift.

Meine Frage war ob das ein bekannter Debuger-Fehler ist.
Leben kann ich damit ganz gut.

Gruß Fritz

von Peter D. (peda)


Lesenswert?

Fritz T. schrieb:
> Ich setze das Bit 7 im Simulator, um den Interrupt auszulösen.

Dann verhält sich der Simulator anders, als der echte Chip. In echt ist 
das Bit nämlich Read-only.
Manche Simulatoren erlauben mit einer Stimulusdatei oder in einem 
Terminalfenster eine UART-Eingabe zu simulieren.

Fritz T. schrieb:
> In Echt ist durch die Interruproutine das gelesen Byte schon lange
> verarbeitet, bis das nächste Byte eintrift.

Dann dürfen aber keine anderen Interrupts oder atomare Zugriffe ihn 
blockieren. Bei höchster Baudrate sind nur 80 CPU-Zyklen schnell mal 
vorbei.

von Fritz T. (haderlump)


Lesenswert?

Die Routine bringt erst mal das, bzw. die Bytes an einen "sicheren Ort". 
Die eigentliche Auswertung erfolgt dann "stressfrei" in der 
Hauptschleife.

Ja, in Echt ist das Bit 7 tatsächlich read only.  Das Programm 
beeinflusst es auch nicht. Aber auch die anderen Register sind im 
Simulator ja manipulierbar.

Bei einer Baudrate von 19200 braucht ein Byte ca 500 uS, macht dann bei 
20 MHz ca. 10000 CPU Takte. Also genügend Reserve.
Insgesamt mischen die Timer mit (erzeugen langsame Impulse), Die meiste 
Zeit langweilt sich das Programm aber in der Hauptschleife.

Gruß Fritz

von Gregor J. (Firma: Jasinski) (gregor_jasinski)


Angehängte Dateien:

Lesenswert?

Wenn im Topic die UART von ATMEGAs gemeint ist, dann liegt hier 
möglicherweise eine Verwechslung vor, denn das besagte Bit 7, das 
Datenempfang signalisiert, befindet sich im UCSRxA-Register. Im UCSRxC 
ist etwas anderes – die Titelzeile wäre demnach dann auch irreführend. 
Der dritte Screenshot beinhaltet die Erklärung und Beispiele (in C und 
Assembler), wie man den Empfangsbuffer leeren kann, aber das nur so 
nebenbei.

: Bearbeitet durch User
von Oliver S. (oliverso)


Lesenswert?

Gregor J. schrieb:
> Der dritte Screenshot beinhaltet die Erklärung und Beispiele (in C und
> Assembler), wie man den Empfangsbuffer leeren kann, aber das nur so
> nebenbei.

Ja, aber wer liest schon Datenblätter? Das ist doch oldschool...

Oliver

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.