STK500/UART/Terminal - Problem

[Ralf (Gast)]

Hallo erstmal,

meine erste Frage als Microcontroller-Neuling ohne weitere 
Elektronikkenntnisse löst hoffentlich bei dem einen oder anderen 
Experten hier ein "Helfen-wir-dem-Jungen-mal-auf-die-Sprünge"-Gefühl 
aus. Ich komme alleine nämlich nicht weiter und hier im Forum gesucht 
hab´ ich auch schon.

Also, seit ein paar Tagen bin ich Besitzer eines STK500-Boards, welches 
ich mit einem Atmega32 bestückt habe. Programmierumgebung ist AVR Studio 
4 und WinAVR (beides frisch runter geladen), ich programmiere in C (ich 
versuch´s).

Einige Programme habe ich schon geschrieben und zum Laufen gekriegt.Bis 
jetzt kein Problem. Aber die Kommunikation über den UART macht mich noch 
irre.

Ich stelle über ein Terminalprogramm die Verbindung her und möchte ein 
Zeichen, welches ich an den AVR sende einfach nur zurück gesendet und 
auf der Terminalschirm dargestellt haben, mehr nicht. Leider klappt´s 
nicht.

Grundsätzlich funktioniert die Kommunikation irgendwie schon, d.h. ich 
kann senden, der AVR empfängt was und schickt auch was zurück.
Allerdings nur, wenn ich im Terminalprogramm eine geringere Baudrate 
einstelle als eigentlich laut Programm vorgesehen (=9600). 
Komischerweise werden die nebeneinanderliegenden Tasten "n", "m", ";", 
".""-",die Tasten "h", "j", "k","l" und noch einige andere Tasten dann 
richtig zurück gesendet, der Rest aber nicht, z.B. für ein"b" bekomme 
ich ein "z" zurück geliefert.

siehe Anhang

Folgendes Programm läuft auf dem AVR:

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


/* CPU Frequenz */
#define F_CPU 1000000L

#define BAUD 9600UL
#define UBRR_BAUD ((F_CPU/(16L*BAUD))-1)

// USART initialisieren
void uart_init(void)
{
// Baudrate einstellen (Normaler Modus)
UBRRH = (uint8_t) (UBRR_BAUD>>8 );
UBRRL = (uint8_t)UBRR_BAUD;

// Aktivieren von receiver und transmitter
UCSRB = (1<<TXEN) | (1<<RXEN);

// Einstellen des Datenformats: 8 Datenbits, 1 Stoppbit
UCSRC = (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0);

}

int main(void)
{
uint8_t buffer;

// USART initialisieren
uart_init();

while (1)
{
// Warten bis Daten empfangen wurden
while ( !(UCSRA & (1<<RXC)) );

// Empfangsregister auslesen
buffer = UDR;

// Warten bis der Sendepuffer frei ist
while ( !( UCSRA & (1<<UDRE)) );

// Daten in den Puffer schreiben und damit senden
UDR = buffer;


}
return 0;
}

Ich bin inzwischen ratlos. Kann mir einer helfen?

Grüße
Ralf

[fieser, klugscheissender Rahul (Gast)]

>siehe Anhang

Nicht vorhanden.

>#define F_CPU 1000000L

Läuft dein Controller wirklich mit 10MHz?
Das STK500 selbst schafft höchstens 3,686MHz.

>Komischerweise werden die nebeneinanderliegenden Tasten "n", "m", ";",
>".""-",die Tasten "h", "j", "k","l" und noch einige andere Tasten dann
>richtig zurück gesendet, der Rest aber nicht, z.B. für ein"b" bekomme
>ich ein "z" zurück geliefert.

Guck lieber mal nach, welchen Wert/welche Position diese Tasten in der 
(erweiterten) ASCII-Tabelle haben.

[johnny.m (Gast)]

@Rahul:
Ich sehe da nur 6 Nullen -> 1 MHz

[fieser, klugscheissender Rahul (Gast)]

>@Rahul:
>Ich sehe da nur 6 Nullen -> 1 MHz

Dann hast du meine Voodoo-Puppe in die Augen gestochen!

Kann trotzdem sein, dass die Baudrate aufgrund der Taktfequenz voll 
daneben liegt.

[johnny.m (Gast)]

Mit 1 MHz macht die UART ohne U2X glatte 7% Fehler bei 9600 Baud. Das 
geht mit großer Wahrscheinlichkeit schief!

[johnny.m (Gast)]

@Rahul:
> Dann hast du meine Voodoo-Puppe in die Augen gestochen!
Hoffentlich hab ich ihr den Rest gegeben...;-)

[Ralf (Gast)]

Sorry, Anhang...

[Ralf (Gast)]

Es ist doch richtig, dass die Frequenz entsprechend diesem Wert gesetzt 
werden muss... nochn Anhang

[Ralf (Gast)]

yeaaaahhh, es funzt!!!

Besten Dank@johnny.m

