Hallo Jungs, habe ein Prob. mit dem UART auf dem mega48. Kann auf PD1 einfach nichts messen :( Könnt ihr mir helfen... Hier mein Code bzw. der abgeänderte aus dem Netz: //************************************ USART Initialisieren void USART_Init() { // Set baud rate UBRR0H = 0; UBRR0L = 47; // 4800 bps // Enable transmitter UCSR0B |= (1<<TXEN0); // Set frame format: 8 Datenbits, 1 Stopbit UCSR0C |= (1<<UCSZ01)|(1<<UCSZ00); } //************************************ Daten senden void USART_Transmit() { /* Wait for empty transmit buffer */ while ( !( UCSR0A & (1<<UDRE0)) ) ; /* Put data into buffer, sends the data */ UDR0 = 'x'; } int main(void) { USART_Init(); while(1) { USART_Transmit(); // Daten senden } return 0; }
Jörg X. wrote:
> hilft ein "DDRD |= 1<<PD1;" irgendwo vor dem ersten Senden ?
Sollte keinen Effekt haben. Das Enable des Senders überschreibt die
Konfiguration im DDR. Durch das TXEN wird der Pin automatisch zum
Ausgang.
@Eddy: Wie wärs denn mal mit dem VOLLSTÄNDIGEN Code? Das da oben sieht soweit ganz OK aus...
@Johannes: Danke für den Hinweis mit dem DDR. Denn das habe ich mich auch schon gefragt. Was meinst du, vollständiger Code...? Ist doch alles was man braucht...oder?! Ok, es fehlt noch #include <avr/io.h>
Eddy wrote: > Ok, es fehlt noch > #include <avr/io.h> Eben. Immer ein compilierbares Programm schicken. Ist im Makefile der richtige Controller angegeben?
Womit misst du "nichts" ? Mit welchem Takt läuft der Atmega ? bzw. läuft der überhaupt? (Warum ist der UBBRR-Wert ausgeschrieben? die Formel geht doch auch) Fragen über Fragen.. hth. Jörg
@Johannes: Ja Controller läuft mit 3.686MHz UBRR-Wert ist ausgeschrieben, weil ich es einfach so gemacht habe...Kein besonderer Grund. Das Beschreiben des mega48 geht ohne Prob. Habe mein Prog. mal simuliert. Mir ist aufgefallen, nach dem Befehl UCSR0C |= (1<<UCSZ01)|(1<<UCSZ00); wird das 1.und 2.Bit des UBRR0H-Registers gesetzt, damit ändert sich die Baudrate die ich vorgegeben habe,komisch... Nach 2-Maligem Senden wird das UDRE0H-Bit gelöscht und der Zustand bleibt in der while-Schleife hängen...hmmm Versteh ich net...
Eddy wrote: > Habe mein Prog. mal simuliert. > Mir ist aufgefallen, nach dem Befehl > UCSR0C |= (1<<UCSZ01)|(1<<UCSZ00); > wird das 1.und 2.Bit des UBRR0H-Registers gesetzt, damit ändert sich die > Baudrate die ich vorgegeben habe,komisch... Das ist ein Fehler des Simulators. Hast Du im Simulator auch den richtigen µC angegeben? Schau auch mal in die Hilfe zum Simulator. Da stehen zumindest die bekannten Fallstricke drin. Z.B. steht da bei "UART/USART": > When writing to UCSRC, the value will be copied to UBRRH unless bit 7 is > also set in in the same write operation. This behaviour is erroneous on > devices that have separate locations for these registers. Another workaround > is to write UBRRH after UCSRC."
Hallo, ja, im Simulator ist der korrekte µC angegeben... Hmm, es wird ja empfohlen zuerst UCSRC und dann UBRRH zu beschreiben...Aber was hat das für den µC für Auswirkungen, da es ja nur ein Fehler des Simulators ist?
Hallo, habe die Reihenfolge in der Initialisierung des UARTS geändert, damit beleibt die Baudrate beim Vorgegebenem Wert. Aber es besteht das Problem, dass ins UDR0 Register nichts geschrieben wird..hmm
> Aber es besteht das Problem, dass ins UDR0 Register nichts geschrieben > wird..hmm Zeigt das AVR_Studio nix an, oder wie ist das gemeint? Das UDR ist ja zwei Register: eins zum senden, eins zum empfangen - da das passende Register dadurch ausgewählt wird, dass gelesen oder geschrieben wird, KANNST du den Wert, den du da grad reingeschrieben hast, NICHT auslesen (Dass der Simulator das auch so anzeigt, ist eben blöd). hth. ?! Jörg
@Jörg: Genau.. Nun, beim Messen an PD1 kommt nichts. Das hängt wahrscheinlich damit zusammen, dass nach 2-Maligem Senden das UDRE0H-Bit gelöscht wird und der Zustand somit in der while-Schleife hängen bleibt, was ich net versteh...
> Nun, beim Messen an PD1 kommt nichts. Verrat doch bitte (endlich) womit du misst. > Das hängt wahrscheinlich damit zusammen, dass nach 2-Maligem Senden das > UDRE0-Bit gelöscht wird das liegt an dem Sendepuffer des ATmega (rtfm ;) ) >und der Zustand somit in der while-Schleife hängen bleibt der bleibt nicht hängen (ok, bei -Os stürzt gerne mal der Simulator ab) das Programm muss nur warten bis die zwei Bytes gesendet wurden (2*10*(1/4800)s, ca 15000! Takte, um genau zu sein) Steht aber alles schon in diesem Thread. hth. Jörg
Hab ein Oszi... Über den Sendepuffer werde ich mich mal schlau machen...was zu tun ist.
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.