[En-Nut-Discussion] Nut/OS Memory Considerations

[Harald Kipp]

Alastair,

>In the implementation of bank switching in the OS:
>
>Have the ability to specify the start and end of the "Unswitched RAM".
>Have the ability to specify the start and end of the "Bank Switched RAM".
>Have the ability to move the bank select register to be any location in
>memory.

These things very much depend on the hardware
implementation. What I defined is a minimum API,
which can be done with a minimum hardware and
leave maximum room for enhancements.



>Also (maybe?) have the ability to specify a second range of SRAM that is
>able to be used by the heap. This would mean that you could fill up an area
>between 0xC000 to 0xFEFF that is unused by memory mapped IO with RAM, and
>have the O/S support putting the heap into it. I haven't looked deep into
>the heap allocation process, but I assume that since it is a linked list of
>free areas, this should mean that the areas do not actually HAVE to be
>continuous, and thus you could have a second area after the bank switched
>area.

This is easily done by an additional NutHeapAdd.
Indeed, the heap areas don't need to be continuous.
The current solution is to create a new init.c
for a specific hardware. A more advanced solution
may automatically determine available RAM layouts.



>Also, for your bank switching numbers, and things such as a default of
>'0'... you might find that when it comes around to actually implementing the
>bank switching that the default of 0 might make it a little more difficult
>to implement. You (I assume) will only be using a single SRAM chip, in which
>case you might find that a default of '2' ends up easier to implement in
>hardware (leaving "Bank0" and "Bank1" to be the "Unswitched RAM").

Bank numbers are not reflecting real banks. It's
up to the bank switching driver to do the translation.



>You may want to be able to move the bank select register around, because
>since in any wait-state cycle setup the topmost area of memory is the most
>likely to end up with wait states (assuming use of fast SRAM). So it would
>be 'nice' to be able to move things that don't need wait states out of
>there. (Yes, I agree you will not be switching very often) You might also
>want to think about read-back capability for the "current SRAM bank" in your
>hardware implementation, too.

The bank switching chapter in the manual should
have made a clear distinction between the hardware
driver implementation and the API. In fact, the
hardware should be part of another manual dealing
with drivers in general. But to save work I
added some details in this manual plus a sentence,
that things may be implemented different on the
hardware dependend part.

Hope, you don't get the feeling now, that I'm pushing
down any argument. I take any suggestion most seriously.

Harald