[En-Nut-Discussion] Ethernut 2.0 Alpha Schematic

[Alastair Jeremy]

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)

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.

Suggested detail:

(a) 0x0000 - 0x0fff - internal ATmega128/103 memory
(b) 0x1000 - 0x10ff - internal ATmega128 memory
(c) 0x10ff - 0x7fff - external memory, "addresses 0x10ff to 0x7fff" (ie. 28k
out of a 32k section)
(d) 0x8000 - 0xbfff - banked external memory, 'n' banks of 16k
(e) 0xC000 - 0xCfff - possible re-mapping of lowest 4kb (see below for
explanation)
(f) 0xd000 - 0xffff - "memory mapped I/O range"

You could also break (f) down depending on your application into 0xd000 -
0xdfff and 0xe000-oxffff, where the first part is high speed, and the second
part has wait states for slower peripherals (or you could split at 0xC000
for wait states and have all peripherals being "slow").

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?

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

If you are using a C compiler that will handle storing it's own heap in
banked SRAM, then there is no real point in adding (e), and I would suggest
leaving it as "memory mapped I/O range" (obviously with the potential for
someone to map in the SRAM anyway!).

Anyway, I would suggest just leaving the bottom 4k of the last 16k as a
"possible" area for SRAM, and not planning (yet) to map something into it.

Now for item (f), the "memory mapped I/O range".

I don't think it is necessary at this stage to break down *exactly* how this
has to work. The ethernet controller software works on a base address, and
thus can be moved to anywhere in here. It would be "nice" to be able to move
around anything that is on the ethernut and located in this address space.
eg. at the moment it is not possible to decode the Realtek at any other
address without cutting and strapping tracks.

I would say you should probably leave how to decode this area up to the
user. Or if you must decode it in some manner, simply decode it and provide
all the -CS out at the header. Then for a chip like the Realtek, put it's
"Chip Select" line(s) at the header as well (essentially 2 address lines
could be used to give you one active high and one active low CS). Then you
can build your own external hardware which can "put" (using a hardware link)
the ethernet controller at a suitable location, based whatever else is being
done externally.

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

I actually quite like the memory mapped bank switch, ie. write to a
particular location in memory, or read from one, etc. If you are using
simple logic chips (ie 3-8's and latches, not a CPLD), then mapping 256
bytes as a "bank latch" would be ideal.

So if we just had a defined macro to switch banks I think that would solve
it. For the memory mapped bank switch, you would make it a write to external
SRAM, for port-pin bank select you could use OUT. And if in the future
someone had a massive memory requirement, then you could just change the
bank switch macro to deal with more than an 8 bit number for the bank.

Oh, while I'm on a roll - it would also be useful to have ALE on the header,
in case you want to do something non-standard there, too, or just multiplex
the use of that pin (I can understand why it is not on the current design,
since the current design started out with the ATmega103, which did not have
alternate port function available for ALE/WR/RD)

Enough of my ramblings for today :)

Alastair


-----Original Message-----
From: en-nut-discussion-admin at egnite.de
[mailto:en-nut-discussion-admin at egnite.de]On Behalf Of Mikael E.Pedersen
(MEP)
Sent: Wednesday, 23 October 2002 4:29 PM
To: 'en-nut-discussion at egnite.de'
Subject: RE: [En-Nut-Discussion] Ethernut 2.0 Alpha Schematic



> -----Original Message-----
> From: Austin Schutz [mailto:tex at off.org]
>
> 	Ok, so here's one more idea:
> 	1. Leave 0x0000 - 0x7fff for controller
> 	2. Make 0x8000 - 0xbfff for decoded devices using 3to8 or 4to16
decoder
> 	3. Make 0xc000 - 0xffff for bank switched memory (~ 16k blocks)

How about swapping 2 and 3 ? So the bank switched mem is before the decoded
devices.
In that case it will be possible to use the Mega128 feature that can set
additional waitstates for high memory addresses.
Then you can have extra waitstates on the decoded devices (if needed), but
still have faster access to both the
standard 32k ram and the bank switched ram.

Best regards,
Mikael
_______________________________________________
En-Nut-Discussion mailing list
En-Nut-Discussion at egnite.de
http://www.egnite.de/mailman/listinfo/en-nut-discussion