ATmega16/ATMega32 (ASM) plug'n'play

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

I am developing for a ATMega32 target, but don't have any of them at the moment, so am using ATMega16.

I'd like the code to be invariant of the target at this stage (ie when flash, ram and eeprom are within the bounds of the ATMega16 limits), but I've noticed at least one potential gotcha - the interrupt vector table, whilst having the same interrupts and the same size, is arranged differently!

So, two questions:
- are there any other potential gotchas?
- what's the ASM trick to have invariant code that runs all the interrupts properly no matter whether it's deployed to ATmega16 or ATMega32?

TIA, Martin

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

Conditional assembly. Use two interrupt vector tables enclosed in .if .else .endif blocks. I don't know offhand what the test is for processor type, but it should be easy to find.

Jim

Your message here - reasonable rates.

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

Quote:

- are there any other potential gotchas?

Atmel's app note AVR089: Migrating between ATmega16 and ATmega32 . Only 3 pages; probably not much there.

You can't take full advantage of the Mega32 with twice the SRAM if you use the conventional stack location of "RAMEND".

Quote:

- what's the ASM trick to have invariant code that runs all the interrupts properly no matter whether it's deployed to ATmega16 or ATMega32?

I don't know whether I would strive for your stated goal. Rather, I'd try to isolate the differences into a pair of include files for the two configurations.

Besides the vector table and mentioned RAMEND, I don't think that the I/O maps are identical so you need to use the proper chip include file if that is so.

I haven't used AVRASM2 much, but I believe that it has some conditional compilation ("preprocessor") capabilities so you could conditionally assemble chunks like the vector table based on the processor type of the target.

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

With ImageCraft ICCAVR V7.xx you can do the following:

/****************************************************************************/	 
// Timer 1 Output Compare Register 1A, OCR1A intrrupt vector.
#ifdef __iom8535v_h
#pragma interrupt_handler Stepping_IRQ:7
#endif __iom8535v_h

#ifdef __iom16v_h
#pragma interrupt_handler Stepping_IRQ:8
#endif __iom16v_h

#ifdef __iom32v_h
#pragma interrupt_handler Stepping_IRQ:8
#endif __iom32v_h

#ifdef __iom64v_h
#pragma interrupt_handler Stepping_IRQ:13
#endif __iom64v_h

#ifdef __iom128v_h
#pragma interrupt_handler Stepping_IRQ:13
#endif __iom128v_h

/****************************************************************************/	 
// Timer 1 Output Compare Register, OCR1B intrrupt vector.
#ifdef __iom8535v_h
#pragma interrupt_handler ACC_DEC_IRQ:8
#endif __iom8535v_h

#ifdef __iom16v_h
#pragma interrupt_handler ACC_DEC_IRQ:9
#endif __iom16v_h

#ifdef __iom32v_h
#pragma interrupt_handler ACC_DEC_IRQ:9
#endif __iom32v_h

#ifdef __iom64v_h
#pragma interrupt_handler ACC_DEC_IRQ:14
#endif __iom64v_h

#ifdef __iom128v_h
#pragma interrupt_handler ACC_DEC_IRQ:14
#endif __iom128v_h

By changing:

/*************************************************************/
// Standard C library Includes
#include 
#include 
#include 
#include 
#include 

to say:

/*************************************************************/
// Standard C library Includes
#include 
#include 
#include 
#include 
#include 

I can change from the Mega8535 AVR, Mega16/32 AVR and Mega64/128 AVR flavors, simply by making this little change at the beginning of the program.

Of course, while writing the program, you will have to keep in mind any future use of AVR flavors and be thinking about the hardware and software differences between them and the conditionals that will be required to make the jump from AVR flavor to AVR flavor.

As I didn't see where you specified any particular language, I'm sure that there is some method of doing this same thing in assembley language. I don't use assembley much so I wouldn't know the proper syntax or methods unless I got the assembley manual out. It seems that back when I did look assembley language for the AVR, macros an conditional assembley was covered very well.

Also, if using C, with ImageCraft ICCAVR V7.xx anyway, you will have to have several versions of putchar() and getchar() because the Mega16 and Mega32 only employ one USART while, the Mega64 and Mega128 employ two USARTS. The putchar() and getchar() functions for the Mega64 and Mega128 devices will have to differentiate between USART0 and USART1. You can do this as well, with contitional statements as shown above.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

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

Jim

<<Conditional assembly. Use two interrupt vector tables...>> Thanks, I've investigated and found the following technique I could modify and use to define two different interrupt vector tables at the start of the code.

#define ATMega16
#ifdef ATMega16
.include "m16def.inc"
#else
.include "m32def.inc"
#endif

Still means I have to set the correct #define, compile the code and then download it to the right target device. I was really looking for techniques that mean I compile the code once and it doesn't matter which target I download it to.

I guess I was looking for something in the run time environment ie inside the AVR, that I can query to find out the AVR type. The signature bytes seem a potential, but I can't work out where to read them from - datasheet just says they are in a 'separate address space'. The fabled 'device type' would also work, but my understanding is that this is just an Atmel defined number for each device which is not stored in the AVR at all....

Lee

<<Atmel's app note AVR089>> Oops! Never found that. Thanks!

Carl

<<As I didn't see where you specified any particular language,>> ASM - it's in the thread title!

By the way, just come across the following that could be useful to some people here - I presume it's also on the proper www.atmel.com website somewhere as well:
http://atmel.argussoft.ru/downlo...

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

The signature bytes should be readable like fuses using LPM I think (can't guarantee that but it seems to the most likely reason for their existence). Off to read a datasheet now....

Cliff

Edit: rats, looks like they're only visible to a serial/parallel programmer but I guess you could just write a recognisable CPU id byte to EEPROM and use that as a run time switch ?

Edit2: Or maybe use the fact that Mega16 has 1K of SRAM and Mega32 has 2K and do a Ram test at initialisation?