AVR/Atmega8 an STK500 - UART/USART

[Andrey B. (rrreey)]

Hallo zusammen,

vielleicht kann mir jemand helfen. Ich habe ein STK500 und ein Atmega8 
da drauf. Eine UART Kommunikation habe ich zum PC hergestellt bzw. 
schicke ein Zeichen von dem Controller an den PC. Dazu verwende ich bei 
dem Atmega 1MHz und Baudrate von 4800. Allerdings wenn ich das am 
Computer lesen möchte, zeigt er mir nur Nullen an bzw. dass er nur 
Nullen bekommt,egal welches Zeichen ich sende. Am Oszilloskop sehe ich 
dagegen die unterschiedlichen Signale. Zum Empfangen bzw. Anzeigen  der 
Daten verwende ich das Programm HTerm. Woran könnte das liegen? Hat da 
jemand eine Idee?
Vielen Dank im voraus!

[Hubert G. (hubertg)]

Falsche Initialisierung des µC wäre eine Möglichkeit.

[Harald M. (mare_crisium)]

Andrey,

hast Du auf dem STK500 die Verbindung vom PortD (Pins PD0 und PD1) zum 
Anschluss "RS232 SPARE" (STK500-User Guide, Seite 3-5) hergestellt? 
Steckt Dein RS232-Kabel im Anschluss "RS232 Port for Communication" 
(STK500-User Guide, Seite 3-1)?

Ciao,

mare_crisium

[Karl H. (kbuchegg)]

Ich muss nachhaken
> zeigt er mir nur Nullen an bzw. dass er nur Nullen bekommt
heißt das, das du in hTerm siehst, das etwas ankommt und dieses etwas 
sind lauter binäre 0-en (oder immer der Code für das ASCII Zeichen '0', 
was auch ungewöhnlich wäre)

Oder steht im hTerm der Cursor still und nichts rührt sich?
Das ist nicht dasselbe. Im einen Fall kommt tatsächlich ein Empfang zu 
Stande, im anderen Fall aber nicht. Letzterer Fall könnte zb dadurch 
verursacht werden, dass das verwendete Kabel falsch rum gekreuzt ist.

Ich würde als erstes mal die grundsätzliche physikalische Verbindung 
testen.
Dazu nimmst du den µC aus seinem Sockel und brückst mit einem Stück 
Draht den Tx-Pin mit dem Rx-Pin direkt im µC-Sockel. Wenn du dann am PC 
auf der Tastatur klimperst, muss alles was du tippst auch am Monitor 
erscheinen. Gegentest: die Brücke rausnehmen und das Echo muss aufhören.
Wenn du diesen Zustand hast, dann ist damit abgeklärt, dass die 
physikalische Verbindung, inklusive Kabel, inklusive aller Jumper auf 
dem STK grundsätzlich funktionsfähig ist.

[Andrey B. (rrreey)]

Vielen Dank erstmal für die Antworten!

Harald M., ja die Anschlüsse sind richtig verbunden.

Karl Heinz Buchegger,in HTerm sehe ich das ein Signal ankommt und diesel 
Signal wird anscheinend als Null interpretiert, d.h. es kommen laute 
binäre Nullen.
Die physikalische Verbindung werde ich dann wohl wieder nachprüfen und 
sobald ich es getan habe,hier bescheid geben.

[Andrey B. (rrreey)]

Moment,die Verbindung besteht ja. Ich bekomme das Signal am PC und kann 
es auch mit einem Oszilloskop abgreifen.

[Hubert G. (hubertg)]

Doch ein Initialisierungsfehler?

[Andrey B. (rrreey)]

Hier habe ich meinen Quelltext für das Programm. Weiß nicht,ob ich alles 
richtig gemacht habe. Vielleicht sieht ja jemand von euch den Fehler.

[Hubert G. (hubertg)]

Ich nehme mal an du hast die Initialisierung aus dem Datenblatt 
abgeschrieben. Hast du im HTerm aber auch zwei Stoppbits eingestellt?

[Andrey B. (rrreey)]

Ja, ich habe es mit unterschiedlicher Konfiguration ausprobiert, es 
kommen trotzdem immer nur Nullen an.

