Now the USART is working in the right way and now I can comunicate throught the serial port with a PC!
But I still have something a little trouble in my code: in fact when I initialize the USART I set the registers UCSR0B and UCSR0C in this way:
I set TXCIE0, UDRIE0, RXEN0, TXEN0 of the register UCSR0B to enable transmission and reception and the interrupts of data register empty and tx complete. Then I set the UPM01, UCSZ01 and UCSZ0 of the register UCSR0C: in this way I use a legnht of 8 bit, even parity and 1 stop bit.
The trouble is that when microcontroller set the value of UCSR0C, it also sets to ‘1’ the bits of the register UBRR0H (defining the baud rate) in the same position of the bits UCSZ01 and UCS! But I didn’t define an instruction to do so!
The solution is to set the baud rate after setting UCSR0C but can anybody suggest me an explaination of this thing please?
Usually you set the baud rate before turning on the U(S)ART anyway… even the example code in the 128’s datasheet does so. In the 128, the UBBRH and the USCRC register isn’t shared either (it is on other ATMega’s…), so I don’t know why that’s happening.
If you could just send the snippet of assembly/C/whatever you’re using, that would help out.
Here is the code I use to initialize the USART and to write on it the message "ciao ":
#include <stdio.h>
#include <io.h>
#include <ina90.h>
#include <signal.h>
int var;
SIGNAL(SIG_UART0_DATA)
{
switch(var)
{
case 0:
UDR0=99;
break;
case 1:
UDR0=105;
break;
case 2:
UDR0=97;
break;
case 3:
UDR0=111;
break;
case 4:
UDR0=32;
break;
case 5:
UDR0=0;
var=-1
break;
}
var=var+1;
}
main()
{
UCSR0B=120;
UCSR0C=38;
UBRR0L=103;
UBRR0H=0;
_SEI();
for(; ; )
{
}
}
With the initialization of the register in the main the code is working in the right way but as I’ve alreay said, if I set the baud rate before setting UCSR0B and UCSR0C I have troubles with UBRR0H!
U can see this problem if U debug the code with AVR studio.
Well, I can’t explain it, heh. What you’re doing is fine. By looking at the compiled assembly, it’s exactly what you want. I really can’t explain why the 128 is doing that (simulator too)… it says nothing about it in the data sheets that I can find. Even the example code given in the data sheet has that problem (along with improper symbols and opcodes in the assembly… ugh).
I guess just keep it the way you have it. That’s probably not what you wanted for an answer, but I can’t find anything to say why it’s happening.
