> 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

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'

"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

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!

> 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.

-- 
Best Regards
Ulf at atmel dot com
These comments are intended to be my own opinion and they
may, or may not be shared by my employer, Atmel Sweden.

Ulf Samuelsson wrote:
> "Mike Harrison" <mike@whitewing.co.uk> skrev i meddelandet
>
... snip ...
>>
>> The problem actually 'occurred' a few years ago when we were
>> forced to migrate from the 4414 to the 90S8515 when the 4414 was
>> obsolete, then only manifested itself when we again were forced
>> to change to a new part due to the 8515 going obsolete.
>>
>> Most of us are too busy developing new products to spend a lot of
>> time re-examining code written years ago that breaks when put on
>> a new, supposedly 'compatible' part.....
> 
> I think this email went a bit premature. I meant to say:
> You need to read more carefully to see that most registers ARE in
> fact initialized even on the ATmegaAVR.
> 
> I dont think it is reasonable to expect to see that the EEAR is not
> initialized and I think it *should* be in the migration document.

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.

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

"Mike Harrison" <mike@whitewing.co.uk> skrev i meddelandet
news:6jado0lhhn5f1r0n5tmkm7u8f2cs6j06a6@4ax.com...
> On Mon, 1 Nov 2004 20:29:08 +0100, "Ulf Samuelsson" <ulf@atmel.nospam.com>
wrote:
>
> >
> >"Tim Mitchell" <timng@sabretechnology.co.uk> skrev i meddelandet
> >news:H8LIWLibzjhBFAV2@tega.co.uk...
> >> In article <k04co054e0g5rcbn50h2tptfh3i3sg46r8@4ax.com>, Mike Harrison
> >> <mike@whitewing.co.uk> writes
> >> >Here's a warning that may hopefully save someone else all the hassle
> >> >we've just had after migrating
> >> >a product to the Mega8515 - there may be a similar issue with other
> >> >back-compatible mega parts..
> >> >
> >> >We had some code that was originally written for a 90S4414. This moved
> >> >to a 90S8515 a while ago when
> >> >the 4414 went obsolete. We recently changed to the AtMega8515, again
> >> >due to the old part going
> >> >obsolete.
> >> >We then started seeing apparently random eeprom corruption on some
> >> >units. We could write and verify
> >> >the eeprom, but after powering off for an hour the data would
sometimes
> >> >be all FFs, and sometimes
> >> >correct.....
> >> >
> >> >After many false leads and much headscratching, I chanced on a subtle
> >> >difference between the
> >> >ATMega8515 and the old 90S4414/8515 parts, which is not highlighted in
> >> >the datasheet ' differences'
> >> >section (I have emailed Atmel to suggest they add it..).
> >> >
> >> >On the Mega version, The EEADR registers are not initialised to a
> >> >guaranteed state on reset. They
> >> >are initialised to 0 on the old 90S parts. As the code was originally
> >> >for the 4414, (which has 256
> >> >bytes eeprom, hence no EEADRH), and then moved with no problems to the
> >> >90S8515 (which initilises
> >> >EEADRH to 0), there was no code to explicitly clear EEADRH, so on the
> >> >Mega8515, we had what amounted
> >> >to a 'random page swap' on power-up, and some rather unhappy
customers...
> >>
> >> I believe this is the (undocumented) case with all registers on all AVR
> >> Mega parts - the registers all power up in an undefined state, but as
> >> you say on the older AVRs they power up consistently at 0. Has caused
> >> some fun when porting code over.
> >> -- 
> >> Tim Mitchell
> >
> >Thanks, I spread it around internally !
> >However, I think you need to read the datasheet more carefully.
>
> I don't dispute that the information is in there, but I don't think anyone
would think it reasonable
> to read through a 255 page datasheet line-by-line to compare minor details
to spot changes from a
> part that is promoted as a direct replacement. The datasheet should have a
section that itemises
> EVERY difference, however subtle,  so any potential problem areas can
easily be looked at.
>
> The problem actually 'occurred' a few years ago when we were forced to
migrate from the 4414 to the
> 90S8515 when the 4414 was obsolete, then only manifested itself when we
again were forced to change
> to a new part due to the 8515 going obsolete.
>
> Most of us are too busy developing new products to spend a lot of time
re-examining code written
> years ago that breaks when put on a new, supposedly 'compatible'
part.....
>

I think this email went a bit premature. I meant to say:
You need to read more carefully to see that most registers ARE in fact
initialized
even on the ATmegaAVR.

I dont think it is reasonable to expect to see that the EEAR is not
initialized
and I think it *should* be in the migration document.


-- 
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

"Vladimir Vassilevsky" <antispam_bogus@hotmail.com> skrev i meddelandet
news:W%whd.4189$fC4.1110@newssvr11.news.prodigy.com...
> One thing I can't understand about the previous and the latest AVRs:
>
> Why the EEPROM write takes about 1ms on the "old" AVRs and about 8ms on
> the "new" AVRs?
>



> The funny thing is that ATMega128 has the EEPROM write time of 8ms in
> the native mode and 1ms in ATMega103 compatibility mode! So the
> different silicon is apparently not an issue.

That is indeed funny! Here is my guess.
IIRC, there was a problem initially with Silicon fabbed in the North
Tyneside facility.
The part will complete the EEPROM write after a certtain number of cycles
of an R/C oscillator. The number of counts is fixed, and set to handle the
slow EEPROM.
Now we may have a faster EEPROM, but the part does not understand this in
the ATmega128 mode
In ATmega103 mode it completes in a different way, and the true speed of the
EEPROM is available.
As I said, this is pure guessing.

