Atmega Uart - Falsche Byte Übertragung

[AtmegaNoob (Gast)]

Hi!

Folgender Aufbau habe ich:

Auf einem Atmel Evalution Board habe ich einen Atmega32.
Über Uart sende ich Daten vom Atmega zum PC. (Nicht Angeschlossen 
sondern über den AZ-Delivery FT232-AZ USB zu TTL Serial Adapter für 3,3V 
und 5V).
Leider bekomme ich auf dem PC (HTerm) falsche Bytes.

Die ersten beiden Bytes sind ok und dann wird die zweite Byte 5 Mal 
widerholt.
Auch zeigt hTerm sporadisch an, dass es Fehler in der Übertragung für 
manche Bytes gibt. Baudrate, Byte und Stoo Bit sind gleich angezeigt.

#include <avr/io.h>
#include <stdio.h>
//#define F_CPU 3686400UL
#define F_CPU 16000000UL
#include <util/delay.h>
#define Baud 38400
//#define CR "\0\r\n"


void uart_init(void)
{
  UCSRB = (1 << TXEN);
  UCSRC = (1 << URSEL) | (1 << UCSZ1) | (1 << UCSZ0);
  UBRRL=0x05; // Baudrate festlegen
  UBRRH=0x00; // Baudrate festlegen
}

int uart_send(unsigned char c)
{
  while (!(UCSRA & (1<<UDRE)))
  {
    // mach nichts
  }
  //senden
  UDR=c;
  return 0;
}


void uart_write(char *s)
{
  while(*s)
  {
    uart_send(*s);
    s++;
  }
}

int main(void)
{
  uart_init();
  while(1==1)
  {
    //uart_write("Das ist ein Test" CR);
    uart_write("Das ist ein Test\r\n");
    _delay_ms(1000);
  }
}

Mal zum Testen in Assembler probiert:

;
; Laboraufgabe 4 - (UART).asm
;

.include "m32def.inc"

.def temp = r16    ; Register für kleine Arbeiten
.def zeichen = r17  ; in diesem Register wird das Zeichen an die Ausgabefunktion übergeben

.equ F_CPU = 16000000  ; Systemtakt in Hz
.equ BAUD = 9600    ; Baudrate

; Berechnungen
.equ UBRR_VAL = ((F_CPU+BAUD*8)/(BAUD*16)-1)  ; clever runden
.equ BAUD_REAL = (F_CPU/(16*(UBRR_VAL)+1))    ; Reale Baudrate
.equ BAUD_ERROR = ((BAUD_REAL*1000)/BAUD-1000)  ; Fehler in Promile

.if((BAUD_ERROR>10) || (BAUD_ERROR<-10))  ; max +/- 10 Promile Fehler
  .error "Systematischer Fehler der Baudrate grösser 1 Prozent und damit zu hoch!"
.endif

; Stackpointer initialisieren

  ldi  temp,  HIGH(RAMEND)
  out SPH,  temp
  ldi  temp,  LOW(RAMEND)
  out  SPL,  temp

; Baudrate einstellen
  ldi  temp,  HIGH(UBRR_VAL)
  out UBRRH,  temp  
  ldi  temp,  LOW(UBRR_VAL)    
  out  SPL,  temp
; Frame-Format 8 Bit
  ldi  temp,  (1<<URSEL)|(1<<USBS)|(3<<UCSZ0)
  out UCSRC,  temp
  sbi UCSRB,  TXEN  ; TX aktivieren
  ldi  r16,  (1<<URSEL)|(1<<USBS)|(3<<UCSZ0)
  out  UCSRC,  r16
loop:
  ldi  zeichen,  0b00000001
  rcall  serout    ; Unterprogramm aufrufen
  ldi  zeichen,  0b00000010
  rcall  serout    ; Unterprogramm aufrufen
  ldi  zeichen,  0b00000011
  rcall  serout    ; Unterprogramm aufrufen
  ldi  zeichen,  0b00000100
  rcall  serout    ; Unterprogramm aufrufen
  ldi  zeichen,  0b00000101
  rcall  serout    ; Unterprogramm aufrufen
  ldi  zeichen,  0b00000110
  rcall  serout    ; Unterprogramm aufrufen
  ldi  zeichen,  0b00000111
  rcall  serout    ; Unterprogramm aufrufen
  ldi  zeichen,  0b00001000
  rcall  serout    ; Unterprogramm aufrufen
  

  rcall  serout
  rcall  sync
  rjmp  loop

serout:
  sbis  UCSRA,  UDRE  ; Warten bis UDR für das nächste Byte bereit ist
  rjmp  serout
  out  UDR,  zeichen  
  ret            ; zurücl zum Hauptprogramm

