ATmega1284 braucht Pause zwischen USART-Konfiguration und ersten Zeichen

[Jefe (Gast)]

Moin, ich habe eben festgestellt, dass die USART zwischen Konfiguration 
(9600-8-N-1, 8 MHz-Quarz) ein kleines bischen braucht um die 
Konfiguration abzuschließen. Erst nach dieser kleinen Pause von 
vielleicht 20 Takten, kann ich die ersten Zeichen korrekt senden. Sonst 
kommt nur Müll raus. Bzw. Mal geht es, mal nicht.

Frage: Wo steht so etwas im Datenblatt? Ich nutze zur Zeit einen 
ATmega1284P


Jefe

[Falk B. (falk)]

Das liegt wahrscheinlich an der "falschen" Reihenfolge beim Beschreiben 
der Register. Der BAUD-Genertor bekommt ein Update, wenn man UBRRnL 
schreibt. Man muss erst alles konfigurieren und am Schluss erst TXENn 
auf 1 setzen. Dann sollte es ohne Pause funktionieren.

[Ingo Less (Gast)]

Zeig mal

[Oliver S. (oliverso)]

Kannst du das mal näher erklären? Denn eigentlich sendest du gar nichts, 
du schreibst nur einen Wert ins Register. Senden macht die Uart dann 
ganz alleine, und das erst, wenn die fertig initialisiert ist.

Ich vermute eher, daß dein TX-Pin vor der Initialisierung low ist, und 
damit der Receiver auf den anderen Seite Probleme hat, daß Startbit zu 
erkennen.

Oliver

[Adam P. (adamap)]

Jefe schrieb:
> Ich nutze zur Zeit einen
> ATmega1284P

Ich nutze den sehr gerne und oft, viel Platz und 20 MHz :)

Aber ich hatte noch nie Probleme.
Ich betreibe den sogar mit 57.6K oder 250K.

Aber ich mach die Config. wie:

Falk B. schrieb:
> Man muss erst alles konfigurieren und am Schluss erst TXENn
> auf 1 setzen.

[Adam P. (adamap)]

Jefe schrieb:
> Frage: Wo steht so etwas im Datenblatt?

Zeig mal deine Init().

Dann sieht man es gleich, oder ich teste es morgen früh.

Edit:
Nebensächlich - warum wählt man einen 1284 und treibt den mit "nur" 8 
Mhz?

[Jefe (Gast)]

Adam P. schrieb:
> Edit:
> Nebensächlich - warum wählt man einen 1284 und treibt den mit "nur" 8
> Mhz?
Hatte nur ein 8 MHz Quarz übrig.


Ansonsten hat sich das Problem erledigt. Es ist wohl eher irgendetwas im 
Zusammenhang CH340  Windows 11  USB3.

Warum auch immer klappt es nun ohne Probleme.

Hier aber der Code. Vielleicht gibt es ja noch Potential ;-)

.include "m1284Pdef.inc"

.equ F_CPU    = 8000000

.equ BAUD_9600  = 9600
 
.equ UBRR_VAL_9600   = ((F_CPU+BAUD_9600*8)/(BAUD_9600*16)-1)
.equ BAUD_REAL_9600  = (F_CPU/(16*(UBRR_VAL_9600+1)))
.equ BAUD_ERROR_9600 = ((BAUD_REAL_9600*1000)/BAUD_9600-1000)
 
.if ((BAUD_ERROR_9600>10) || (BAUD_ERROR_9600<-10))
.error "Systematischer Fehler der Baudrate grösser 1 Prozent!"
.endif

.cseg
 
.org 0x0000
  ldi     r16, HIGH(RAMEND)
  out     SPH, r16
  ldi     r16, LOW(RAMEND)
  out     SPL, r16
    
  ldi     r17, HIGH(UBRR_VAL_9600)
  ldi     r18, LOW(UBRR_VAL_9600)
  sts     UBRR0H, r17
  sts     UBRR0L, r18
  ldi     r16, 0b00000110
  sts     UCSR0C, r16
  
  clr     r16
  ldi     r16, (1<<TXEN0)|(1<<RXEN0)|(1<<RXCIE0)
  sts     UCSR0B, r16
  
  ldi  r16, 6
  call  serout_raw
  call  serout_raw
  call  serout_raw

loop:
  jmp  loop


serout_raw:
  lds  r19, UCSR0A
  sbrs  r19, UDRE0
  rjmp    serout_raw
  sts  UDR0, r16
  ret

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Jefe schrieb:
> Es ist wohl eher irgendetwas im Zusammenhang CH340  Windows 11  USB3.
> Warum auch immer klappt es nun ohne Probleme.
Ein Oszilloskop würde hier in kurzer Zeit Klarheit bringen. Denn damit 
kann man genau sehen, was auf dem Bus los ist. Und wenn man parallel auf 
einem anderen Portpin noch ein Triggersignal ausgibt, dann kann man 
sogar ganz einfach messen, wie lange das Versenden dauert.

> (1<<RXCIE0)
Warum schaltest du da den Interrupt aktiv?
Zum Glück ist da nirgends ein sei(). Kann lustig werden, wenn du die 
Interrupts später mal global aktivierst, weil du z.B. einen 
Pinchange-Interrupt verwenden willst.

[Peter D. (peda)]

Nach dem Reset sind alle Pins hochohmig, d.h. der Pegel ist undefiniert. 
Wenn der nachgeschaltete IC keinen Pullup hat, kann also Mumpitz 
anliegen.

Sauber ist es daher, nach dem Reset den Pin als high oder mit Pullup zu 
setzen und in diesem Zustand für mindestens eine Bytezeit zu belassen. 
Danach ist der Empfänger garantiert für das nächste Startbit bereit.

[Jefe (Gast)]

Peter D. schrieb:
> Sauber ist es daher, nach dem Reset den Pin als high oder mit Pullup zu
> setzen und in diesem Zustand für mindestens eine Bytezeit zu belassen.
> Danach ist der Empfänger garantiert für das nächste Startbit bereit.

OK, den RX auf high. Was ist mit TX?

[Sebastian (Gast)]

Jefe schrieb:
> OK, den RX auf high. Was ist mit TX?

Ich glaube der TX-Pin war gemeint. Also vor dem ersten Senden entweder 
vor Aktivierung der UART den TX-Pin auf Output High stellen und eine 
Bytezeit warten, oder die UART aktivieren und danach noch eine Bytezeit 
warten. Andonsten kann die anscheinend der zunächst undefinierte 
TX-Pegel den Anfang der Übertragung korrumpieren.

LG, Sebastian

[Jefe (Gast)]

Sebastian schrieb:
> Ich glaube der TX-Pin war gemeint.

Ja natürlich, habe ich auch schon so umgesetzt. Meinte RX

[A. S. (Gast)]

Könnte sein, dass Du Back to Back sendest und er sich nicht auf Start 
synchronisiert.

2 stopbits beim Sender und 1 beim Empfänger sorgen meist schnell für 
Abhilfe