Atmega8 scheint UART zu empfangen

[Gerrit (Gast)]

Hallo zusammen,

ich habe das myAVR MK2 bei mir im Einsatz. Nun habe ich laut Datenblatt 
versucht Text zu senden bzw. zu empfangen.

Der Versand einer Zeichenkette funktioniert. Seltsam ist nur, dass der 
Terminal vor der Empfangenen Zeichenkette immernoch ein kryptisches 
Zeichen darstellt.

Viel irritierender finde ich aber, dass ich LEDs am PORTC einschalte, 
bevor ich in meinen while(1) gehe. In der Schleife rufe ich dann die 
folgende Funktion auf:

unsigned char USART_Receive( void )
{
    /*
    Wait for data to be received
    */
    while ( !(UCSRA & (1<<RXC)) );
    /*
    Get and return received data from buffer
    */
    return UDR;
}

Den Rückgabewert setze ich dann als PORTC:

    unsigned char zeichen = USART_Receive();
    PORTC = zeichen;

Wenn ich den AVR nun resette, gehen die LEDs an und gleich wieder aus. 
Und das ohne, dass ich den Terminal auch nur geöffnet, geschweige 
verbunden habe.

PS: Ich hatte auch versucht das empfangene Zeichen gleich wieder zu 
senden. Das ist dann aber ebenfalls ein kryptisches Zeichen, welches 
immer und immer wieder im Terminal ankommt.

Hat jemand eine Idee??

[Stefan F. (Gast)]

Zeige mal das ganze Programm.
Hast du ein Oszilloskop oder Logiktester?
Kannst du den RxD Pin mal fest auf High legen, damit er ganz sicher 
nichts empfängt?

[Karl M. (Gast)]

Hallo Gerrit,

aus meinen Anfängen habe ich auch noch solch ein Board herumliegen.

Wie sieht dein Makefile aus und welchen AVR µC CPU hast Du verwendet ?

[Clemens L. (c_l)]

Gerrit schrieb:
> Seltsam ist nur, dass der Terminal vor der Empfangenen Zeichenkette
> immernoch ein kryptisches Zeichen darstellt.

Welches?  ÿ?

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

Clemens L. schrieb:
> Welches?  ÿ?
0xFF?
Siehe https://en.wikipedia.org/wiki/ISO/IEC_8859-1

[Gerrit (Gast)]

Ich habe das MK2 mit einem Atmega8.

[Gerrit (Gast)]

Ja, so sieht das Zeichen aus, welches als erstes geschickt wird.

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

Gerrit schrieb:
> Ja, so sieht das Zeichen aus, welches als erstes geschickt wird.
Das ist kein Zeichen, sondern ein simpler Pegelwechsel an der 
RX-Leitung.

Du solltest da auch einen Übertragungsfehler "Framing Error" bekommen, 
weil da kein Stopbit übertragen wird. Du solltest also hier diese 
Fehlerbits auch noch auswerten, wenn dein Protokoll ein solches 
Startup-Verhalten nicht ignorieren kann...

[Gerrit (Gast)]

Okay, das komische Bit zu Beginn, war der Druck der Reset-Tast.

Mein Code ist nun wie folgt:

#define F_CPU 3686400// Clock Speed
#define BAUD 9600
#define MYUBRR F_CPU/16/BAUD-1

#include <avr/io.h>
#include "util/delay.h"


void USART_Init(unsigned int ubrr) {
  /* Set baud rate */
  UBRRH = (unsigned char)(ubrr>>8);
  UBRRL = (unsigned char)ubrr;
  /* Enable receiver and transmitter */
  UCSRB = (1<<RXEN)|(1<<TXEN);
  /* Set frame format: 8data, 2stop bit */
  UCSRC = (1<<URSEL)|(1<<USBS)|(3<<UCSZ0);
}

unsigned char receiveByte(void) {
  while ( !(UCSRA & (1<<RXC)) )       /* Wait for incoming data */
  return UDR;                                /* return register value */
}

void USART_Transmit( unsigned char data )
{
  /* Wait for empty transmit buffer */
  while ( !( UCSRA & (1<<UDRE)) )
  ;
  /* Put data into buffer, sends the data */
  UDR = data;
}

