Zeichenkodierungsproblem bei UART

[0xf3 (Gast)]

Hallo Mikrocontrollerfreunde,

ich versuche gerade mit meinem ATmega über UART zu sprechen. Leider 
verstehen wir uns aber noch nicht so gut. Wenn ich ein Zeichen vom PC an 
den AVR übertrage, soll es u. a. gleich wieder zurückgeschickt werden:

receivedByte = UDR0;
...
UDR0 = receivedByte:

Was ich dann aber im Terminal (screen oder minicom) sehe ist nicht das 
Zeichen, das es sein sollte, eher irgend ein Zeichensalat. Auf beiden 
Seiten liegen soweit die gleichen Einstellungen vor, also gleiche 
Baudrate, ein Stoppbit, kein Paritätsbit.

Kann vielleicht jemand nen Tipp geben, was hier noch falsch läuft bzw. 
was ich vergessen habe?

0xf3

[Peter II (Gast)]

0xf3 schrieb:
> Kann vielleicht jemand nen Tipp geben, was hier noch falsch läuft bzw.
> was ich vergessen habe?

Hast du eine Quarz dran? Wie sieht die Hardware aus? MAX232 oder ähnlich 
verwendet?

[z42 (Gast)]

Könntest du Fehlerbeschreibung und Indizien bitte noch mehr komprimieren 
und unnötiges weglassen?

[holger (Gast)]

>Was ich dann aber im Terminal (screen oder minicom) sehe ist nicht das
>Zeichen, das es sein sollte, eher irgend ein Zeichensalat. Auf beiden
>Seiten liegen soweit die gleichen Einstellungen vor, also gleiche
>Baudrate, ein Stoppbit, kein Paritätsbit.

Nö, wenn auf beiden Seiten die gleichen Einstellungen
wären, würdest du das korrekte Echo sehen.
Falsche Taktrate des uC angegeben ist der wahrscheinlichste
Grund für deinen Zeichensalat.

Wie sehen deine Fuses aus?

[Peter II (Gast)]

holger schrieb:
> Nö, wenn auf beiden Seiten die gleichen Einstellungen
> wären, würdest du das korrekte Echo sehen.

außer wenn das Signal invertiert ist, weil falsch verkabelt

[0xf3 (Gast)]

Richtig, vergessen zu erwähnen. Ein Quarz ist dran mit 3,6864 MHz. Den 
habe ich extra genommen, damit beim Prescaler für UART eine gerade Zahl 
rauskommt. Außerdem benutze ich ein Kabel mit USB-Adapter. Bin mir nicht 
ganz sicher, aber ich glaube da steckt ein FT232-Chip drin. Jedenfalls 
kann ich damit prima mit meinem Raspberry reden. Die Strippen sind so, 
wie sie meines Wissens auch sein sollen, also RX -> TX und TX -> RX.

Ansonsten:

#define F_CPU 3686400UL
#define BAUDRATE 57600UL
uint8_t myUBRR = (F_CPU / (16 * BAUDRATE)) - 1;


FUSES = -U lfuse:w:0xc8:m -U hfuse:w:0xd8:m -U efuse:w:0xff:m

[MaK (Gast)]

Welcher ATMEGA ist es denn?

Außerdem: Masse Seriell-USB-Adapter mit Masse der Schaltung verbunden?

Daten/Stoppbits + Parität richtig?

[0xf3 (Gast)]

Es ist ein ATmega328P. Die Schaltung wird ausschließlich über das 
Adapterkabel mit Strom versorgt. Bin daher ziemlich sicher, dass Masse 
und 5V an der richtigen Stelle stecken. Die sonstigen Einstellungen 
müssen auch passen, hab mir gerade nochmal die minicom-Konfiguration 
angeschaut: 8 Bit pro Zeichen, ein Stoppbit und kein Paritätsbit.

Im Controller sieht das so aus:

...
UCSR0B |= (1 << TXEN0) | (1 << RXEN0);
UCSR0C |= (1 << UCSZ01) | (1 << UCSZ00);
UBRR0H = (uint8_t) (myUBRR >> 8);
UBRR0L = (uint8_t) myUBRR;
UCSR0B |= (1 << RXCIE0);
...

