I didn't think of that, the Linux driver is certainly available, although the c code is probably fairly twisted and tweaked to support various boards.
The modular solution W5100 sounds easier. The ability to receive and transmit raw Ethernet frames allows you to experiment with you own new protocols. Good idea.
Douglas W. Goodall
Post by William R Sowerbuttshttps://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/3com/3c509.c
I've used the Wiznet W5100 ethernet chip myself. I wrote an AVR ATmeta328P
bootloader that fits in 1KB and allows the AVR to be reprogrammed over
http://sowerbutts.com/optiboot-w5100/
I've used this chip for a few projects, all with AVRs, and it worked well.
The W5100 is a easy to program and hides all the details of TCP/IP. It's very
much simpler to use than implementing a full stack. It can also speak UDP
which is of course trivial compared to TCP. It has a "raw" mode that allows
you to just give it a raw ethernet frame to transmit, I believe it also has a
raw receive mode, so in principle you can bypass the built-in TCP/IP stack
and use it as a plain ethernet interface. When using the built-in stack it is
limited to four concurrent connections. It does support 10 and 100Mbit
ethernet and auto-negotiates both speed and duplex. It supports only IPv4
which is now (officially, at least) a "legacy" protocol (although maybe N8VEM
fans view this as a plus!)
There is a more recent W5200 chip that I've not yet used which looks better
but has a revised (incompatible) command set, etc. I think the SPI interface
has also been revised so you can get data in and out of the chip faster (with
the W5100 you must send 32 bits over the SPI bus for every byte transferred,
a lot of overhead)
I've also used the ENC28J60 (which just sends and receives raw frames)
although not as much as the W5100. It supports only 10Mbit ethernet and
doesn't support auto-negotiation. This means that you often end up with a
duplex mismatch between the switch and the ethernet chip which can result in
the switch seeing "collisions" when both ends to transmit at the same time.
Simplest solution is to tell the ENC28J60 to work in half-duplex mode, or
force the switch port to full-duplex. Irritating.
Since you have to implement the full TCP/IP stack with the ENC28J60 you could
support either IPv4 or IPv6 or both.
I've not used the newer ENC624J600, it looks to address the auto-negotiation
problem and add 100Mbit support, but it is also available only in a 3.3V
TQFP64 package.
There is such a wide variety of SPI peripheral hardware out there -- ethernet
NICs, display drivers, UARTs, SD cards, etc. Tons of stuff. The wire protocol
is essentially the same in every case.
Maybe one solution to this and other peripheral requirements would be a
standard SPI master board. The one board could host one or more SPI busses,
and each SPI bus could have multiple chip selects to support multiple devices
on the same bus.
A 5x2 0.1" header could deliver 5V, 3.3V, GND, CS, MISO, MOSI, CLK and maybe
also a few misc signals -- eg a couple of GPIOs one of which might support
interrupting the host processor.
The SPI master board could have a row of these standard headers and space to
mount a daughterboard on top of each -- you could either mount the peripheral
on a daughterboard directly to the card, or plug an IDC ribbon cable in and
run it off to the peripheral board elsewhere.
As well as standardising the SPI expansion header we could also standardise
the SPI bus master registers exposed to the host processor. Then a variety of
technologies (CPLD, FPGA, propeller chip, etc) could be used to implement the
SPI master device. I suppose the registers would need to allow the host to
program the bus clock speed, assert/deassert the various chip selects, write
a byte to the bus and read back the byte received during the last transfer. A
fancy implementation might include a FIFO to keep the bus busy, or perhaps
even DMA so the CPU can get on with other things during SPI transfers.
Will
Post by douglas_goodallThe 3C509 was a real champion, but the drivers are not open source, so I
don't know it writing interface software will be a problem. I do remember
that the board had on-board buffering which would be good in a retro
design. Best of luck.
Post by Nikolay DimitrovGents,
I wanted to share some thought of mine about using Ethernet for retro
computers. There's a company that offers such type modules, which can be
easily integrated for parallel buses, like ISA & ECB (I don't work for
Olimex).
https://www.olimex.com/Products/Modules/Ethernet/CS8900A-H/
https://www.olimex.com/Products/Modules/Ethernet/DM9000E-H/
https://www.olimex.com/Products/Modules/Ethernet/MOD-ENC624J600/
https://www.olimex.com/Products/Modules/Ethernet/MOD-ENC28J60/
https://www.olimex.com/Products/Modules/Ethernet/ENC28J60-H/
There are also the RTL8019 & 3C509 ISA cards (from the good old days),
but I haven't thought on the idea for ECB-ISA bridge.
If you have some ideas or progress on this topic, would be great to
share with the rest of us.
Regards,
Nikolay
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/d/optout.
_________________________________________________________________________
"Carpe post meridiem" http://sowerbutts.com
(m=-1;m<7;putchar(m++/6&c%3/2?10:s[c]-31&1<<m?42:32));}
--
You received this message because you are subscribed to a topic in the Google Groups "N8VEM" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/n8vem/4Gp-SUz_Yes/unsubscribe.
Visit this group at http://groups.google.com/group/n8vem.
For more options, visit https://groups.google.com/d/optout.