Uart empfängt immer das selbe

[Loris I. (loris1123)]

Hallo zusammen,

aktuell arbeite ich für die Hochschule an einem kleinen Projekt mit 
Microcontrollern.
Ich habe hierzu einen Arduino Uno mit ATmega328p, programmiere aber 
nicht über das Arduino Framework sondern in reinem C mit avr-gcc.

Mein Ziel ist es, Daten (Texte) per Kabel an von einem RaspberryPi an 
den Arduino zu senden und diese dort zu verarbeiten. Zum Testen möchte 
ich das empfangene Byte einfach auf 8 LEDs darstellen.

Ich habe also den Ground des Raspis und des Arduino verbunden und 
außerdem TX des Raspi mit RX des Arduino.

Wenn ich nun im Raspi einen Minicom öffne und Tasten drücke, gehen zwar 
LEDs an, jedoch sind es bei fast allen Buchstaben alle LEDs, bis auf die 
letzte. (1111110) Nur bei einigen Buchstaben, zum Beispiel h,j ,k l, 
gehen 2 LEDs aus. Dann wird immer 10011110 ausgegeben.

Wenn ich das ganze über das Arduino Framework mache, funktioniert es 
wunderbar und ich kann auf unterschiedliche Buchstaben reagieren.
Mein Fehler wird also vermutlich in der Initialisierung des UART oder 
der Verarbeitung liegen. Meinen Fehler finde ich jedoch nicht. Ich habe 
ihn mit vielen Beispielcodes, unter anderem aus diesem Forum, 
verglichen.

Ich hoffe, dass ihr mir helfen könnt :)

Viele Grüße
Loris,

Hier noch mein Quellcode:

#include <avr/io.h>
#include <avr/interrupt.h>

// Calculate Baudrate
#define BAUDRATE 9600
#define BAUD_PRESCALE (((F_CPU / (BAUDRATE * 16UL))) - 1)

void USART_init(void){
    // Set baud
    UBRR0H  = (BAUD_PRESCALE >> 8);
    UBRR0L  = BAUD_PRESCALE;

    // Enable UART Receive and Receivecomplete Interrupt
    UCSR0B = (1<<RXEN0) | (1 << RXCIE0);

    // Set frameformat to 8 Data and 1 Stopbit
    UCSR0C = ((1<<UCSZ00)|(1<<UCSZ01));
}

void rx_to_led(int rx){
    // Maps the parameter to the 8 output-LEDs
    int b = rx >> 2;
    int d = (rx & 3) << 6;

    PORTB = b;
    PORTD = d;
}

int main(void) {
    // Enable 8 Outputs connected to LEDs.
    DDRB = (1 << PB0) | (1 << PB1) |(1 << PB2) |(1 << PB3) |(1 << PB4) | (1 << PB5);
    DDRD = (1 << PD6) | (1 << PD7);

    sei();      // Enable global interrupts
    USART_init();
    while (1){

    }
    return 0;
}

ISR(USART_RX_vect, ISR_BLOCK){
    rx_to_led(UDR0);
}

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

Passt die Software zur Hardware:
Stimmt die Baudrate?
Ist F_CPU korrekt? (Stichwort: CLKDIV8 Fuse)

[Udo S. (urschmitt)]

Loris I. schrieb:
> void rx_to_led(int rx){
>     // Maps the parameter to the 8 output-LEDs
>     int b = rx >> 2;
>     int d = (rx & 3) << 6;
>
>     PORTB = b;
>     PORTD = d;
> }

Stimmt diese Funktion? Hast du die mal mit verschiedenen festen Werten 
getestet?

[Udo S. (urschmitt)]

Mir fällt gerade auf du hast die Variablen als int definiert. Da wird 
arithmetisch geshiftet.
Da wäre ein uint8_t als Typ die richtigere Wahl.

[Ernst O. (ernstj)]

Stimmt die Zuordnung von Spannnungspegeln und logiscchen Pegeln?
(ist irgendwo etwas invertiert?)

[Loris I. (loris1123)]

Vielen dank für die viele schnelle Hilfe!

Die Funktion rx_to_led habe ich mit verschiedenen werten getestet. Sie 
funktioniert.