[Karl H. (kbuchegg)]

Quelltext als PNG?
(Das ist das dümmste was du tun kannst. Wie soll ich mich denn jetzt mit 
Cut&Paste auf deinen Quelltext beziehen und daraus Passagen zitieren. 
Abgesehen davon hast du eine Menge Arbeit damit, das PNG herzustellen.
Quelltext postest du ganz einfach als .... tata .... Quelltext. Was für 
eine Überraschung! Das ist für dich am wenigsten Arbeit und wir können 
uns problemlos auf Passagen beziehen)


     USART_transmit( 0x01 );


lass dir zuerst mal etwas senden, was ein sichtbares Zeichen ergibt. Das 
Bitmuster für 0x01 zu senden und dann mit der Ausgabe kombinieren, dass 
beim Empfänger IMMER nur ein 0-Byte ankommt, das war nicht sehr 
hilfreich. Denn die USART braucht nur in der Takfrequenz ein klein wenig 
daneben sein und schon kommt das einzige 1 Bit im Gesendeten nicht zur 
richtigen Zeit beim Empfänger an. Und von 'IMMER' kann auch keine Rede 
sein.

    USART_transmit( 'A' );

und dann schaun wir mal, was da rauskommt.
Wahrscheinlich das übliche. Deine Taktfrequenz ist ein wenig daneben. 
Die F_CPU Angabe stinkt nach internem RC-Generator. Die geht so genau 
wie die Messung der Seehöhe durch Messung des Wasserstands in der Donau.

[Stefan E. (sternst)]

USART_Init(BAUD);

Nö.

[Stefan E. (sternst)]

Karl Heinz Buchegger schrieb:
> Das
> Bitmuster für 0x01 zu senden und dann mit der Ausgabe kombinieren, dass
> beim Empfänger IMMER nur ein 0-Byte ankommt, das war nicht sehr
> hilfreich. Denn die USART braucht nur in der Takfrequenz ein klein wenig
> daneben sein und schon kommt das einzige 1 Bit im Gesendeten nicht zur
> richtigen Zeit beim Empfänger an.

Damit bei 0x01 am Empfänger eine 0 ankommt, muss der Takt schon gewaltig 
daneben liegen. Hinweis: es wird LSB-first gesendet. ;-)

[Andrey B. (rrreey)]

also hier der Quelltext nochmal:

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


#ifndef F_CPU
#define F_CPU 1000000UL   // Systemtakt in Hz - Definition als unsigned long beachten 
                         // Ohne ergeben sich unten Fehler in der Berechnung
#endif


#define BAUD 9600UL      // Baudrate
#include <util/setbaud.h>
#define UBRR_VAL ((F_CPU)/(BAUD*16)-1)   // clever runden
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1)))     // Reale Baudrate
#define BAUD_ERROR ((BAUD_REAL)/(BAUD)-1)*100 // Fehler in Promille, 1000 = kein Fehler.


#if ((BAUD_ERROR<99) || (BAUD_ERROR>101)) 
#endif 
#include <util/delay.h>
#include <inttypes.h>



void USART_Init(void){
   UBRRH = UBRR_VAL >> 8;
   UBRRL = UBRR_VAL & 0xFF;
  
  UCSRB = (1<<RXEN)|(1<<TXEN);
  UCSRC = (1<<URSEL)|(1<<USBS)|(3<<UCSZ0);
}

void USART_Transmit(unsigned char data){
  while(!(UCSRA)&(1<<UDRE));
  UDR = data;
}

void USART_TransmitC(unsigned char *s)
{
    while (*s)
    {   // so lange *s != '\0' also ungleich dem "String-Endezeichen(Terminator)" 
        USART_Transmit(*s);
        s++;
    }
}



int main(){
  
   // Ausgabe von 0123456789
   char c;
 
   USART_Init();
   
 /*
   for (uint8_t i=0; i<=9; ++i) {
      c = i + "0";
      USART_TransmitC(c);

   }
 */
   while (1) {
    DDRC = 0xff;
      PORTC = 0x00;
    _delay_ms(500);
    PORTC = 0xff;
    _delay_ms(500);
    USART_Transmit(0xFF);
  
   }
 
   return 0; // never reached 
 
  
}