> The difference in EEPROM timing caused us a problem when porting the
> code from ATMega323 to ATMega32.

Yes, me too, I had to change three lines of code which were obvious
what they were supposed to do.

"Send signal to self in 4 ms, because then the EEPROM has terminated any
possible ongoing write"

I changed the constant 4 ms to 6 ms in the ATmega16 and then the program
worked.


12 kB of ATmega163 code required 20 lines changed.
The EEPROM timer, the fact that the UART has three stages.

Proper way to clear a UART receive buffer is not to read the UDR and assume
it then is empty.
There is a bit which tells you that it is empty, and this means that you
read the UDR
until the chip says it is empty.

I think that the program could have been written for he ATmega163 in such a
way that
there would not be any need to change the code.

Lesson learned:
-- When programming, it is important to understand what datasheet values may
change in the future
    and prepare for this.

> Vladimir Vassilevsky
>
> DSP and Mixed Signal Design Consultant
>
> http://www.abvolt.com
>
> Mike Harrison wrote:




-- 
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 Mon, 1 Nov 2004 20:29:08 +0100, "Ulf Samuelsson" <ulf@atmel.nospam.com> wrote:

>
>"Tim Mitchell" <timng@sabretechnology.co.uk> skrev i meddelandet
>news:H8LIWLibzjhBFAV2@tega.co.uk...
>> In article <k04co054e0g5rcbn50h2tptfh3i3sg46r8@4ax.com>, Mike Harrison
>> <mike@whitewing.co.uk> writes
>> >Here's a warning that may hopefully save someone else all the hassle
>> >we've just had after migrating
>> >a product to the Mega8515 - there may be a similar issue with other
>> >back-compatible mega parts..
>> >
>> >We had some code that was originally written for a 90S4414. This moved
>> >to a 90S8515 a while ago when
>> >the 4414 went obsolete. We recently changed to the AtMega8515, again
>> >due to the old part going
>> >obsolete.
>> >We then started seeing apparently random eeprom corruption on some
>> >units. We could write and verify
>> >the eeprom, but after powering off for an hour the data would sometimes
>> >be all FFs, and sometimes
>> >correct.....
>> >
>> >After many false leads and much headscratching, I chanced on a subtle
>> >difference between the
>> >ATMega8515 and the old 90S4414/8515 parts, which is not highlighted in
>> >the datasheet ' differences'
>> >section (I have emailed Atmel to suggest they add it..).
>> >
>> >On the Mega version, The EEADR registers are not initialised to a
>> >guaranteed state on reset. They
>> >are initialised to 0 on the old 90S parts. As the code was originally
>> >for the 4414, (which has 256
>> >bytes eeprom, hence no EEADRH), and then moved with no problems to the
>> >90S8515 (which initilises
>> >EEADRH to 0), there was no code to explicitly clear EEADRH, so on the
>> >Mega8515, we had what amounted
>> >to a 'random page swap' on power-up, and some rather unhappy customers...
>>
>> I believe this is the (undocumented) case with all registers on all AVR
>> Mega parts - the registers all power up in an undefined state, but as
>> you say on the older AVRs they power up consistently at 0. Has caused
>> some fun when porting code over.
>> -- 
>> Tim Mitchell
>
>Thanks, I spread it around internally !
>However, I think you need to read the datasheet more carefully.

I don't dispute that the information is in there, but I don't think anyone would think it reasonable
to read through a 255 page datasheet line-by-line to compare minor details to spot changes from a
part that is promoted as a direct replacement. The datasheet should have a section that itemises
EVERY difference, however subtle,  so any potential problem areas can easily be looked at. 

The problem actually 'occurred' a few years ago when we were forced to migrate from the 4414 to the
90S8515 when the 4414 was obsolete, then only manifested itself when we again were forced to change
to a new part due to the 8515 going obsolete.  

Most of us are too busy developing new products to spend a lot of time re-examining code written
years ago that breaks when put on a new, supposedly 'compatible'  part.....

One thing I can't understand about the previous and the latest AVRs:

Why the EEPROM write takes about 1ms on the "old" AVRs and about 8ms on 
the "new" AVRs?

The funny thing is that ATMega128 has the EEPROM write time of 8ms in 
the native mode and 1ms in ATMega103 compatibility mode! So the 
different silicon is apparently not an issue.

The difference in EEPROM timing caused us a problem when porting the 
code from ATMega323 to ATMega32.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

http://www.abvolt.com

Mike Harrison wrote:

> Here's a warning that may hopefully save someone else all the hassle we've just had after migrating
> a product to the Mega8515 - there may be a similar issue with other back-compatible mega parts..
> 
> We had some code that was originally written for a 90S4414. This moved to a 90S8515 a while ago when
> the 4414 went obsolete. We recently changed to the AtMega8515, again due to the old part going
> obsolete.
> We then started seeing apparently random eeprom corruption on some units. We could write and verify
> the eeprom, but after powering off for an hour the data would sometimes be all FFs, and sometimes
> correct.....
> 
> After many false leads and much headscratching, I chanced on a subtle difference between the
> ATMega8515 and the old 90S4414/8515 parts, which is not highlighted in the datasheet ' differences'
> section (I have emailed Atmel to suggest they add it..).
> 
> On the Mega version, The EEADR registers are not initialised to a guaranteed state on reset. They
> are initialised to 0 on the old 90S parts. As the code was originally for the 4414, (which has 256
> bytes eeprom, hence no EEADRH), and then moved with no problems to the 90S8515 (which initilises
> EEADRH to 0), there was no code to explicitly clear EEADRH, so on the Mega8515, we had what amounted
> to a 'random page swap' on power-up, and some rather unhappy customers...