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.
Mit 1 MHz macht die UART ohne U2X glatte 7% Fehler bei 9600 Baud. Das geht mit großer Wahrscheinlichkeit schief!
@Rahul:
> Dann hast du meine Voodoo-Puppe in die Augen gestochen!
Hoffentlich hab ich ihr den Rest gegeben...;-)
Es ist doch richtig, dass die Frequenz entsprechend diesem Wert gesetzt werden muss... nochn Anhang
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
Naja, man könnte auch die Baudraten-Frequenz von 3,686MHz einstellen. (Aber das ist eine andere Baustelle...)
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.