[En-Nut-Discussion] Ethernut 2.0 Alpha Schematic

[Austin Schutz]

On Thu, Oct 24, 2002 at 08:36:12AM +1000, Alastair Jeremy wrote:
> My 2 cents worth:
> 
> I would suggest that the swapped version of this suggestion would be the
> most appropriate. I think it would be good not to have a break in the
> external SRAM memory. Also I think that at this stage we probably shouldn't
> be as worried about things like whether to use a 4-16 or 3-8, since it is
> quite possible that at some stage it will just become a CPLD or GAL, where
> you can do all sorts of things. I would suggest calling it "memory mapped
> peripherals area". If you did put a basic 3-8 or 4-16 on the base board,
> then I would suggest not 'forcing' the user to use it, ie. don't use it to
> decode any on-board stuff, but rather route all the 8/16 decoded lines to a
> header, and the CS of any on-board stuff for the "memory mapped periperals"
> to a header, and let the user link up the desired combination (or provide an
> external, completely different way of mapping things)

	Interesting idea. Well, it would at least allow for the user to
move the ethernet and/or bank switch to a different memory space.

> 
> I would suggest the following memory map:
> 
> Summary:
> 
>  0x0000 - 0x7fff - SRAM
>  0x8000 - 0xbfff - Banked external memory, 'n' banks of 16k
>  0xC000 - 0xffff - Other "stuff", including memory mapped I/O, ethernet
> controllers, etc.

...

> Firstly, item (e): Leave a gap here if you are using simple 3-8 or 4-16
> decoding, but if using a CPLD or GAL then re-map the external memory which
> would normally be "0x0000 to 0x0fff" to this location, thus you don't end up
> wasting 4kb of your external memory (you would only waste 256 bytes if using
> ATmega128 in normal mode, ie. not in the '103 compatibility mode).
> 
> I am not sure how the C-compiler deals with bank switching? I think that GCC
> does not do banking, or am I wrong? Can someone advise on what other C
> compilers are capable of?
> 
	Not sure.

> 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.


> As for banking, I also think that it probably isn't necessary at this stage
> to define exactly how banking should work. All we really need is to define a
> macro that is "change bank to N", and then you should be able to implement
> your own banking scheme. For example, if you wanted to be able to switch
> banks very quickly, it might be faster having a few Port pins dedicated to
> the task (nasty I know, but if you NEED the speed, it is possibly a
> worthwhile allocation of pin resources, it goes from 3 cycles to 1 cycle to
> switch banks if all other pins on that port are in special function mode).

	Well, that's really the tradeoff. Chips vs. ports. There are
existing apps that supposedly use all the ports. it would be nice to leave
them all to the users.

	As far as the cpld, well it sounds neat. Can it be built into the
existing system reprogrammable by the users? If so, it's probably possible
to tie the bank switching mechanism to a single address, and you can let the
user figure out for themselves where they want everything to live beyond
a reasonable default. Seems like you have better experience with those than
the rest of us (well at least the loud ones like me :-). Could you just
replace everything off the bus including even the existing address latch
and have the cpld handle it all? How complex can the cpld code be without
requiring a $$ chip? What software/hardware tool would users use to program
it?

	Austin