Atmega168 UART weird character

AthulSNair · September 5, 2018, 7:52pm

I'm learning AVR programming using this book

I was able to run and get output using the code provided along with the book. I use Proteus to simulate the output since I don't have controller in hand.

Today I tried to write a simple uart program by referring data sheet.

/*
 * uart.c
 *
 * Created: 05-09-2018 09:55:36 PM
 * Author : New User
 */ 

#include <avr/io.h>
#include <util/delay.h>

int main(void)
{
    UCSR0B = (1 << RXEN0) | (1 << TXEN0);
    UCSR0C = (1 << UCSZ01) | (1 << UCSZ02);                       
    UBRR0L = 6;
    char data;
    while (1) 
    {
        while (!(UCSR0A & (1<<RXC0)));
        data = UDR0;
        while (!(UCSR0A & (1<<UDRE0)));
        UDR0 = data;

    }
}

When I simulate code in Proteus I get weird characters in virtual terminal.

First thought it might be due to error in baud rate.

As my understanding default F_CPU of Atmega168 is 1MHz if I don't use any external crystal oscillator. So for a baudrate 9600 U0BRR = 6 from this equation

U0BRR = (F_CPU/(16 * 9600)) - 1 = (1000000/16*9600)-1 = 5.51 ~6
Also in the datasheet, U0BRR is 6 for a baud rate 9600 for 1MHz clock

So what's happening here??

IDE: AtmelStudio 7

I've attached my my Proteus settings

Is there anything i should change in Proteus??

I have an arduino(ATMEGA328), and after some search I found out same code works on both controllers. Changed UBRR0L to 103 for 16MHz. Also tried with changing F_CPU to 16000000UL. Not working there too.

system · September 5, 2018, 8:34pm

(deleted)

AthulSNair · September 6, 2018, 4:56am

I used Arduino to compile the code and tried it with arduino uno board too

Budvar10 · September 6, 2018, 5:02am

Just after brief look, it seems like incorrect baud rate. I think, you missed to set the UBRR0H - see the example in the datatsheet.

ron_sutherland · September 7, 2018, 2:19am

@AthulSNair, I think you're on the right path, it will have some pain. Don't fear taking parts from the Arduino core, but the uart is probably not a good one to look at. There are many AVR examples to look at and a few work well, I weaved a few parts from various places into this:

github.com

epccs/RPUno/blob/master/lib/uart.c

/*
    AVR Interrupt-Driven UART with stdio redirect
    Copyright (C) 2019 Ronald Sutherland

    This library is free software; you can redistribute it and/or
    modify it under the terms of the GNU Lesser General Public
    License as published by the Free Software Foundation; either
    version 2.1 of the License, or (at your option) any later version.

    This library is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
    Lesser General Public License for more details.

    You should have received a copy of the GNU Lesser General Public
    License along with this library; if not, write to the Free Software
    Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA

    Hacked from UART library by Andy Gock
    https://github.com/andygock/avr-uart

This file has been truncated. show original

Probably the coolest part was figuring out streams so it could be passed into the stdout and stdin and then used with avr-libc stdio library sort of like found in Unix/Linux (e.g. libc and the updated version newlib).

github.com

epccs/RPUno/blob/028b808fae9b6b1022a0e60a702f900a3815a00d/Uart/main.c#L54


      
          
          
void setup(void) 
          {
              pinMode(STATUS_LED,OUTPUT);
              digitalWrite(STATUS_LED,HIGH);
              
              //Timer0 Fast PWM mode, Timer1 & Timer2 Phase Correct PWM mode.
              initTimers(); 
          
          
    /* Initialize UART, it returns a pointer to FILE so redirect of stdin and stdout works*/
              stdout = stdin = uartstream0_init(BAUD);
              
              /* Initialize I2C, with the internal pull-up*/
              twi_init(TWI_PULLUP);
          
          
    /* Clear and setup the command buffer, (probably not needed at this point) */
              initCommandBuffer();
          
          
    // Enable global interrupts to start TIMER0 and UART
              sei();

The end result is printf("hello world\n") works as expected. Also getchar(), which takes a single byte from the stream buffer.

github.com

