[En-Nut-Discussion] Paged Memory Access and Segmented Buffer

[Harald Kipp]

Hi Peter,

At 12:18 22.05.2006 -0700, you wrote:

>memory locations 0xFF00-0xFF1F select the page during a write
>operation, this is then latched and now the RAM available to the
>processor is at 0x8000 to 0xBFFF read or write, and A14 must be low

"Officially" it works like this:

Writing 0 to 0xFF00 makes 16k bank 0 visible in 0x8000-0xBFFF.
Writing 1 to 0xFF01 makes 16k bank 1 visible in 0x8000-0xBFFF.
...and so on.


>To get back to the main 32K i have to do a write operation to what
>address? 0xFF1F?

The lower 32k always remain static and visible, no matter which
bank is enabled in 0x8000-0xBFFF.



>does anyone have any examples of this in assembly? is the overhead
>when using the built in Segmented Buffer insignificant that i should
>forget about it?

You may check the .lst file. But a simple inlined routine
without extra stuff like local variables is typically not
larger than pure assembly. Though, it depends on your
environment and requirements. Best use C first and then
check the .lst file for the assembler code that has been
generated.




>Also with the segmented buffer, it claims to ignore the size when
>calling NetSegBufInit(size), but this does not seem to be the case
>for me, i did not run the configurator as i am on OSX.  I set
>NUTBANK_COUNT to 30 manually in memory.h, and when i call
>NUTBANK_COUNT in my code it tells me 30, but when i call
>NutSegBufAvailable() it is not 30X16k, only 16k and that is only when
>i call NutSegBufInit(16384);  is there another place where i should
>be defining NUTBANK_COUNT instead??

cfg/memory.h is fine. Alternatively you may add

   HWDEF+=-DNUTBANK_COUNT=30

to UserConf.mk.

Nut/OS library building doesn't recognize header file dependencies.
May be you forgot to 'make clean'?

Harald