Re: Warning on migrating to ATMega8515 - eeprom problem

From: Ulf Samuelsson (ulf_at_atmel.nospam.com)
Date: 11/02/04

  • Next message: Rob Young: "Re: Looking for an FPGA on a board (for fun...)" 
    Date: Tue, 2 Nov 2004 23:37:47 +0100

    "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
  • Next message: Rob Young: "Re: Looking for an FPGA on a board (for fun...)"

    Relevant Pages

    • Re: VS2005 major development bug
      ... Crashing during compilation would mean then compiler to throw an ICE, but that's surely not the case. ... But I don't want to be pedantic and this has nothing to do with the problem / bug we are discussing in this thread about. ... Managed C++ was to make the pimpl class a nested class of the ref class and pass a pointer of the ref class to the pimpl class. ... A nested class seems not to be allowed anymore to access private members of a managed class. ...
      (microsoft.public.dotnet.languages.vc)
    • OSDK Version 0.013
      ... Corrected a bug in the makefile that make it ... Added a new program in the OSDK, ... I tested it to compile the game from Fabrice, I had to do a few ... modifications in the source code, but also some bugs to correct in the OSDK ...
      (comp.sys.oric)
    • Re: statically compiled files left over after a make world
      ... The bug did ... bootstrap the compilation of the various loadable modules. ... would gain the attacker nothing more than he could gain by simply ...
      (FreeBSD-Security)
    • Re: new 20050811 kernels available
      ... VCAFILT is known to be buggy - you might want to ask John Rodriguez if he will open source it. ... Hell, the problem could even be in calls between Sunley's YadTV2 and gradd video system, which passes through the kernel. ... He only borrowed the source code of wcast.sys to fix a bug as a favor to me. ... Since I believe he no longer has an OS/2 build system, he is not able to fix this bug from wcast.sys side, assuming that he could borrow the code again. ...
      (comp.os.os2.bugs)
    • Re: Signed zeros: is this a bug?
      ... Looks to me like you've found a bug with the parser/compiler: ... appear within the same "unit of compilation" (expression, function, ... errant "peephole optimizer" pass which tries to roll multiple ...
      (comp.lang.python)