Als F_CPU habe ich 16000000UL gesetzt, da das in vielen Beispielen mit 
diesem µC auch gesetzt war. Wobei ich gestehen muss, dass ich (noch) 
nicht genau verstehe was das genau bedeutet.
Ich lese mich da gerade ein bissche ein und ich kann scheinbar über 
CKSEL0..3 die Clock setzen.
Ich könnte mir vorstellen, dass der Arduino Bootloader hier vielleicht 
verschiedene Werte setzt.
Dem werde ich auf den Grund gehen.

[Udo S. (urschmitt)]

Loris I. schrieb:
> Die Funktion rx_to_led habe ich mit verschiedenen werten getestet. Sie
> funktioniert.

Meine C Kenntnisse sind jetzt zwar etwas eingerostet aber das du hier 
einem 8 Bit Port ein int zuweist müsste aber mindestens eine Warning 
erzeugen.
Compiliere mal mit allen Warnings an.

[Loris I. (loris1123)]

Eine Kleinigkeit ist mir gerade noch aufgefallen, die vielleicht auch 
interessant ist:

Beim senden von 'o' leuchtet zuerst 1111110 auf. Beim wiederholen dann 
nur noch 10011110. Bei weiteren Wiederholungen blinken dann die 2. und 
3. LED ganz kurz auf.

[Karl H. (kbuchegg)]

Loris I. schrieb:
> Vielen dank für die viele schnelle Hilfe!
>
> Die Funktion rx_to_led habe ich mit verschiedenen werten getestet. Sie
> funktioniert.
>
> Als F_CPU habe ich 16000000UL gesetzt, da das in vielen Beispielen mit
> diesem µC auch gesetzt war. Wobei ich gestehen muss, dass ich (noch)
> nicht genau verstehe was das genau bedeutet.

Das bedeutet, dass dein M328p mit 16Mhz läuft. Und das stimmt ja auch. 
Auf einem Arduino Uno ist ein Keramik Resonator mit 16Mhz verbaut.

> Ich lese mich da gerade ein bissche ein und ich kann scheinbar über
> CKSEL0..3 die Clock setzen.

Vorsicht.
Dein Uno ist schon mit der richtigen Einstellung gekommen. Das passt 
schon.

> Ich könnte mir vorstellen, dass der Arduino Bootloader hier vielleicht
> verschiedene Werte setzt.

Nein. Der Boorloader kann diese Werte nicht ändern.
Wozu auch? Der Resonator als Bauteil hat nun mal 16Mhz.

> Dem werde ich auf den Grund gehen.

Dreh erst mal deine Senderichtung um.
Lass den Arduino senden und sieh dir am Pi im Terminalprogramm an, was 
da rauskommt. Es ist immer eine gute Idee, zuerst den Teilnehmer 
empfangen zu lassen, bei dem man das Empfangene einfach sichtbar machen 
kann und dem man soweit vertraut, das alles in Ordnung ist.
Steht diese Kommunikationsrichtung erst mal, dann funktioniert die 
andere Richtung normalerweise sofort. Ist auch logisch: wird ja in 
beiden Fällen die gleiche Baudrate benutzt.

[Loris I. (loris1123)]

Karl Heinz schrieb:

> Das bedeutet, dass dein M328p mit 16Mhz läuft. Und das stimmt ja auch.
> Auf einem Arduino Uno ist ein Keramik Resonator mit 16Mhz verbaut.

Und wenn ich den internen Resonator verwenden möchte? Der Arduino ist 
nur zum Prototyping gedacht. Später wollen/sollen wir auf einen 
einzellnen Microcontroller umsteigen.

> Dreh erst mal deine Senderichtung um.
> Lass den Arduino senden und sieh dir am Pi im Terminalprogramm an, was
> da rauskommt. Es ist immer eine gute Idee, zuerst den Teilnehmer
> empfangen zu lassen, bei dem man das Empfangene einfach sichtbar machen
> kann und dem man soweit vertraut, das alles in Ordnung ist.
> Steht diese Kommunikationsrichtung erst mal, dann funktioniert die
> andere Richtung normalerweise sofort. Ist auch logisch: wird ja in
> beiden Fällen die gleiche Baudrate benutzt.

Daran hatte ich auch schon gedacht. Das Problem ist nur, dass ich keinen 
Spannungsteiler zur Hand habe, da der Arduino mit 5V läuft und der RPi 
mit 3,3V könnte der Rückweg problematisch werden.

