ATMEGA 8515 USART

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

i AM USING atmega8515. I have written a code for USART implementation. baud rate =2400,no parity, i stop bit & 8 data bits. I use STK500 board. On the hyper terminal I am getting stange charecters . I have tried to chaNge the BAUD RATE = 9600. still I get the stange charecters. Here is my implementation.
Is somthing wrong in my code. I would be happy if someone help me.

[code]}

Last Edited: Mon. May 23, 2011 - 06:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
On the hyper terminal I am getting stange charecters .
Which means that your baud rate is off. What is F_CPU set to, and is that the frequency that the AVR is really running at?

Regards,
Steve A.

The Board helps those that help themselves.

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

Where are you defining F_CPU?
If you're compiling from AVR studio, make sure you declare the actual frequency your AVR is running at, as part of your project options.

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

Koshchi wrote:
Quote:
On the hyper terminal I am getting stange charecters .
Which means that your baud rate is off. What is F_CPU set to, and is that the frequency that the AVR is really running at?

I have set the F_CPU = 8000000Hz, in the project configurations options.

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

Quote:
I have set the F_CPU = 8000000Hz, in the project configurations options.
But is that what the AVR is really running at? (HINT: If you haven't changed any fuses, you are running at 1MHz).

Regards,
Steve A.

The Board helps those that help themselves.

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

Koshchi wrote:
Quote:
I have set the F_CPU = 8000000Hz, in the project configurations options.
But is that what the AVR is really running at? (HINT: If you haven't changed any fuses, you are running at 1MHz).

thanks for yur reply.I didnot change your fuse settings. I changed the F_CPU = 1000000. it is kind of working . Here is my output , i tried to type a to z & 1 to 9.But it looks like for some input , it is not receiving the samecharecter. When I press the enter key, I get stange output. Should i have to change the fuse settings?

}bcdefglmjklmno|}rstuvw|}z=234567<=

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

The internal oscillator of an AVR can be off by as much as 10%. RS232 requires accuracy within 2%.

Regards,
Steve A.

The Board helps those that help themselves.

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

Try putting a short delay between each call to tx(), say 1ms and see if that fixes it. If the RC is off frequency that gap between characters will allow the UARTs to sync up again.

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

As stated above, the uC runs at 1 MHz on an internal oscillator, UNLESS you chane the FUSE SETTINGS to make it run on something else, (like an externally connected crystal).

Your code needs to match the physical device. Putting 8000000 Hz into your code will NOT make the uC run at that speed.

Recompile your code with the code saying the clock is 1000000 Hz (1 MHz), and see if that makes it work.

JC

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

DocJC wrote:
As stated above, the uC runs at 1 MHz on an internal oscillator, UNLESS you chane the FUSE SETTINGS to make it run on something else, (like an externally connected crystal).

Your code needs to match the physical device. Putting 8000000 Hz into your code will NOT make the uC run at that speed.

Recompile your code with the code saying the clock is 1000000 Hz (1 MHz), and see if that makes it work.

JC

I recompiled my code with 1MHZ now. In my hyper terminal I can see the letter which i type. But , for some charecters I get , some other charecter.

