[En-Nut-Discussion] Ethernut 2.0 Alpha Schematic

Alastair Jeremy ajeremy at dotaussie.com.au
Sun Oct 27 23:27:32 CET 2002


As per your comment below - this is actually also why I suggested re-mapping
the 0x1000 bytes that are "under" the internal ATmega SRAM up into the area
immediately after the banked area. Then if you never switched banks (or had
a C compiler that didn't support banked heap) you would have 52k available,
and very little waste.

Alastair


-----Original Message-----
From: en-nut-discussion-admin at egnite.de
[mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Austin Schutz
Sent: Friday, 25 October 2002 4:06 AM
To: en-nut-discussion at egnite.de
Subject: Re: [En-Nut-Discussion] Ethernut 2.0 Alpha Schematic


> If you were using a compiler that did not support banked memory for your
> application (ie. you used it for your own special routines or as a buffer
or
> something), then with the above map you could have up to 32k+16k+4k=52k of
> continuous SRAM for the C program heap, and then just switch in other
banks
> for your 'special' purposes to be kept within 'critical' sections of code
> (and remembering to switch back to the bank that the C program is using!).
>

	You could switch the bank yourself by writing to the latch. Even
if you never used it again it would give you a static 48k of memory. I
agree that it would be nice to have the non-device mapped high memory be
addressable. If you could completely optimize it you could get very close
to having the full 64k usable.






More information about the En-Nut-Discussion mailing list