Mahlzeit!
Ich habe hier folgenden Code, um ein paar Bytes (0..8) über die
serielle Schnittstelle zu schicken.
Der Controller ist ATMega162. Programmiert ist das mit dem avrgcc
Das Problem an der Sache ist, beim Empfänger kommt nur 0x00 an. Die
Anzahl stimmt, aber der Inhalt ist falsch.
Die Bytes (momentan Testweise durch 0xFF ersetzt,) sollen periodisch
übertragen werden, bis sich die Gegenseite meldet.
Kann mir bitte jemand sagen, wieso da nur 0x00 übertragen wird?
Vielen Dank im Vorraus
Rahul
UBRR1H = (unsigned char) (ubrval >> 8);
UBRR1L = (unsigned char) ubrval;
UCSR1B = ((1<<RXEN1) | (1<< RXCIE1) | (1<<TXEN1));
UCSR1C = ((1<<UCSZ11) | (1<<UCSZ10));
do
{
// LED togglen
if ((PORTD & rot) == rot)
{
PORTD &= ~rot;
}
else
{
PORTD |= rot;
}
for(i=0;i<=8;i++)
{
while (!(UCSR1A & (1<<UDRE1)));
UDR1 = 0xFF; // SendBuffer[i];
}
for(i=0;i<255;i++)
for(j=0;j<100;j++)
for(k=0;k<20;k++);
}
while (ComplMsg !=0xFF);
Im Datenblatt steht dieses als Beispiel-C-Code:
void USART_Transmit( unsigned char data )
{
/* Wait for empty transmit buffer */
while ( !( UCSRA & (1<<UDRE)) )
;
/* Put data into buffer, sends the data */
UDR = data;
}
Gast
#229759
Bitratenproblem?
@Simon: Was soll mir das sagen? Der ATMEGA162 besitzt 2 USARTS (USART0 und USART1), entsprechend also auch viele Register. #define fosc 3686411 // 3,686MHz #define ubrval (fosc/(16L*baud))-1 ubrval ist 23. Das Bitratenproblem kommt auch IMHO nicht hin, da ja die richtige Anzahl übertragen wird, und auch immer das gleiche.
Gast
#229761
Wenn Bitrate Empfänger = 10fach Bitrate Sender, und der Sender stets 0xFF überträgt, kommt's hin. Zugegebermassen ein extremer Fall.
Gast
#229762
Ich hatte mal den Fall, das der interne RC Oszillator schneller schwing als angegeben (4,2 MHz statt 4MHz). Dadurch kam nur Müll oder halt nichts an, so wie bei dir. Probier mal einen externen Quarz, falls du nich schon einen dran hängen hast. Ciao Marcel...
Gast
#229763
Der Controller steckt im STK500. Die andere Seite ist ein PC. Mit einem anderen Programm im gleichen Controller funktioniert der Aufbau... Ich werde da wohl ne Nacht drüber schlafen. Gruß Rahul
Gast
#229764
Mit welcher Software empfängst du denn dein Gesendetes? Vielleicht hast du ja nur übersehen, daß "00" und "FF" nicht unbedingt darstellbare Zeichen im ASCII-Code sind...
Das Programm nennt sich COMTEST von B&B-Electronics. Das zeigt "nicht darstellbare" Zeichen in spitzen Klammern als HEX-Wert an. DAran kann es nicht liegen. Ich werde mir das Programm bei nächster Gelegenheit angucken. Erst mal ne Nacht drüber schlafen, nach Hamburg ins Miwula fahren und dann irgendwann noch mal gucken...
Es hat mich gewurmt. Aber, es funktioniert. Und wie immer ist das Datenblatt dein Freund. Atmel hat in seinen USART-Beispielen ganz wunderbar aufgeführt, welche Bits gesetzt werden müssen. Ich hatte das URSEL-Bit vergessen. Damit unterscheidet der Controller zwischen dem UCSRC- und dem UBRRH-Register. Jetzt läuft zumindest die Initialisierung... Auch wenn ich alleine draufgekommen bin, danke ich euch für die Hilfe. Gruß Rahul
Gast
#229767
Stimmt, von Prozessor zu Prozessor kann´s da schonmal diverse Unterschiede geben. Deshalb ist es immer recht sicher, bei Fragen genau das zu checken, was in dem Datenblatt des einen Prozessors steht, den man gerade benutzt. Sind nicht alle gleich.... ist mir anfangs auch passiert, jetzt gucke ich vor ´jedem Programmierproblem lieber nochmal nach, weil alles kann man sich einfach nicht merken.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.