Der Hinweis >>Mit 1 MHz macht die UART ohne U2X glatte 7% Fehler bei 
9600 Baud<<

ich habe folgendes ergänzt:

#if F_CPU < 2000000UL
   UCSRA = (1 << U2X);
   UBRRL = F_CPU / (8 * 9600UL) - 1;
#else
   UBRRL = F_CPU / (16 * 9600UL) - 1;
#endif

Und nu löppt datt...

Grüße
Ralf

[unbeschreiblicher Rahul (Gast)]

Naja, man könnte auch die Baudraten-Frequenz von 3,686MHz einstellen.
(Aber das ist eine andere Baustelle...)

[Florian G. (suffix)]

Noch ein Hinweis:

Wenn du Einsteiger bist, dann fang erst mal mit Assembler an, ansonsten 
bekommst du öfters kleine Probleme, die du nich verstehst. Bei größeren 
Projekten machen C-Compiler manchmal Fehler. Ohne Assembler-Kenntnisse 
kannst du mit den erzeugten lst Files nichts anfangen und auch keine 
Fehler beheben.

Nur so ein Rat von mir.

Und im AVR-Studio hat man ja auch einen exzellenten Simulator auch für 
Assembler.

[unbeschreiblicher Rahul (Gast)]

>exzellenten Simulator

Der leider stellenweise etwas fehlerhaft ist.

>Bei größeren Projekten machen C-Compiler manchmal Fehler.
Und die schreibt man dann lieber in Assembler?

>ansonsten bekommst du öfters kleine Probleme, die du nich verstehst.
In Assembler passiert sowas nie?

C ist vielleicht etwas gewöhnungsbedürftig, weil es eine Menge möglich 
macht, an das man im ersten Moment nicht denk ("=" != "=="...), dafür 
muß man sich nur um das Programmieren und nicht um Speicherverwaltung 
kümmern.
Wer den Controller bis ins Detail kennenlernen will, oder extrem 
zeitkritische Anwendungen programmiert, (oder eine masochistische Ader 
hat), ist mit Assembler gut beraten. Wer das alles nicht möchte, nimmt 
Bascom (nur so am Rande), und wer irgendwas dazwischen will, nimmt C 
(oder Ada...).

[Ralf (Gast)]

>Wenn du Einsteiger bist, dann fang erst mal mit Assembler an, ansonsten
bekommst du öfters kleine Probleme, die du nich verstehst.

Also, nochmals besten Dank, auch für die nachfolgenden Tipps. Dass ich 
Einsteiger bin, bezog sich auf die Programmierung von Microcontrollern, 
nicht unbedingt auf die Programmierung in C.

Es ist mir schon klar, dass man das "Herz" eines uC besser versteht, 
wenn man sich in Assembler einarbeitet. Aber das würde mir die ganze 
Sache nochmals schwerer machen, und wie der unbeschreibliche schon 
anmerkte.... ich nehm´ lieber das "dazwischen".

[suffix (Gast)]

Ich meinte, wenn man sich am Anfang nicht mit den Innereien eines uC 
beschäftigt, bekommt man evtl. später bei größeren C-Projekten Probleme 
durch den Compiler, die man dann nicht beheben kann, weil man sich eben 
nicht mit der Speicherverwaltung auskennt. Also ich habs mir mit 
Assembler besser beigebracht.

[Karl heinz B. (kbucheg)]

suffix wrote:
> Ich meinte, wenn man sich am Anfang nicht mit den Innereien eines uC
> beschäftigt, bekommt man evtl. später bei größeren C-Projekten Probleme
> durch den Compiler,

Das würde ich so nicht unterschreiben.
Ein C Compiler ist auch nur ein Werkzeug, der einem aber
bei einem erstaunlich geringem Overhead eine Menge
Verwaltungskram abnimmt.

Nichts desto trotz bin ich durchaus deiner Meinung:
Ein Einstieg mit Assembler schadet nicht. Zum einen
führt man dadurch keinen 2-Frontenkrieg nämlich sich
gleichzeitig mit dem Aufbau des µC und mit einer,
im Vergleich zu Assembler, doch schon komplexen Sprache
rumzuschlagen. Zum anderen bleibt der Blick auf den
grundsätzlichen Aufbau und die Arbeitsweise des µC frei.
Und dieser Blick ist durchaus auch bei C Programmierung
wichtig.

Allerdings ist meine persönliche Einschätzung eher so:
Wenn man das Assembler Tutorial auf dieser Site durch-
gemacht und verstanden hat, hat man genügend auf Assembler-
ebene gemacht um den Umstieg zu C zu wagen und Assembler
ad acta zu legen. Danach hat man durchaus ein Verständnis
dafür, wie ein AVR arbeitet und wie man ihn dazu kriegt
bestimmte Dinge in Hardware zu tun. Alles darüber Hinausgehende
kann man genausogut auch in C machen und wird mit einem Wegfall
von Verwaltungskram, besseren Möglichkeiten von Projekt-
strukturierung und einer einfacheren Programmentwicklung belohnt.