[Openec] checksum of first 64k of updateme.bin not calculated correctly

[Frieder Ferlemann]

Hi Paul,

Am 02.11.2010 18:48, schrieb Paul Fox:
> i wrote:
>  > frieder wrote:
>  >  > The memory model currently used (--model-large) for SDCC
>  >  > is typically generating about 33% larger code than the
>  >  > (--model-small) or about 18% larger code than the
>  >  > stack-auto memory model.
>  >  > (ratios from regression test results)
>  > 
>  > we should certainly look at using small, then.  when i built a
>  > comparable set of 1.75 source on both keil and sdcc "large", keil was
>  > about 2/3's the size.  many of our accesses are to xdata, as you
>  > noticed, so we might not get the full gain of small, but if it could
>  > keep us on sdcc we'd all be happier.
> 
> well, i switched to --model-small, and then added xdata keywords to
> global and static declarations until i no longer got "Could not get NN
> consecutive bytes in internal RAM for area DSEG" messages.

you might want to (in thought) sort the declarations
by how often they are used (not how often they are
used in time but how often they are referenced in
the code) and then move them around between __data,
__idata, __pdata and __xdata memory.
Using __data for the topmost declarations until
the __data memory space is exhausted, then use
about 60 bytes __idata memory (so there's enough
for the stack left), then move to __pdata, finally
to __xdata.

> doing this took us from 39K to 36K of code, clearly much less than a
> 33% savings.  presumably this is because our xdata needs are so big
> that we don't get a big savings.  does that seem right?

Yes (together with the only 2k difference you see with Keil when
switching from large to small) this can be right.

(although I see a size reduction of 1325 bytes for
onewirebatt.c alone and another around 700 bytes
are likely used less for the small memory model
printf.

You could try printf_small, printf_fast or printf_tiny
as well (feature subsets of printf)
by using #define printf printf_tiny

> switching to 3.0, as you predicted, gave minimal savings -- under 100
> bytes.
> 
> we can eliminate some code (e.g., we probably don't need all of
> monitor(), for instance, and the 1150 byte "updateme" image will go

Is 1067 byte here:)

> away when we switch to the 3731).  we also know that we can use bit
> variables for many of our booleans, and some data is probably
> redundant -- porting our code to the new framework has exposed some of
> that.  but i'm not optimistic about fitting in 32K -- at least not
> with comfortable breathing room.  :-/

Yes, Where does the limitation to 32K come from?

> (i also spent time converting the code to keil.  using large model it's
> 28K, and small model is around 26K.)

If Keil is at 26K then reaching 32K will be a hard task
(and the breathing room...).

Greetings,
Frieder