[Karl H. (kbuchegg)]

Loris I. schrieb:
> Karl Heinz schrieb:
>
>> Das bedeutet, dass dein M328p mit 16Mhz läuft. Und das stimmt ja auch.
>> Auf einem Arduino Uno ist ein Keramik Resonator mit 16Mhz verbaut.
>
> Und wenn ich den internen Resonator verwenden möchte?

Dann musst du an die Fuses ran.

Aber so wie der Ardunio geliefert wurde, läuft er mit 16Mhz durch den 
externen Resonator. Und genau das ist auch der Zweck von F_CPU: den 
Compiler darüber zu informieren, dass der µC mit 16Mhz rennt.

Das ändert aber am Grundproblem nichts.
Mit dem internen Generator (der kein Resonator ist), ist die Genauigkeit 
der Taktfrequenz schlechter als mit dem externen Generator. Wenn du mit 
dem Resonator keine saubere UART hinkriegst, dann kriegst du es mit dem 
interen Takt auch nicht hin.

> Daran hatte ich auch schon gedacht. Das Problem ist nur, dass ich keinen
> Spannungsteiler zur Hand habe, da der Arduino mit 5V läuft und der RPi
> mit 3,3V könnte der Rückweg problematisch werden.

Dann besorg dir 2 Widerstände.
Das Stochern im Nebel muss aufhören. Raten ist ein schlechter Ratgeber, 
auch wenns manchmal nicht anders geht.

[MWS (Gast)]

Loris I. schrieb:
> Und wenn ich den internen Resonator verwenden möchte? Der Arduino ist
> nur zum Prototyping gedacht. Später wollen/sollen wir auf einen
> einzellnen Microcontroller umsteigen.

Es gibt keinen internen Resonator, nur einen RC-Oszillator, der im 
allgemeinen nix für serielle Kommunikation taugt, zu ungenau.

Über den ISP-Anschluss kann man das alles ändern und dauch dafür sorgen, 
dass gar nichts mehr geht.

Ein Bootloader ist sicherer, da kann man nichts verpfuschen, da man 
keinen Zugriff auf die Fuses hat. Ein ATM328 von der Stange wird 
allerdings keinen Bootloader haben, da muss dann der ISP ran.

[Loris I. (loris1123)]

Ich habe nun den Arduino über den 3,3V Pin des Raspi betrieben. So 
brauche ich keinen Spannungsteiler. Für LEDs scheint es dann nicht mehr 
zu reichen, aber die brauche ich ja vorerst nicht unbedingt.
Was ich gesendet habe, habe ich den Atmega direkt zurücksenden lassen.
Minicom gibt mir beim senden von a-z folgendes:

yz{|}~hijklmnoxyz{|}~xyz

[Stefan F. (Gast)]

3,3V reichen für rote, gelbe und grüne LED's aus.

Die Werte für die Baudraten-Initialisierung berechnet man normalerweise 
mit hilfe von Makros aus der AVR C Library: 
http://www.nongnu.org/avr-libc/user-manual/group__util__setbaud.html

#define BAUD 9600
#include <util/setbaud.h>
UBRR0H = UBRRH_VALUE;
UBRR0L = UBRRL_VALUE;
#if USE_2X
    UCSR0A |= (1 << U2X);
#else
    UCSR0A &= ~(1 << U2X);
#endif

[Loris I. (loris1123)]

Stefan Us schrieb:
> 3,3V reichen für rote, gelbe und grüne LED's aus.
>
> Die Werte für die Baudraten-Initialisierung berechnet man normalerweise
> mit hilfe von Makros aus der AVR C Library:
> http://www.nongnu.org/avr-libc/user-manual/group__util__setbaud.html
>
>

> #define BAUD 9600
> #include <util/setbaud.h>
> UBRR0H = UBRRH_VALUE;
> UBRR0L = UBRRL_VALUE;
> #if USE_2X
>     UCSR0A |= (1 << U2X);
> #else
>     UCSR0A &= ~(1 << U2X);
> #endif
>

Das wars! Die Baudrate scheint wohl falsch berechnet gewesen zu sein. 
Viele dank!!
Grüße Loris