fivdi
commented
6 years ago I've seen similar issues with serial communication when the internal calibrated RC oscillator is used as a clock source. The the internal calibrated RC oscillator provides an approximate 8.0MHz clock not a precise 8.0MHz clock. It was possible to resolve the issue by tweaking the value in the OSCCAL register which is used to trim the calibrated internal RC oscillator.
If it's any help, I typically use the below program to search for values of OSCCAL that function correctly. The program waits to receive a character from a terminal emulator and depending on the character received it will transmit either 1024, 10240, or 1 character back to the terminal emulator. The program then sends the value of the OSCCAL register in decimal to the terminal emulator. If the value of OSCCAL is good, the characters sent back to the terminal emulator will also be good and display correctly, if not, junk will be displayed. The value of OSCCAL is then decremented by one and the program waits until it received the next character and repeats the above process. Typically I'll just keep hitting the character 't' in the terminal emulator looking for good values for OSCCAL.
#include <avr/io.h>
#include <avr/power.h>
#include <util/delay.h>
#define LED PB0
#define LED_DDR DDRB
#define LED_PORT PORTB
#define USART_BAUDRATE 9600
#define UBRR_VALUE (((F_CPU / (USART_BAUDRATE * 16UL))) - 1)
#define set_bit(sfr, bit) (_SFR_BYTE(sfr) |= (1 << bit))
#define clear_bit(sfr, bit) (_SFR_BYTE(sfr) &= ~(1 << bit))
#define toggle_bit(sfr, bit) (_SFR_BYTE(sfr) ^= (1 << bit))
void usart_init() {
UBRR0 = UBRR_VALUE;
UCSR0B = (1 << RXEN0) | (1 << TXEN0);
UCSR0C = (1 << UCSZ00) | (1 << UCSZ01); // 8 bits, no parity, 1 stop bit
}
void usart_send(uint8_t ch) {
set_bit(LED_PORT, LED);
while (!(UCSR0A & (1 << UDRE0)));
UDR0 = ch;
clear_bit(LED_PORT, LED);
}
uint8_t usart_receive(void) {
while(!(UCSR0A & (1 << RXC0)));
return UDR0;
}
void send_chars(uint16_t count) {
uint8_t ch = 'a';
while (count != 0) {
usart_send(ch);
if (ch == 'z') {
ch = 'a';
} else {
++ch;
}
--count;
}
}
void print_byte(uint8_t byte) {
usart_send('0' + (byte / 100)); /* Hundreds */
usart_send('0' + ((byte / 10) % 10)); /* Tens */
usart_send('0' + (byte % 10)); /* Ones */
}
void send_osccal() {
usart_send(' ');
usart_send('(');
print_byte(OSCCAL);
usart_send(')');
usart_send(' ');
}
int main(void) {
clock_prescale_set(clock_div_1); // 8Mhz clock
usart_init();
set_bit(LED_DDR, LED); // set LED pin for output
while (1) {
uint8_t command = usart_receive();
switch (command) {
case 'o':
send_chars(1024);
send_osccal();
break;
case 't':
send_chars(10240);
send_osccal();
break;
case 'b':
default:
usart_send(command);
send_osccal();
break;
}
OSCCAL -= 1;
}
}
Folkert-2
travisgillespie
Testing serial loopback with the listing in Example 5.1 results in "strange" characters being returned. Entering "a" results in the following LED pattern: 01001111, which is capital "O". Typing "c" for example results in LED pattern 01001110, which is capital "N". The message "hello World" is displayed as ú‹…m:ºê+ë. When connecting USB-serial converter Rx and Tx, characters are returned correctly. The program was successfully flashed into an Atmega 168. I have no idea where to start looking for possible causes. Any ideas from your side? Thanks in advance, Folkert