Atmega8 USART Problem

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello Guys, 

I have a problem doing serial comunication with my computer.

I'm using a atmega8 @16MHZ and Baud rate at 9600 and this is the code

/* Created: 26/09/2017 11:58:03
 * Author : Eduardo Pilar
 */
 // Atmega 8, @16Mhz

#include <avr/interrupt.h>
#include <stdio.h>
#ifndef F_CPU
#define F_CPU 16000000UL
#endif
#include <util/delay.h>
#define USART_BAUDRATE 9600
#define BAUD_PRESCALER ((F_CPU) / (USART_BAUDRATE * 16UL)-1)

void initUSART(void)
{

	UBRRH=(BAUD_PRESCALER>>8);
	UBRRL= BAUD_PRESCALER; //set baud rate  9600
	UCSRA=0x00;
	UCSRB=(1<<RXEN)|(1<<TXEN); // enable tx and rx
	UCSRC=(1<<URSEL)|(1<<UCSZ0)|(1<<UCSZ1); // 1 stops bit, 8 bit data

}

unsigned char receiveusart(void)
{
	while(!(UCSRA&(1<<RXC)));
	return UDR;

}

void send_usart (unsigned char data)
{
	while(!(UCSRA & (1<<UDRE)));
	UDR = data;
}

int main(void)
{

	initUSART();

    while (1)
    { 

		send_usart('d'); //seend caracter d
		_delay_ms(100);

	}

}

 

 

When i run the program in atmelStudio simulator i don´t see any change in the UDR register and in the UCSRC. When i connect to realterm, i only see 00000 at the screen.

 

If someone can help me i appreciate!

This topic has a solution.
Last Edited: Tue. Oct 24, 2017 - 09:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can't see either UDR or UCSRC in the simulator. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

thank you for the information, but the program is correct? because when i send the data to pc i only see 000 at realterm.

cheers

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah the code looks fine. You don't need to bother writing UCSRC as 8N1 is the power on default anyway. But I guess it doesn't hurt to write it anyway?

 

BTW see #3 in my signature. My guess is that the AVR is not running at 16MHz as the code has been written to expect.

 

Start by flashing an LED or something like that with just a _delay_ms() loop. If you say it is 16MHz and use a _delay_ms(1000) (for example) and it actually takes 16 seconds to flash then the AVR is running at 1MHz not 16MHz.

 

If you think it is 16MHz what is your clock circuit and how have you set the CKSEL and SUT fuses?

 

BTW:

#define BAUD_PRESCALER ((F_CPU) / (USART_BAUDRATE * 16UL)-1)

That looks "curious". I would have to check order of precedence but to be sure I might go with:

#define BAUD_PRESCALER ((F_CPU / (USART_BAUDRATE * 16UL)) - 1)

to emphasize that the -1 is the last thing to be done.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I put now the correct Fuses and the mirco work at 16mhz, and is show correctly! 

Thank you very much!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wonder if we'll ever hear from the other 0.1% from #3 ?? ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

99% of my troubles with UART come from my forgetting to connect Rx to Tx (hardware seems very solid)

1% came from my using RPi : maximum speed is 115 200 bauds , energia can go up to ca 2E6 bauds and PC can receive at these rates (I doubt avrs can do)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

docasbb wrote:
 is show correctly! 

Excelent! Now please mark the solution: http://www.avrfreaks.net/comment...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dbrion0606 wrote:

99% of my troubles with UART come from my forgetting to connect Rx to Tx (hardware seems very solid)

1% came from my using RPi : maximum speed is 115 200 bauds , energia can go up to ca 2E6 bauds and PC can receive at these rates (I doubt avrs can do)

 

Sure they can!  At 16 Mhz they top out @ 2 MBaud.  At 20 Mhz, the upper limit is 2.5E6

 

Of course there's the issue of dealing with incoming data that fast - which might have been what you doubt.  I have an audio project I've been working on designed around 1.25MBaud, which I had working well on an ATMega8 (It's been moved to an XMEGA).  Just to test the limits I pushed it up to 2 Mbaud.  It worked fine until I started adding some complexity into protocol handling.  At 2 MBaud, you get approximately 80 cycles (assuming 8N1) to deal with the incoming data.  Assuming 2 cycles per instruction, you get 40 instructions, minus interrupt or polling overhead...  It does get tight.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Incoming data are usually very short (typically, PC/RPi/nanopi sends a character -start sending data/save confi g into EEPROM- or a configuration string -sampling rate should be xxx).

RPi/nanopi cannot handle baudrates above 115200 bauds. PC can go much higher -and handle them-.

The other way round, as you did (avr receiving a lot of data) : I never dared... (from what I read from you, I have not the skills and if needed, I would use faster uC -room is left fot total lack of optimizing skills-  :  Texas lm4f + energia and stm32xxx become difficult to find; I shall try next month Arduino Due -can sample ca 100 times faster than avr (no need for very fast transmitting baud rates, if one slowly pickups values ) on the ADC; has two DACs-.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dbrion0606 wrote:
RPi/nanopi cannot handle baudrates above 115200 bauds. 

Really?

 

surprise

 

now I shall have to find one and try it ...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not really:

I discarded solutions https://raspberrypi.stackexchange.com/questions/1094/how-can-i-set-the-uart-speed

because :

they need to edit config fles, which is typo prone, and I have many disks (halting, changing a SD "disk" and rebooting is faster than editing config files...). As I just needed for a kind of oscilloscope, and did not need each and every data (Atduino's DAC is slow enough to cope with a slow serial line; arm's DACs are very fast; my eyes, optical nerve and maybe be brain are very slow), I can live with this slow line....