Atmega324p Porting

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

So, I may have gotten over eager when I decided to start using the Atmega324p rather than the Atmega32 for a new version of an existing project. The porting is a bit tricky, mostly because of the dual uart. Does anyone know of a uart library code — C preferably — that is ready to handle the newer dual USART Atmega 164/324/644 chips? Or, should I just continue with adding '0' and such to register names?

Julian

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

If you are going for low power sleeping, pin change interrupts, the new watchdog interrupt feature, extra timer0/timer2 copmare outputs or hoping for a longer production life, the 324P is the better choice.

You are probably already aware of this migration document, but I'll point it out just in case:

http://www.atmel.com/dyn/resourc...

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

Quote:

So, I may have gotten over eager when I decided to start using the Atmega324p rather than the Atmega32 for a new version of an existing project.

Shouldn't be a problem. I dropped a '644 into a Mega16 app with very few changes.

Quote:

The porting is a bit tricky, mostly because of the dual uart.

I noticed no difference in actual operation of the '644 USART compared to the '16. I can double-check the changes to the source if you need; let me know.

Quote:

Does anyone know of a uart library code — C preferably — that is ready to handle the newer dual USART Atmega 164/324/644 chips? Or, should I just continue with adding '0' and such to register names?

Now, there are two ways to do this: revise the code as you described, or correct the "root cause".

If you expect the project to live a long time and the '32 version is "dead", then I'd revise the code.

If you want to dual-port the code, or make minimal changes, then attack the root cause: the chip definition file. Atmel with its XMLCONVERT has made provisions for this, giving dual definitions.

What language/tool are you using?

In ports from AT90S4433 to Mega8, I often just made my own definitions of the equivalent register names. But development was "done", and the "project" was just the porting. If new development I clean up and use the new register names.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Quote:

If you are going for low power sleeping, pin change interrupts, the new watchdog interrupt feature, extra timer0/timer2 copmare outputs or hoping for a longer production life, the 324P is the better choice.

You forgot "price". ;)

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I've been using avr-gcc mostly, and avr-libc. I'm definitely convinced the 324P is right — no question.

This may be a question out of laziness, but I'm not normally lazy. I went to recompile my code, changing my defined CPU from atmega32 to atmega324p. When I went to build, I got errors for some unknown registers that have to do with the dual uart. The offending file is from avr-libc's examples — stdiodemo. I've usually in the past just taken the uart.c and uart.h files and put them in my build directory as appropriate. But, it looks like I'll need to go in and do some _simple_ modifications. I was just wondering if anyone had already done that "port" (barely a port.)

Julian

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

Surely the "port" is simply throwing in a handful of '0's into the UART register names isn't it? If it's more than 10 minutes work I'd be very surprised!

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

One other mega32->mega324p porting issue is that you'll likely see some code growth. I have a mega32 application that is about 500 bytes under 30K (the other 2K is used for a bootloader). Compiling for the mega324p produces a bit over 30K of code. From what I can tell so far, the additional code size is due to I/O ports moving out of the range where shorter instructions are supported.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

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

Quote:
Surely the "port" is simply throwing in a handful of '0's into the UART register names isn't it? If it's more than 10 minutes work I'd be very surprised!

Clawson, you're absolutely right regarding the register names. A quick-and-dirty port would be just that, which is in fact what I started doing, no problems. I was only wondering if someone had created, say, a uart class or library on top of the dual uart atmegas. It wasn't really a question out of laziness nor absolute necessity. I just wanted to see if anyone had created any sort of abstraction of dual uart devices already.

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

Have you looked at Peter Fleury's site, at http://homepage.hispeed.ch/peterfleury/index.html, under 'AVR Software'?

I have not tried the UART library itself, but it seem pretty universal. Call uart_xxx() for ATmega UART or UART0, and uart1_xxx() for UART1 on devices which support 2 UARTs. The source files contain a few #ifdef so that it automatically adjust for registers name, making it easy to port between single and dual UART ATmega.

Plus, it have buffered UART communications, using UART interrupts.

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

That's great — that's exactly what I was looking for — thanks a lot!

Julian