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
>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.
>@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.
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.
>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...).
>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".
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.
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.
