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

[Curtis Maloney]

Harald Kipp wrote:
> Curtis,
> 
> At 11:43 04.11.2004 +1100, you wrote:
> 
  > 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.
> 

Well, I can't see why you'd sacrifice a whole 4K because of not rearranging a 
few GAL/CPLD equations.  True, it may leave you with a memory hole, but 4K is 4K.

>> 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:
> 
Yes, I meant 0x1100... I've been using the ATmega32 a lot of late.

> 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.
> 
I can see the hazards of non-contiguous RAM... in which case, you could even 
just mangle the upper address pins so it remaps the lower 4K elsewhere.

I've also been toying with the idea of using the lower memory for stack, or 
system data, or something similar to keep it separate from the task space.


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

And here is where I guess I should have read the manual more thoroughly.  That 
makes a BIG difference, yes.

On a slightly different note, we were going to try to test Nut/OS on an existing 
mega32 board we have, only to find far too much of the configuration is 
conditional defined on the specific chip.  For example, instead of saying 
"Simple UART" for the type on the mega103, and "Advanced UART" for that on the 
mega64/mega128, it specifically checks for mega103.

Now, I understand this is most likely because they were the only distinctions 
for you, either "the old board" or "the new board".  But I can see a great 
advantage in trying to split these definitions away from the specific 
implementation.

My thinking was that a specific CPUs define set would specify more abstract 
tags, such as:

#define HW_UART_ADVANCED	2

for the mega128 to say it has two Advanced UARTS.  Then the UART code could have:

#ifdef HW_UART_ADVANCED
[uart0 config/setup here]
#if HW_UART_ADVANCED > 1
[uart1 config/setup here]
#endif
#endif

Given that most MCU platforms generally use the same peripheral modules, and 
their IO addresses are #defined in an include, this would make supporting 
newer/other MCUs from the same family much simpler.

I'm quite happy to make the effort, but I would rather start knowing the sort of 
naming conventions you'd prefer.

> Harald
> 
--
Curtis Maloney