; kleine Pause zum Synchronisieren des Empfängers, falls zwischenzeitlich
; das Kabel getrennt wurde

sync:
  ldi  r16,  0
sync_1:
  ldi  r17,  0
sync_loop:
  dec  r17
  brne  sync_loop
  dec  r16
  brne  sync_1
  ret

; Replace with your application code

Danke im Voraus!

[Jan V. (janv)]

AtmegaNoob schrieb:
> Baudrate, Byte und Stoo Bit sind gleich angezeigt.

Und die Parität?

[M. K. (sylaina)]

AtmegaNoob schrieb:
> void uart_init(void)
> 11{
> 12  UCSRB = (1 << TXEN);
> 13  UCSRC = (1 << URSEL) | (1 << UCSZ1) | (1 << UCSZ0);
> 14  UBRRL=0x05; // Baudrate festlegen
> 15  UBRRH=0x00; // Baudrate festlegen
> 16}

Ein Blick in die Baudraten-Tabelle im Datenblatt bei 16 MHz verrät mir, 
dass UBRR = 5 zu keiner typischen Baudrate passt, unabhängig davon wie 
U2Xn gesetzt wurde. Für die auskommentierten 3.6864 MHz und passt UBBR = 
5 bei U2Xn = 0 für die angegebenen 38k4. Fazit: Für das Eval-Board (das 
wahrscheinlich mit 16 MHz laufen wird) wird der Baudratenfehler 
schlichtweg zu groß sein.

[Wolfgang (Gast)]

AtmegaNoob schrieb:
> Die ersten beiden Bytes sind ok und dann wird die zweite Byte 5 Mal
> widerholt.

Das ist ja widerlich.
Hast du dir das Signal und das genaue Timing vom TX des ATmega mit Oszi 
oder LA genau angesehen?

[AtmegaNoob (Gast)]

Wolfgang schrieb:
> AtmegaNoob schrieb:
>> Die ersten beiden Bytes sind ok und dann wird die zweite Byte 5 Mal
>> widerholt.
>
> Das ist ja widerlich.
> Hast du dir das Signal und das genaue Timing vom TX des ATmega mit Oszi
> oder LA genau angesehen?


Also ich habe kein Oszi zu Hause.
Also beim C Code hsne ich bei hTerm eine Baudrate von 38400 angegeben.
Beim Assembler Code dem entsprechend 9600.

[AtmegaNoob (Gast)]

M. K. schrieb:
> AtmegaNoob schrieb:
>> void uart_init(void)
>> 11{
>> 12  UCSRB = (1 << TXEN);
>> 13  UCSRC = (1 << URSEL) | (1 << UCSZ1) | (1 << UCSZ0);
>> 14  UBRRL=0x05; // Baudrate festlegen
>> 15  UBRRH=0x00; // Baudrate festlegen
>> 16}
>
> Ein Blick in die Baudraten-Tabelle im Datenblatt bei 16 MHz verrät mir,
> dass UBRR = 5 zu keiner typischen Baudrate passt, unabhängig davon wie
> U2Xn gesetzt wurde. Für die auskommentierten 3.6864 MHz und passt UBBR =
> 5 bei U2Xn = 0 für die angegebenen 38k4. Fazit: Für das Eval-Board (das
> wahrscheinlich mit 16 MHz laufen wird) wird der Baudratenfehler
> schlichtweg zu groß sein.


Danke für den Hinweis.
Also auf dem Board ist ein 16 Mhz Verbaut.

Werde ich korrigieren und testen  wenn ich wieder zu Hause bin.

[Georg G. (df2au)]

AtmegaNoob schrieb:
> //#define CR "\0\r\n"

Auch, wenn es auskommentiert ist: Bitte denk über diese Zeile noch 
einmal intensiv nach. Die NULL am Ende des Strings setzt der Compiler 
automatisch. Am Anfang des Strings bewirkt sie ein vorzeitiges Ende.

[S. Landolt (Gast)]

> Mal zum Testen in Assembler probiert

Und läuft das oder nicht?
Für die direkte UBRR-Zuweisung siehe Anhang.

[S. Landolt (Gast)]

>> Mal zum Testen in Assembler probiert
> Und läuft das oder nicht?

Nein, natürlich nicht: das zweite 'out SPL, temp' (in Zeile 33) muss 
'out UBRRL,temp' heißen.

[AtmegaNoob (Gast)]

S. Landolt schrieb:
>>> Mal zum Testen in Assembler probiert
>> Und läuft das oder nicht?
>
> Nein, natürlich nicht: das zweite 'out SPL, temp' (in Zeile 33) muss
> 'out UBRRL,temp' heißen.