when i type a, it is echoed as {. for h ==.

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

For accuracy put a crystal in the design. If UART is a major part of the design then pick one of the UART friendly "magic" crystals - that is those that have a frequency multiple of 300Hz. (1.8432MHz, 3.6864MHz etc.)

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

The internal RC oscillator can be off by 10%. Serial comms needs < 2%. 3% off at 1MHz is 3% off. 3% off at 8MHz is 8MHz off. Either read the chapter in the datasheet about how to cal the internal oscillator, or get a crystal and change the fuses to run from the crystal. (Might sink in if half dozen people tell the same story).

Imagecraft compiler user

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

I am trying to implement the USART driver code.
I don't use the header file. I created my own header file here, to use the USART reg. For some reason it is not working. I dont see any charecter in my hyper terminal. I use the same data format , which i used earlier. 1MHZ, 2400 baud rate, 8 data bit, no parity, 1 stop bit.

I tried to display the USART register values,just to make sure init is fine. UCSRC value is zero. But it is supposed to be 0x86.When i debug through simulator, all the register values are perfect. What's getting wrong? Any help? I am really stressed out with USART.
[code]

Last Edited: Mon. May 23, 2011 - 06:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The avr/io.h file has some clever way of reading in the atmel io definition file for the device specified in the project. If you don't have the correct avr type the UDR will be at the wrong address or some problem like that.

Imagecraft compiler user

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

I ran into compiler warnings:

'USART_RXC_vect' appears to be a misspelled signal handler

warning: 'USART_RX_vect' appears to be a misspelled signal handler

in winavr 20070525

I then checked the io8515.h, sure enough, the vector listing is as following:

/* UART, Rx Complete */

#define UART_RX_vect _VECTOR(9)

#define SIG_UART_RECV _VECTOR(9)

/* UART Data Register Empty */

#define UART_UDRE_vect _VECTOR(10)

#define SIG_UART_DATA _VECTOR(10)

/* UART, Tx Complete */

#define UART_TX_vect _VECTOR(11)

#define SIG_UART_TRANS _VECTOR(11)

What do i need ot do to fix this error?Anyhelp

bobgardner wrote:
The avr/io.h file has some clever way of reading in the atmel io definition file for the device specified in the project. If you don't have the correct avr type the UDR will be at the wrong address or some problem like that.

Last Edited: Mon. May 23, 2011 - 06:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for pointing it. Now I have changed the reading & writing to UDR like this. But still I am not
getting any charecter on my hyper terminal. Any help?

way of reading in the atmel io definition file for the device specified in the project. If you don't have the correct avr type the UDR will be at the wrong address or some problem like that.

[/code]

Last Edited: Mon. May 23, 2011 - 06:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You seem to be suffering from a severe case of not reading the user manual. While there is a copy online:

http://www.nongnu.org/avr-libc/u...

that is for a much later version - WinAVR will have installed a copy that matches what you are using in \Winavr\doc\avr-libc. Suggest you read it as it has the answers for everything you have asked so far.

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

I couldn't understand what did you ask me to read?
I would be happy , if you clarify my doubts

clawson wrote:
You seem to be suffering from a severe case of not reading the user manual. While there is a copy online:

http://www.nongnu.org/avr-libc/u...

that is for a much later version - WinAVR will have installed a copy that matches what you are using in \Winavr\doc\avr-libc. Suggest you read it as it has the answers for everything you have asked so far.

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

Quote:

I ran into compiler warnings:

'USART_RXC_vect' appears to be a misspelled signal handler

warning: 'USART_RX_vect' appears to be a misspelled signal handler

in winavr 20070525

I then checked the io8515.h, sure enough, the vector listing is as following:
[...]
#define UART_RX_vect _VECTOR(9)
[...]
What do i need ot do to fix this error?


Spell the vector name correctly. Last time I checked "USART_RXC_vect" and "UART_RX_vect" was different.. :wink:

Quote:
I don't use the header file

Why on earth do you not use , the "entry point" to an include hierarchy that will make you as device-independent as you can be with the effort only being doing that include and making sure the cimpiler gets the AVR model through the -mmcu option (which e.g. AVR Studio does excellently. And the Mfile utility, if you're into honing your own makefiles.)? Why in any $DEITY's name not use it? What can you possibly gain in doing the part-definition work again, and tying yourself very much harder to a specific device..? :roll:

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Thu. May 12, 2011 - 04:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, list of interrupt vector names here (to avoid the mispelled error):

http://www.nongnu.org/avr-libc/u...

Use of streams here (for UART as well as LCD):

http://www.nongnu.org/avr-libc/u...

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

I tried both. It is still giving the same error.Should I need to update my winavr?

JohanEkdahl wrote:
Quote:

I ran into compiler warnings:

'USART_RXC_vect' appears to be a misspelled signal handler

warning: 'USART_RX_vect' appears to be a misspelled signal handler

in winavr 20070525

I then checked the io8515.h, sure enough, the vector listing is as following:
[...]
#define UART_RX_vect _VECTOR(9)
[...]
What do i need ot do to fix this error?


Spell the vector name correctly. Last time I checked "USART_RXC_vect" and "UART_RX_vect" was different.. :wink:

Quote:
I don't use the header file

Why on earth do you not use , the "entry point" to an include hierarchy that will make you as device-independent as you can be with the effort only being doing that include and making sure the cimpiler gets the AVR model through the -mmcu option (which e.g. AVR Studio does excellently. And the Mfile utility, if you're into honing your own makefiles.)? Why in any $DEITY's name not use it? What can you possibly gain in doing the part-definition work again, and tying yourself very much harder to a specific device..? :roll:

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

I tried to look into INT VECTORS for atmega8515. I used USART_RX_vect, USART_RXC_vect, it is still giving the same misspelled handler error.

clawson wrote:
OK, list of interrupt vector names here (to avoid the mispelled error):

http://www.nongnu.org/avr-libc/u...

Use of streams here (for UART as well as LCD):

http://www.nongnu.org/avr-libc/u...

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

I am trying to implement the USART driver code.
I don't use the header file. I created my own header file here, to use the USART reg. For some reason it is not working. I dont see any charecter in my hyper terminal. I use the same data format , which i used earlier. 1MHZ, 2400 baud rate, 8 data bit, no parity, 1 stop bit.

I tried to display the USART register values,just to make sure init is fine. UCSRC value is zero. But it is supposed to be 0x86.When i debug through simulator, all the register values are perfect. What's getting wrong? Any help? I am really stressed out with USART.

[/code]volatile uint8_t ubrrh, val, p, q, r, s;

void serilInit(void)
{

ubrrh = UBRR_VALUE >> 8;

writetoport(UBRRH, ubrrh);

writetoport(UBRRL, UBRR_VALUE);

writetoport(UCSRC, 0X86);
val = readfromport(UCSRC);
writetoport(LEDS, val); // it is supposed to glow the LEDS(0X86), but it seems like all the LEDS(0x00) are glowing

writetoport(UCSRB, UCSRB_VAL);

writetoport(UCSRA, 0);

}

Last Edited: Mon. May 23, 2011 - 06:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I don't use the header file. I created my own header file here, to use the USART reg.

Yes, you've already told us so, but WHY?

Quote:

I used USART_RX_vect, USART_RXC_vect

Look again in the definition file for your AVR. And look again in the documentation. I still think you are spelling them wrong. Make sure you are actually chacking agains entries in the table that are for ATmega8515. Make sure you then check the exact spelling. Letter for letter. Including any occurrence or not of the letter 'S'...

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Quote:

Yes, you've already told us so, but WHY?

To ensure that no one else can help? I downloaded the Studio project but it just seems like utter madness to have locally redefined the contents of (well just PORT and UART in fact). Also there's a local interrupt.h that (in part) duplicates , it's like a lesson in how not to write code! Even the way the PORTB (etc) are defined means they cannot be used as:

PORTB = 0x55;

as this compiles as:

0X18 = 0x55;

There's even a types.h which makes a half hearted attempt to duplicate but using #define's rather than typedefs?

What I don't get is a "mispelled vector" error using the code though?

In the code I see things like:

	while(TIFR == 1);

but because of:

#define TIFR     0x38

that says:

	while(0x38 == 1);

which is the same as:

	while(0);

In short the program appears to be a complete waste of time. I'd just start over using standard header files.

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

Thanks for your reply. I have implemented a USART ofatmega8515 . I use UART_RX_vect. serialInit is fine. But for some reason, it is not calling the INT routine.
F_CPU is 1MHZ. baud rate = 2400, 8 data bit, 1 stop bit, no partiy. I have been trying it, I couldn't find where the bug is ? any help?

The same code with avr/io.h, avr/interrupt.h it is just working fine.

JohanEkdahl wrote:
Quote:

I ran into compiler warnings:

'USART_RXC_vect' appears to be a misspelled signal handler

warning: 'USART_RX_vect' appears to be a misspelled signal handler

in winavr 20070525

I then checked the io8515.h, sure enough, the vector listing is as following:
[...]
#define UART_RX_vect _VECTOR(9)
[...]
What do i need ot do to fix this error?


Spell the vector name correctly. Last time I checked "USART_RXC_vect" and "UART_RX_vect" was different.. :wink:

Quote:
I don't use the header file

Why on earth do you not use , the "entry point" to an include hierarchy that will make you as device-independent as you can be with the effort only being doing that include and making sure the cimpiler gets the AVR model through the -mmcu option (which e.g. AVR Studio does excellently. And the Mfile utility, if you're into honing your own makefiles.)? Why in any $DEITY's name not use it? What can you possibly gain in doing the part-definition work again, and tying yourself very much harder to a specific device..? :roll:

Last Edited: Mon. May 23, 2011 - 06:15 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
The same code with avr/io.h, avr/interrupt.h it is just working fine.
Then why are you not using them?

Regards,
Steve A.

The Board helps those that help themselves.

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

TRYING to write compiler independent code.

Koshchi wrote:
Quote:
The same code with avr/io.h, avr/interrupt.h it is just working fine.
Then why are you not using them?

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

Quote:

TRYING to write compiler independent code.

All the AVR compilers provide PORTB, DDRD, etc. so you don't need to break those out to local definitions. (but if you were going to I think I'd go with Xmega like struct{} access if I were you).

The one thing that is tied to the compiler is the ISR syntax though several threads here have provided suggested macro wrappers which can adapt to the five or so different AVR C compilers.

BTW perhaps you can explain - I've never understood the fascination with multi-compiler support (unless you are doing something like writing app notes as Atmel does). Surely most people buy one AVR compiler and continue to use just that unless something disastorous happens?

BTW I downloaded your latest .zip and built it in Studio. So what's supposed to be wrong?

Also your "compiler independent" headers contain:

extern void __vector_9 (void) __attribute__ ((interrupt)); /* interrupt is disabled at initialization */
extern void __vector_10 (void) __attribute__ ((interrupt)); /* interrupt is disabled at initialization */

Exactly what is compiler independent about that then ?!?