[Tom (Gast)]

Ich wurde zu Beginn meiner uc-Basteleien von einem vorinstallierten 
Bootloader verarscht, der bei der UART das double-speed-Bit gesetzt hat. 
Die Symptome waren ähnlich, die Ursache zu finden hat etwas gedauert.

[0xf3 (Gast)]

>Ich wurde zu Beginn meiner uc-Basteleien von einem vorinstallierten
>Bootloader verarscht, der bei der UART das double-speed-Bit gesetzt hat.
>Die Symptome waren ähnlich, die Ursache zu finden hat etwas gedauert.

Hm, also das scheint hier wohl nicht der Fall zu sein. Habe jetzt 
explizit

UCSR0A &= ~(1 << U2X0);

gesetzt. Sieht aber alles noch genau so doof aus wie vorher.

[Wolfgang (Gast)]

0xf3 schrieb:
> FUSES = -U lfuse:w:0xc8:m -U hfuse:w:0xd8:m -U efuse:w:0xff:m

Und du bist sicher, dass ein 3,6864 MHz Quarz mit einer Frequenz im 
Bereich zwischen 0,4 und 0,9 MHz schwingt, oder warum hast du CKSEL so 
gewählt?

[MaK (Gast)]

Probier mal lfuse:w:0xdc:m oder
lfuse:w:0xd6:m (Full swing oscillator)

[0xf3 (Gast)]

>Und du bist sicher, dass ein 3,6864 MHz Quarz mit einer Frequenz im
>Bereich zwischen 0,4 und 0,9 MHz schwingt, oder warum hast du CKSEL so
>gewählt?

Oh, stimmt. Da habe ich wohl nicht beachtet, dass die Fusebits 
invertiert gesetzt werden ^^

0xdc und 0xd6 habe ich probiert. Hat aber nichts geändert. Allerdings 
sind diese beiden Werte laut Datenblatt doch für Keramikoszillatoren, 
oder?! Ich hätte glaube ich eher 0xf7 gewählt. Naja, aber das 
funktioniert genau so wenig ;)

[Irgendwer (Gast)]

0xf3 schrieb:
> Außerdem benutze ich ein Kabel mit USB-Adapter

Sicher das dies ein USB<->UART und keine USB<->RS232 Umsetzer ist?
Oder hast du auf auf der µC Seite eine UART<->RS232 Umsetzer drin?

[Andreas K. (andreasmc)]

Um zu prüfen ob der Takt richtig eingestellt ist, hat es sich bewährt 
beim Start eine LED ein paar mal im Sekundentakt blinken zu lassen...

Und anschliessend SetBaud.h verwenden statt einer eigenen Definition ;-)

[0xf3 (Gast)]

Das Kabel macht USB auf TTL. Ist doch richtig so, oder?!

Ah, Tatsache. Habe jetzt auch LEDs dran und offenbar ist der uC-Takt ein 
ganzes Stück langsamer als er sein sollte. Jedenfalls leuchten sie 
deutlich länger als vorgegeben. Hab zwar gerade keine Stoppuhr zur Hand 
aber es ist gut möglich, dass sie ca. 3,6864 mal länger leuchten ;) ich 
weiß bloß nicht wieso ^^

Hm... Also den Quarz habe ich mal ausgetauscht. Kaputt scheint er nicht 
zu sein. Er steckt zwischen XTAL1 und 2 und von jedem Pin gehen noch 22 
pF nach Masse.

Die Fusebits habe ich mir vom Calculator auf engbedded.com abgeschaut:
lfuse:w:0xc6:m  hfuse:w:0xd9:m  efuse:w:0xff:m

Ist sicher ein ganz dummer Fehler für den ich einfach nur zu blind bin. 
Hier mal die main.c:

#define F_CPU 3686400UL
#define BAUD 57600UL

#include <avr/io.h>
#include <avr/interrupt.h>
#include <util/delay.h>
#include <util/setbaud.h>

volatile char receivedByte;

