Warning on migrating to ATMega8515 - eeprom problem

Ulf Samuelsson wrote:
> 
>> I have been idly following this thread, and as far as I am
>> concernced that new device has a serious bug.  It obviously cannot
>> run code developed for earlier products without changes, so cannot
>> be used as a replacement.  It would have taken little effort to set
>> that register in a known harmless condition on reset.
> 
> Yes, probably a bug, but it is questionable if it is serious.
> I.E worth doing a new maskset to fix this bug.
> 
> The bug only affect those that step up from the 4414, and
> those that assume that registers have a known value at reset.
> 
> It is generally a good practice to avoid relying on reset values.
> 
> It is an unknown harmless condition on reset and takes two
> instructions to fix after reset. The problem is if you do not
> know about it.

I consider it a bad bug.  You can't have code that runs on both
machines, it will either have illegal instructions, or fail to
initialize.  

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

"CBFalconer" <cbfalconer@yahoo.com> skrev i meddelandet
news:4187D0DC.1B5B1695@yahoo.com...
> Ulf Samuelsson wrote:
> >
> >> I have been idly following this thread, and as far as I am
> >> concernced that new device has a serious bug.  It obviously cannot
> >> run code developed for earlier products without changes, so cannot
> >> be used as a replacement.  It would have taken little effort to set
> >> that register in a known harmless condition on reset.
> >
> > Yes, probably a bug, but it is questionable if it is serious.
> > I.E worth doing a new maskset to fix this bug.
> >
> > The bug only affect those that step up from the 4414, and
> > those that assume that registers have a known value at reset.
> >
> > It is generally a good practice to avoid relying on reset values.
> >
> > It is an unknown harmless condition on reset and takes two
> > instructions to fix after reset. The problem is if you do not
> > know about it.
>
> I consider it a bad bug.  You can't have code that runs on both
> machines, it will either have illegal instructions, or fail to
> initialize.
>
> -- 


AVR code is not binary compatible between chips because the I/O locations
move around.
Even when they don't there are other issues.
The I/O on the ATmega88 is in the same position as in the ATmega168
buts since the ATmega168 uses > 8KB code space, all the vectors are 32 bit.

Thus you have to recompile.

If you accept source compatability, then there are several way you can
proceed.
Conditional compilation is one way.
If I want to use the same code for several chips I generate a couple of
files.
config.h
compatability.h            - defines fixes needed for this chip compared to
my "base" chip.

For this specific case, I can use one SRAM location, or a CPU register as
EEARH.

compatability.h thus contains.
#ifdef    AT90S4414
__regvar __no_init BYTE EEARH @ 10;        // use r10
#endif

EEARH    = 0;

results in
            clr    r10
being generated.for the 4414, and EEARH is set to 0 for all others.
r10 is normally not used anyway by the IAR compiler.

You can thus run the compiled result of the same source code on both CPUs
and you cannot run the same binary anyway, so it is not so nasty as you
describe it.

It is a valid complaint that the AVR is not binary compatible,
but I am afraid that the AVR architecture will not allow this for the mega
series.
The tiny series which is always < 8 kB could theoretically have this.
In practice with the limit of only a few bitadressable registers,
those are going to be used in an as efficient manner as possible.

With the ATmega48/88/168 Atmel tried to make parts as compatible as possible
within that family, and this is what will happen in the future.
One base design with derivatives using different memory sizes,
few or no changes between parts in different memory sizes.

There will always be some small exception to the rule.
The goal is really no modifications of the source code, binaries are less
important.

-- 
Best Regards,
Ulf Samuelsson   ulf@a-t-m-e-l.com
This is a personal view which may or may not be
share by my Employer Atmel Nordic AB

On Tue, 02 Nov 2004 21:12:17 GMT, CBFalconer <cbfalconer@yahoo.com> wrote:

>Ulf Samuelsson wrote:
>> 
>>> I have been idly following this thread, and as far as I am
>>> concernced that new device has a serious bug.  It obviously cannot
>>> run code developed for earlier products without changes, so cannot
>>> be used as a replacement.  It would have taken little effort to set
>>> that register in a known harmless condition on reset.
>> 
>> Yes, probably a bug, but it is questionable if it is serious.
>> I.E worth doing a new maskset to fix this bug.
>> 
>> The bug only affect those that step up from the 4414, and
>> those that assume that registers have a known value at reset.
>> 
>> It is generally a good practice to avoid relying on reset values.
>> 
>> It is an unknown harmless condition on reset and takes two
>> instructions to fix after reset. The problem is if you do not
>> know about it.
>
>I consider it a bad bug.  You can't have code that runs on both
>machines, it will either have illegal instructions, or fail to
>initialize.  

I don't think there would be any problem writing non-existant registers on the 4144 - it's not an
'illegal instruction'

> r10 is normally not used anyway by the IAR compiler.

Caution!  Unless you specifically instruct the compiler to not use r10,
it DOES use it.  An r10 is a must-preserve register, so even when you
dont inline assembler but call externally linked assembler code, you
must not scratch r10.

The compiler can be configured to not touch registers r15 and below. To
keep clear r10, you effectively have to forbid usage of r10-r15.  Note
that you also have to recompile the runtime library (clib/dlib), because
the precompiled versions that come with the installation binary are
compiled for full register usage.

Reserving R10-R15 wont result in lots of speed reduction.  Much code
compiles well without actually needing r10.  Thats probably why you
concluded that r10 is not used.  However, if you compile complex code
that can take advantage of many registers, r10 will be used.  Try for
example a cryptographic algorithm or other large function with lots
of autovars and only few function calls.  Set optimization to 9 and
see yourself.

Marc