[En-Nut-Discussion] Thoughts on memory maps...

Harald Kipp harald.kipp at egnite.de
Thu Nov 4 09:13:37 CET 2004


Curtis,

At 11:43 04.11.2004 +1100, you wrote:

>I've been reading up on the Ethernut and Nut/OS recently, and I am well 
>impressed.  So much so, the company I work for is planning to use it in 
>many of our future projects.  We will probably even contribute to the 
>H8/300H port, since we also make a platform using that family of CPU.

Sounds good.



>However, one thing strikes me as odd with regards to the Ethernut design, 
>and that is the memory arrangement.
>
> From what I read in the docs, the external memory has been placed at 
> address 0x0000 - a fairly understandable start.  It goes on for 32k, then 
> there's a 16k gap for memory mapped IO, then 16K of bank switched 
> memory.  All seems fine, except that you (willingly) lose the lower 
> 4-and-a-bit K of RAM which is overlapped by the on-board memory and IO space.

The very original design was done as simple as possible.
Since then nobody cares about the wasted 4k, even after
the more complex CPLD design had been done.



>Why not start the RAM at 16K, and leave the 0x0860-0x4000 area for memory 
>mapped IO?  That way you get a clean 48K of RAM (or 32K + 16K banked, or 3 
>16K banks, or whatever) and don't lose any RAM to overlap.

You probably meant 0x1100-0x4000. The ATmega RAM is at
0x100-0x10FF. There are two reasons for external RAM start
at 0x1100:

1. To have one continuous area of RAM. Actually I found out,
that some Etehrnut developers changed nutinit in a way,
which doesn't allow gaps. But anyway, if the RAM area
isn't continuous, you loose the ability for having a bss
segment (gloabl and static variables) larger than 4k.

2. The ATmega allows to add wait states on upper memory
access, which is quite nice for memory mapped I/O.


>The configurator appears to allow you to specify where the external memory 
>starts, so it may not be a massive problem to adapt to this change.  Also, 
>I understand the memory decoding is handled inside a GAL, so it could be 
>as simple as reprogramming it.
>
>Or am I sorely mistaken?

You're right, this should be possible. But note, that
the Configurator is not yet finished and not all setups
may work. Anyway, in the future memory reconfiguration
should be possible.

Harald




More information about the En-Nut-Discussion mailing list