void UART_init(void)  {
     UCSR0B |= (1 << TXEN0) | (1 << RXEN0);
     // enable TX and RX circuitry
     UCSR0C |= (1 << UCSZ01) | (1 << UCSZ00);
     // 8 bit character size
     UBRR0H = UBRRH_VALUE;
     UBRR0L = UBRRL_VALUE;
     // set baud rate
     UCSR0B |= (1 << RXCIE0);
     // enable RX interrupt
     UCSR0A &= ~(1 << U2X0);
     // disable double speed
}

void IO_init(void)  {
     DDRD |= (1 << PD3) | (1 << PD2);
     // PD3 and PD2 are now outputs
}

int flash_LED(uint8_t pin)  {
    // pin: 2 = yellow (PD2), 3 = green (PD3)
    if(pin != 2 && pin != 3)
  return 1;
    for(uint8_t i = 0; i <= 4; i++)  {
  _delay_ms(1000);
  PORTD ^= (1 << pin);
    }
    return 0;
}

ISR(USART_RX_vect)  {
    receivedByte = UDR0;
    flash_LED(3);
    loop_until_bit_is_set(UCSR0A, UDRE0);
    UDR0 = receivedByte;
    flash_LED(2);
}

int main(void)  {
     IO_init();
     UART_init();
     sei();
     while (1) {
  //...
     }
     return 0;
}

Und das Makefile:

DEVICE = atmega328p
CLOCK = 3686400
PROGRAMMER = -c arduino -P /dev/ttyACM0 -b 19200
OBJECTS = main.o
FUSES = -U lfuse:w:0xc6:m -U hfuse:w:0xd9:m -U efuse:w:0xff:m 

AVRDUDE = avrdude $(PROGRAMMER) -p $(DEVICE)
COMPILE = avr-gcc -Wall -Os -DF_CPU=$(CLOCK) -mmcu=$(DEVICE) -std=c99

# symbolic targets:
all:  main.hex

.c.o:
  $(COMPILE) -c $< -o $@

.S.o:
  $(COMPILE) -x assembler-with-cpp -c $< -o $@

.c.s:
  $(COMPILE) -S $< -o $@

flash:  all
  $(AVRDUDE) -U flash:w:main.hex:i

fuse:
  $(AVRDUDE) $(FUSES)

install: flash fuse

load: all
  bootloadHID main.hex

clean:
  rm -f main.hex main.elf $(OBJECTS)

# file targets:
main.elf: $(OBJECTS)
  $(COMPILE) -o main.elf $(OBJECTS)

main.hex: main.elf
  rm -f main.hex
  avr-objcopy -j .text -j .data -O ihex main.elf main.hex

disasm:  main.elf
  avr-objdump -d main.elf

cpp:
  $(COMPILE) -E main.c

[Samuel C. (neoexacun)]

Schreib die Fuses mal manuell in den AVR. Wenn die LEDs tatsächlich 3,x 
mal so lang leuchten wie sie sollten läuft der AVR wohl auf 
standardmäßigen 1MHz.

[0xf3 (Gast)]

Super, das scheint's gewesen zu sein!

#avrdude -p atmega328p -c arduino -P /dev/ttyACM0 -Ulfuse:w:0xc6:m -U hfuse:w:0xd9:m -U efuse:w:0xff:m

avrdude: stk500_getsync(): not in sync: resp=0xe0

avrdude done.  Thank you.

Jetzt passt die Taktung und auch die Zeichen kommen richtig ins Terminal 
zurück. Aber diese Meldung verstehe ich nicht. Und lesen kann ich die 
Fuses auch nicht.

#avrdude -p atmega328p -c arduino -P /dev/ttyACM0 -U lfuse:r:fuse.txt:h

avrdude: stk500_getsync(): not in sync: resp=0xe0

avrdude done.  Thank you.

Die fuse.txt wird nicht erzeugt (ja, ich habe Schreibrechte). Und warum 
klappt das anscheinend nur manuell?

Naja, immerhin bin ich schon mal ein ganzes Stück weiter. Vielen Dank 
bis dahin für die Hilfe!