www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik "Zeichensalat" über den UART


Autor: Timo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
Haben folgendes Programm in den Controller (ATMega 16) geladen:
#include <avr/io.h>

#ifndef F_CPU
#define F_CPU 8000000UL              
#endif              

#define UART_UBRR_CALC(BAUD_,FREQ_) ((FREQ_)/((BAUD_)*16L)-1)

#define UART_BAUD_RATE 9600         


int main (void)
{
  UCSRB  |=  (1<<TXEN);            
  UCSRC  |=  (1<<URSEL)  |  (3<<UCSZ0);  

  UBRRH  =  0x00;
  UBRRL  =  0x33;
 
  //Senden einzelner Zeichen

  while (!(UCSRA & (1<<UDRE)))        
  {
  }

  while (1)
  {
    UDR    =  'A';
  }

  return (0);
  }

Die Baudrate ist auf 9600 eingestellt -> siehe UBRRL = 33_hex -> 51_dez
-> bei 8 MHz = 9600 Baud (laut Toturial)

Wir haben einen Schnittstellentreiber benutzt (MAX232). Zum Testen, ob
der Controller "sendet", haben wir ein Schnittstellentester zwischen
MC und PC geschaltet. Die LED TX und RX leuchten korrekt. Wir verwenden
auch das korrekte Kabel. Wir wollen das Zeichen "A" nun am PC auslesen.
Wir benutzen HyperTerminal. Drücken wir nun auf lesen (Baud - Rate,
Stop - , Startbit und soweiter korrekt eingestellt) erhalten wir
Zeichen vom MC. Jedoch NICHT nur dass gewünschte A, sondern ab und zu
ist ein "P" dabei, ein "I" u.s.w. Sieht aber alles sehr regelmäßig aus.
Wir haben nun zum Test ein anderes Zeichen vom MC gesendet. Es kommt
aber immer der selbe "Zeichensalat" an. Wir haben die TX - Leitung des
MC am Oszilloskop untersucht. Das "A" lässt sich nicht erkennen. Wir
haben das wie folgt gemacht:

ASCII - Code für "A" herausgesucht. Diesen in einen Binärwert
umgerechnet. Start- und Stopbit berücksichtigt. Dann haben wir uns
dass zu erwartende Bitmuster aufgezeichnet.
Anschließend haben wir gemessen. Das theoretische stimmt keineswegs
mit dem gemessenen überein. Wir sehen zwar TTL - Signale, die auch
sehr regelmäßig sind, diese ergeben aber keinen Sinn. Rechnerisch
brauchen wir bei 9600 Baud pro Bit etwa 10 us. Am Oszilloskop nach-
gemessen sind es etwa 100 us.

Ist am Programm etwas faul?
Sonstige Ideen ?

Achja:
Folgende Änderung des Quellcodes haben wir verwendet:
  while (1)
  {
    if (UCSRA & (1<<UDRE))
    {
    UDR    =  'A';
    }
  }

Nach dieser Änderung sollte er nach jedem gesendeten Zeichen auf die
Bereitschaft ein Zeichen zu senden warten. Aber auch hier das selbe
Problem wie bereits erwähnt. Wir empfangen "Zeichensalat".

Autor: Jörg X. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du wartest beim ersten Code-Teil ein Mal darauf, dass der USART bereit 
ist. Du musst das natürlich jedes Mal machen:
while (1){
    while(!UCSRA & (1<<UDRE))
        ; // dies ist eine Warteschleife
    UDR = 'A';
}
und die ~100µs scheinen mir korrekt: beim UART entspricht die Baudrate 
der _Bit_-rate

lies bitte noch mal nach, wie man die Register des UART benutzt (im 
Datasheet am besten)

hth. Jörg

Autor: Timo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Jörg. Meinst du also, dass ich die Register falsch benutze?

Autor: Jörg X. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nicht völlig falsch, aber man sollte sich die entsprechenden Kapitel mal 
anschauen ("Register description", gibt's im Datasheet für fast alle 
Peripherie) und auch den Code verstehen, wie z.B die leeren 
while-Schleifen, die ja öfter vorkommen.
 Auch ist es besser Formeln in den Code zu schreiben, z.B. in Makros, 
als nur die Zahlen. In deinem Quelltext stehen die defines für die 
UBRR-Registerwerte schon drin, aber du benutzt sie nicht:
#define UART_UBRR_CALC(BAUD_,FREQ_) ((FREQ_)/((BAUD_)*16L)-1)
#define UART_BAUD_RATE 9600

// ...

UBRRH = UART_UBBR_CALC(UART_BAUD_RATE) >> 8; //Highbyte
UBRRL = UART_UBBR_CALC(UART_BAUD_RATE); //Lowbyte
/* falls das nicht klappt, beides nach "uint8_t" bzw "unsigned char" casten:
UBRRL = (uint8_t) UART_UBBR_CALC(UART_BAUD_RATE);
*/
Die Warteschleife "while(!UCSRA & (1<<UDRE));" soll verhindern, dass 
Werte im UDR überschrieben werden.

Und die letzte Fehlerquelle (eigentlich die erste): Bist du sicher, dass 
der Atmega mit den 8MHz läuft?
 Nur "#define F_CPU 8000000L" reicht ja nicht (Stichwort: Fuses).

hth. Jörg

Autor: Timo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also:
Der Controller läuft mit 8 MHz. Haben es extra mit dem Oszi überprüft. 
Wir haben deine Zeile zum Senden übernommen:

Also:
while (1){
    while(!UCSRA & (1<<UDRE))
        ; // dies ist eine Warteschleife
    UDR = 'A';
}


Der Pegelwandler ist richtig verlötet. Wir empfangen trotzdem nicht das 
gewünschte Zeichen.

An was kann es liegen? Es kommt wieder "Zeichensalat" an.

Gruß

Autor: Toni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Masse verbunden?

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Internen RC Osci verwendet ?

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Timo (Gast)

>Der Controller läuft mit 8 MHz. Haben es extra mit dem Oszi überprüft.

Mit inerenm 8 MHz Oszillator (UNGENAU!) oder Quarz/Quarzoszillator?

http://www.mikrocontroller.net/articles/AVR-Tutori...

MfG
Falk

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.