void printString(const char myString[]) {
  uint8_t i = 0;
  while (myString[i]) {
    USART_Transmit(myString[i]);
    i++;
  }
}

int main(void)
{
    /* Replace with your application code */
  
  USART_Init(MYUBRR);
  unsigned char zeichen;
  
  printString("Welcome AVR!\r\n");
  
  DDRC = 0b11111111;
  PORTC = 0b11111111;
  
    while (1) 
    {
    zeichen = receiveByte();
    PORTC= zeichen;
    printString("Test\r\n")
    _delay_ms(200);
    }
  
  return 1;
}

Seltsam ist halt, dass die leuchtenden LEDs kurz angehen und gleich 
wieder aus.

[Georg G. (df2au)]

Schaltbild?

[Gerrit (Gast)]

Wie bereits geschrieben, habe ich das MK2 mit mySmartUsb MK2 im Einsatz. 
Heißt, das ist alles verkabelt und der SmartUsb steht auf Datenmodus. An 
PORTC sind nur LEDs.

[Georg G. (df2au)]

Gerrit schrieb:
> PORTC sind nur LEDs.

LED gegen Masse oder gegen VCC?

[Alex P. (alex2203)]

Ich tippe mal ganz schwer, das die LED's gegen Masse sind. Somit ist 1 
gleich 0 und umgekehrt.

Schmeiss das hier mal raus

  DDRC = 0b11111111;
  PORTC = 0b11111111;


und stattdessen:

  DDRC = 0xFF;
  PORTC = 0x00;

[Gerrit (Gast)]

Guten Abend zusammen,

ich habe mir das nun noch mal in Ruhe angesehen. Ich habe meine Main() 
wie folgt geändert:

int main(void)
{
    /* Replace with your application code */
  
  USART_Init(MYUBRR);
  unsigned char zeichen;
  
  printString("Welcome AVR!\r\n");
  
  DDRC = 0xFF;
  PORTC = 0xFF;
  _delay_ms(1000);
  
    while (1) 
    {
    zeichen = receiveByte();
    PORTC = PORTC << 1;
    //PORTC= zeichen;
    //printString("Test\r\n")
    _delay_ms(200);
    }
  
  return 1;
}

Die Funktion zum Empfangen ist:

unsigned char receiveByte(void) {
  while ( !(UCSRA & (1<<RXC)) )       /* Wait for incoming data */
  return UDR;                                /* return register value */
}

Es gehen nun alle LEDs an. Sobald ich in den Loop komme, geht eine nach 
der anderen LED aus. Woraus ich schließe, dass die 
receiveByte()-Funktion nicht auf das Bit wartet bzw. das Bit scheinbar 
gesetzt ist.

Ich habe auch versucht in der Init das RXC Bit auf 0 zu setzen, änderte 
am Verhalten auch nichts:

UCSRA &= ~(1 << RXC);

[Gerrit (Gast)]

Gelöst: Fehlendes Semikolon in while() in receiveByte();

[Stefan F. (Gast)]

Interessant finde ich, dass der Compiler diese Stelle nicht mit einem 
Syntaxfehler bemängelt hat.

[Georg G. (df2au)]

Stefan U. schrieb:
> Interessant finde ich, dass der Compiler diese Stelle nicht mit einem
> Syntaxfehler bemängelt hat.

Warum sollte er? War alle syntaktisch korrekt.

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

Georg G. schrieb:
> War alle syntaktisch korrekt.
Er hat eben nur nicht gewartet, bis ein Zeichen da ist...

Gerrit schrieb:

 while ( !(UCSRA & (1<<RXC)) )
 return UDR;

Dort steht: "solange nicht fertig, gib das UDR zurück"...

[Georg G. (df2au)]

Lothar M. schrieb:
> Er hat eben nur nicht

Genau das ist meist das Problem, der Compiler versteht einfach den 
Programmierer nicht richtig. Für viele dieser Missverständnisse hat ein 
guter Compiler Warnungen, die ein defensiver Programmierer auch ernst 
nimmt. Aber leider funktioniert das nicht immer. Und viele Programmierer 
finden es auch toll, wenn sie jede überflüssige Klammer, jeden Kommentar 
weglassen.

> Dort steht: "solange nicht fertig, gib das UDR zurück"...
Und das ist dummerweise das genaue Gegenteil dessen, was beabsichtigt 
war :-)