Vielen Dank.


Mit folgendem (korrigiertem) Code erhalte ich nur lauter "0" angezeigt.
(Config in hterm: 8 Data, 2 Stop, 9600 Baud)

;
; Laboraufgabe 4 - (UART).asm
;

.include "m32def.inc"

.def temp = r16    ; Register für kleine Arbeiten
.def zeichen = r17  ; in diesem Register wird das Zeichen an die Ausgabefunktion übergeben

.equ F_CPU = 16000000  ; Systemtakt in Hz
.equ BAUD = 9600    ; Baudrate

; Berechnungen
.equ UBRR_VAL = ((F_CPU+BAUD*8)/(BAUD*16)-1)  ; clever runden
.equ BAUD_REAL = (F_CPU/(16*(UBRR_VAL)+1))    ; Reale Baudrate
.equ BAUD_ERROR = ((BAUD_REAL*1000)/BAUD-1000)  ; Fehler in Promile

.if((BAUD_ERROR>10) || (BAUD_ERROR<-10))  ; max +/- 10 Promile Fehler
  .error "Systematischer Fehler der Baudrate grösser 1 Prozent und damit zu hoch!"
.endif

; Stackpointer initialisieren

  ldi  temp,  HIGH(RAMEND)
  out SPH,  temp
  ldi  temp,  LOW(RAMEND)
  out  SPL,  temp

; Baudrate einstellen

  ldi  temp,  HIGH(UBRR_VAL)
  out UBRRH,  temp  
  ldi  temp,  LOW(UBRR_VAL)    
  out  UBRRL,  temp

; Frame-Format 8 Bit

  ldi  temp,  (1<<URSEL)|(1<<USBS)|(3<<UCSZ0)
  out UCSRC,  temp

  sbi UCSRB,  TXEN  ; TX aktivieren

; aus doc2503.pdf Seite 146
; 
; USART_Init:
; Set baud rate
; outUBRRH,  r17
; outUBRRL,  r16
; Enable receiver and transmitter
; ldi r16,  (1<<RXEN)|(1<<TXEN)
; out UCSRB,  r16
; Set frame format: 8data, 2stop bit
; ldi r16,  (1<<URSEL)|(1<<USBS)|(3<<UCSZ0)
; outUCSRC,  r16
; ret

  ldi  r16,  (1<<URSEL)|(1<<USBS)|(3<<UCSZ0)
  out  UCSRC,  r16
; ret

loop:

  ldi  zeichen,  'T'
  rcall  serout    ; Unterprogramm aufrufen
  ldi  zeichen,  'e'
  rcall  serout    ; Unterprogramm aufrufen
  ldi  zeichen,  's'
  rcall  serout    ; Unterprogramm aufrufen
  ldi  zeichen,  't'
  rcall  serout    ; Unterprogramm aufrufen
  ldi  zeichen,  '!'
  rcall  serout    ; Unterprogramm aufrufen
  ldi  zeichen,  10
  rcall  serout    ; Unterprogramm aufrufen
  ldi  zeichen,  13
  rcall  serout    ; Unterprogramm aufrufen

  rcall  serout
  rcall  sync
  rjmp  loop

serout:
  sbis  UCSRA,  UDRE  ; Warten bis UDR für das nächste Byte bereit ist
  rjmp  serout
  out  UDR,  zeichen  
  ret            ; zurücl zum Hauptprogramm

sync:
  ldi  r16,  0
sync_1:
  ldi  r17,  0
sync_loop:
  dec  r17
  brne  sync_loop
  dec  r16
  brne  sync_1
  ret

[S. Landolt (Gast)]

> erhalte ich nur lauter "0" angezeigt

Tja - bei mir hier läuft "Test!" den Monitor hinunter; (der 
Zwillingsbruder) ATmega16 mit direkter Verbindung zum PC.

[AtmegaNoob (Gast)]

Damke für die schnelle Antwort!



Liegt es vllt an (meiner) Verbindung vom Board (/Atmega) über den 
Adapter zum PC ? (Adapter->Board: GND->Pin 39, 5V ->Pin 40, TX/RX->Pin 
26/27)

Irdendwie kommt es mir gerade so vor, dass ich für das Offensichtliche 
zu blind bin duck und weg

Danke

[AtmegaNoob (Gast)]

-no Text-

[S. Landolt (Gast)]

Zu Ihrer speziellen PC-Anbindung kann ich leider nichts sagen - ich habe 
nur besagte direkte sowie zwei andere per USB.

[S. Landolt (Gast)]

? - Das um 19:14 gezeigte ist das alte HEX-File, das mit dem zweiten 
'out SPL, temp' statt des 'out UBRRL,temp'.

