Extended I/O & Mega8 vs Mega88

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

I ran into an interesting problem trying to migrate a design from the Mega8 to the Mega88. First of all, Atmel's app note fails to mention several differences including register problems, CLKPR (the clock prescaler), and more.

But, believe it or not, what killed the hardware migration was the fact they moved much of the I/O to the extended I/O area. This makes these registers unreachable by the IN and OUT instructions and you have to use STD and LDD instructions instead.

These are 4 byte instead of 2 byte instructions which makes your code bigger! Everywhere these extended registers are accessed requires 2 more bytes of code space (except the odd exception where the compiler or assembly programmer can use some tricks to use ST/STS instead).

The IN/OUT to STD/LDD is a lot of work for any code that was written in assembler. Once you start using the STD and LDD replacements, suddenly conditional branches are out of range, and you have even more code to modify and test.

Most of the I/O re-asignments are not because the Mega88 has vastly more on-chip peripherals compared to the Mega8. It's only because Atmel is trying to make the newer Mega devices more compatible with each other. So it's a bit frustrating!

I realize Atmel doesn't claim the Mega88 is a replacement for the Mega8, but it's something to watch out for if you were thinking of the Mega88. I also realize the Mega168 (with more code space) is another solution for some. In this case the code that didn't fit is in the bootloader section which doesn't get any bigger in the Mega168. So it killed the project. I hope they keep making the Mega8 for a long time!

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

I agree not having CLKPR mentioned is a mistake. Report it to ATMEL.

For AVR assembler don't use IN or OUT. Use a macro like this one instead:

; AVR {in/lds} - {out/sts} automatic selection macros
;
;	The device include file must be used to define SRAM_START
;

; usage: InReg reg, addr
.macro InReg
    .if @1 < 0x40
        in @0, @1
    .elif ((@1 >= 0x60) && (@1 < SRAM_START))
        lds @0,@1
    .else
       .error "InReg: Invalid I/O register address"
    .endif
.endmacro

; usage: OutReg addr, reg
.macro OutReg
    .if @0 < 0x40
        out @0, @1
    .elif ((@0 >= 0x60) && (@0 < SRAM_START))
        sts @0,@1
    .else
       .error "OutReg: Invalid I/O register address"
    .endif
.endmacro

Then all you have to change is the device include file and check the migration information. Of course it will not help with relative branches that go out of reach or when code grows too large.

The exception would be parts without SRAM where the macros need changing. However, I think the AVRs without SRAM are so small all the registers probably fit into the IN/OUT addressing anyway.

I agree it can be frustrating. However, keep in mind you are using a new/different chip with real improvements over the ATmega8. As you pointed out using the original ATmega8 is the only way to ensure total compatibility. Being that I'm not involved with designing or testing the silicon based on a new “family” of products I cannot say for sure, but making devices more “compatible” may go a lot deeper than you have considered.

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

CLKPR probably isn't mentioned in the migration note for one particular reason:
When it is left in its default state (ie. left untouched), the ATmega88 will operate identically to an equally-configured ATmega8 in virtually all situations.

This argument falls apart if you want to have access to the 2 MHz or 4 MHz internal RC oscillator options of the ATmega8. The section of the migration note dealing with oscillator settings probably could benefit from a mention of CLKPR.

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

Quote:

The IN/OUT to STD/LDD is a lot of work for any code that was written in assembler. Once you start using the STD and LDD replacements, suddenly conditional branches are out of range, and you have even more code to modify and test.

I'll have to remember this quote for the next "C vs. ASM" war. ;)

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.