epccs/RPUno/blob/028b808fae9b6b1022a0e60a702f900a3815a00d/Uart/main.c#L103


      
          
          
while(1) 
          {
              // use STATUS_LED to show if I2C has a bus manager
              blink();
              
              // check if character is available to assemble a command, e.g. non-blocking
              if ( (!command_done) && uart0_available() ) // command_done is an extern from parse.h
              {
                  // get a character from stdin and use it to assemble a command
                  AssembleCommand(getchar());
          
          
        // address is a char e.g. the ascii value for '0' warning: a null will terminate the command string. 
                  StartEchoWhenAddressed(rpu_addr);
              }
              
              // check if the character is available, and if so stop transmit and the command in process.
              // a multi-drop bus can have another device start transmitting after the second received byte so
              // there is little time to detect a possible collision
              if ( command_done && uart0_available() )
              {

The Standard IO facilities is a gold mine after you get it to work.

https://www.nongnu.org/avr-libc/user-manual/group__avr__stdio.html

westfw · September 7, 2018, 5:07am

I experimented (on an actual Uno, with 16MHz clock, and UBRR0L = 103), and I had a lot of trouble getting it to work, too.

The code mostly looks pretty correct (see below.)

I discovered a couple of interesting things:

While it looks like a bitrate problem, SOME of the characters echoed correctly. If I sent "abcd", I got back "ybc" ... that's weird.

is incorrect. UCSZ02 is actually off in UCSR0B. Here, there should be USCZ00 (UCSZ02 should default to 0, which is the value you want, so you don't actually need to set it.

I COULD get it to work by adding:

UCSR0A = 0;

To the initialization code. I don't have any current theory as to why this helps, except a vague though that perhaps the received data is "out-of-sync" with the transmitted data (send 'a', get some trash that was already in the buffer. Except this doesn't hold up very well.)

ron_sutherland · September 7, 2018, 6:20am

That reminds me of the startup glitch someone alerted me to and I verified some time back.

github.com

epccs/RPUadpt/blob/aebc0e0627ad6e882028a058d71446a7d50f9330/Remote/main.c#L351


      
          digitalWrite(HOST_nDSR, HIGH);
          pinMode(RX_DE, OUTPUT);
          digitalWrite(RX_DE, HIGH);  // allow RX pair driver to enable if FTDI_TX is low
          pinMode(RX_nRE, OUTPUT);
          digitalWrite(RX_nRE, LOW);  // enable RX pair recevior to output to local MCU's RX input
          pinMode(TX_DE, OUTPUT);
          digitalWrite(TX_DE, HIGH); // allow TX pair driver to enable if TX (from MCU) is low
          pinMode(TX_nRE, OUTPUT);
          digitalWrite(TX_nRE, LOW);  // enable TX pair recevior to output to FTDI_RX input
          pinMode(DTR_DE, OUTPUT);
          digitalWrite(DTR_DE, LOW);  // seems to be a startup glitch ??? so disallow DTR pair driver to enable if DTR_TXD is low
          pinMode(nSS, OUTPUT); // nSS is input to a Open collector buffer used to pull to MCU nRESET low
          digitalWrite(nSS, HIGH); 
          pinMode(SHUTDOWN, INPUT);
          digitalWrite(SHUTDOWN, HIGH); // trun on a weak pullup 
          
          
bootloader_address = RPU_HOST_CONNECT; 
          host_active = 0;
          lockout_active = 0;
          status_byt = 0;
          write_rpu_address_to_eeprom = 0;

Optiboot seems to deal with it, no clue how, but when I turn on the UART (without optiboot) it glitches the TX line. The board I have linked to has a transceiver that I disable before turning on the UART so the glitch does not get into the communication channel.

update: so I'll try to fix it as westfw has shown

Budvar10 · September 7, 2018, 7:19am

Does it have something to do with error (-7% for 1MHz, 9600baud, U2X=0) ?

westfw · September 7, 2018, 8:27am

(-7% for 1MHz}

Well, not for the experiments at 16MHz...
(with U2X, error for 9600 at 1MHz goes down to .1% !)

Topic		Replies	Views
atmega168p usart interrupt Programming	1	916	May 5, 2021
Atmega Serial Print not working properly 3rd Party Boards	19	736	July 4, 2023
Mega2560 R3 USB Serial Baud - Bare Metal Networking, Protocols, and Devices	7	1763	May 6, 2021
Help with custom UART initialization Programming	18	3827	May 5, 2021
atmeag 164p uart/usart problems 3rd Party Boards	1	558	May 6, 2021

Atmega168 UART weird character

Related topics