[Andrey B. (rrreey)]

hab das jetzt soweit,dass ich für

 USART_Transmitt(0x01);

eine "129"(dezimal) bekomme. Dementsprechend für

 USART_Transmitt(0x00);

 "128"
Jetzt weiß ich nicht wo mein Fehler liegt.

[Stefan E. (sternst)]

Andrey B. schrieb:
> hab das jetzt soweit,dass ich für

 USART_Transmitt(0x01);

> eine "129"(dezimal) bekomme. Dementsprechend für

USART_Transmitt(0x00);

> "128"
> Jetzt weiß ich nicht wo mein Fehler liegt.

Das bedeutet, dass das Stopp-Bit zu früh kommt. Das dürfte jetzt das 
schon von Karl Heinz angesprochene "interner RC-Oszillator"-Problem 
sein.

[Andrey B. (rrreey)]

Was muss ich denn jetzt genau machen,um dieses Problem zu lösen?

[Karl H. (kbuchegg)]

Andrey B. schrieb:
> Was muss ich denn jetzt genau machen,um dieses Problem zu lösen?

Den Mega nicht mit dem internen RC-Oszllator laufen lassen, sondern 
einen Quarz oder Quarzoszillator aktivieren.

[Stefan E. (sternst)]

Moment: bei 1 MHZ und 9600 Baud und ohne U2X ist der Fehler schon 
prinzipiell viel zu groß. Benutze U2X oder 4800 Baud.


PS:

#if ((BAUD_ERROR<99) || (BAUD_ERROR>101)) 
#endif

War wohl keine so gute Idee, die Zeile dazwischen zu löschen. ;-)

[Andrey B. (rrreey)]

Vielen Dank.so hier der Code, der jetzt auch funktioniert.Das war 
tatsächlch die Baudrate. Hab die jetzt auf 4800 gestellt.:

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


#ifndef F_CPU
#define F_CPU 1000000UL   // Systemtakt in Hz - Definition als unsigned long beachten 
                         // Ohne ergeben sich unten Fehler in der Berechnung
#endif


#define BAUD 4800UL      // Baudrate
#include <util/setbaud.h>
#define UBRR_VAL ((F_CPU)/(BAUD*16)-1)   // clever runden
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1)))     // Reale Baudrate
#define BAUD_ERROR ((BAUD_REAL)/(BAUD)-1)*100 


#if ((BAUD_ERROR<99) || (BAUD_ERROR>101)) 
#endif 
#include <util/delay.h>
#include <inttypes.h>



void USART_Init(void){
   UBRRH = UBRR_VAL >> 8;
   UBRRL = UBRR_VAL & 0xFF;
  
  UCSRB = (1<<RXEN)|(1<<TXEN);
  UCSRC = (1<<URSEL)|(0<<USBS)|(3<<UCSZ0);
}

void USART_Transmit(unsigned char data){
  while(!(UCSRA)&(1<<UDRE));
  UDR = data;
}

void USART_TransmitC(unsigned char *s)
{
    while (*s)
    {   // so lange *s != '\0' also ungleich dem "String-Endezeichen(Terminator)" 
        USART_Transmit(*s);
        s++;
    }
}



int main(){
  
   // Ausgabe von 0123456789
   char c;
 
   USART_Init();
   
 /*
   for (uint8_t i=0; i<=9; ++i) {
      c = i + "0";
      USART_TransmitC(c);

   }
 */
   while (1) {
    DDRC = 0xff;
      PORTC = 0x00;
    _delay_ms(500);
    PORTC = 0xff;
    _delay_ms(500);
    USART_Transmit(0x00);
  
   }
 
   return 0; // never reached 
 
  
}

[Karl H. (kbuchegg)]

Andrey B. schrieb:

> #if ((BAUD_ERROR<99) || (BAUD_ERROR>101))
> #endif


Ist natürlich auch eine Möglichkeit eine Fehlermeldung zu löschen, die 
einem gesagt hätte, dass sich das mit den Zahlenwerten nicht vernünftig 
ausgeht.