[S. Landolt (Gast)]

Korrektur: das muss ein Zwischenstand sein, es entspricht meinem neuen 
File, mit Ausnahme dieser einen beschriebenen Zeile (und natürlich dem 
RAMEND (da ATmega16)).

[S. Landolt (Gast)]

Kehren wir das Vorgehen um - hier mein HEX-File, das muss bei Ihnen ohne 
Änderung laufen.

[Wolfgang (Gast)]

AtmegaNoob schrieb:
> Liegt es vllt an (meiner) Verbindung vom Board (/Atmega) über den
> Adapter zum PC ?

Nimm einen Logik Analysator oder ein Oszilloskop und guck dir an, was 
dein ATmega rausgibt.
Dann ist der Adapter und die PC-Software raus - zwei Baustelle weniger.

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

AtmegaNoob schrieb:
> Also ich habe kein Oszi zu Hause.
Beschaff dir eines. Denn nur mit einem Oszilloskop kannst du die 
Qualität des Signals bezüglich Pegel, Flankensteilheit, Überschwinger, 
Timing und Ströungen beurteilen. Wenn das alles passt, dann kann man 
im Protokoll weitersuchen.

Es ist mir ein völliges Rätsel, wie man serielle Busse ohne Oszilloskop 
anständig zum Laufen bekommen will.

AtmegaNoob schrieb:
> Auf einem Atmel Evalution Board
Welches "Board" von den vielen, die es gibt? Und wie ist das versorgt?

[M. K. (sylaina)]

Lothar M. schrieb:
> Es ist mir ein völliges Rätsel, wie man serielle Busse ohne Oszilloskop
> anständig zum Laufen bekommen will.

Wie hat man es uns bei der BW beigebracht? Nur ein nicht abgegebener 
Schuss kann nicht treffen...ich glaube der ein und andere hat dieses 
Prinzip verinnerlicht und adaptiert es auf alles, was ihm zwischen die 
Finger kommt. Ich verstehe auch nicht, wie man ohne Oszi bei sowas 
wirklich effektiv weiter kommen will. In meinen Augen ist das zum Teil 
viel Stochern im Nebel in der Hoffnung mal nen Treffer zu landen.

[mitlesa (Gast)]

Lothar M. schrieb:
> Welches "Board" von den vielen, die es gibt? Und wie ist das versorgt?

Das frage ich mich schon lange Zeit, und hinzu kommt die Aussage

AtmegaNoob schrieb:
> Adapter->Board: GND->Pin 39, 5V ->Pin 40, TX/RX->Pin 26/27

die zu "bezweifeln" ist. Ist denn Pin 39 ein echter bzw.
zulässiger Ground-Anschluss?

Wenn wir den TO dann endlich dazu bewegt haben ein Oszilloskop
zu kaufen oder wenigstens auszuleihen kommt dann eventell noch
die Aussage "ich habe alles mit dem Logikanalysator überprüft".
Nein, es muss ein Oszilloskop sein um den Spannungsverlauf
erkennen zu können.

[mitlesa (Gast)]

Dann gibt es noch Zweifel ob es hier mit rechten Dingen zugeht:

AtmegaNoob schrieb:
> Adapter->Board: ........., 5V ->Pin 40, ........

Der VCC-Pin des FT232-Moduls hat - duch Jumper wählbar - entweder
3.3 oder 5V zu bieten. Das ist ein Ausgang, eine kleine
Quelle mit der man externe Controller versorgen kann. Werden
diese 5V an eine andere 5V-Quelle angeschlossen kommt es zu
einem Kampf der Giganten mit unvorhersehbaren Ausgang.

Merke: Ein FT232-Modul braucht keine Versorgung von aussen,
daher kann / sollte man den Vcc-Pin unbeschaltet lassen. Und
ein wie auch immer geartetes Eval-Board wird auch seine eigene
Versorgung mitbringen, einer von beiden Versorgern wird
zumindest irritiert reagieren können.

[S. Landolt (Gast)]

Was auch immer an der Hardware fehlerhaft sein mag oder nicht - mit dem 
gestern abend gezeigten HEX-File läuft die UART mit 1.0 MBd, das kann 
nichts werden.

[Magnus M. (magnetus)]

AtmegaNoob schrieb:
https://www.mikrocontroller.net/attachment/584886/fehler.png
> Mit folgendem (korrigiertem) Code erhalte ich nur lauter "0" angezeigt.
> (Config in hterm: 8 Data, 2 Stop, 9600 Baud)

Warum hast du in HTerm die Parität auf "EVEN" anstatt "NONE" gestellt?