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