Re: Ethernet over SPI driver for ENC424J600

On Mon, Oct 26, 2009 at 11:46:13AM +0000, Alex Schuilenburg wrote:
> John Dallaway wrote on 2009-10-26 09:05:
> > Ilija Stanislevik wrote:
> >> Dear fellows,
> >>
> >> I use this opportunity to announce our development project. It is
> >> a driver for Microchip's ENC424J600 Ethernet controller.
[snip]
Thank you!
> > This is great news. Thank you for letting the eCos community know
> > of your plans at an early stage.
[snip]
> > Are you intending to use lwIP or the FreeBSD TCP/IP stack in your
> > project? Regardless, I would encourage you to verify correct
> > operation with Simon Kallweit's port of lwIP 1.3.1:
> >
> >   http://download.westlicht.ch/
[snip]
> I think it is fair to advise you of the risks involved in using the
> newer lwIP 1.3.1 stack and of more stable options available to you
> when developing new code for eCos.  Since you are developing a new
> device driver, I suggest you initially stick with the FreeBSD port
> (and optionally older lwIP port) which are known to work reliably,
> rather

Hello guys, may be I miss something but I thought that any Ethernet
eCos driver is enough abstract thing to manage ETH L2 and that does
not depend (well, depends a bit) on any next layer, e.g., a TCP/IP
implementation (RedBoot TCP/IP, *BSD, lwIP* stacks) even if the driver
uses another channel (SPI) to get a memory access to MAC buffers.  I
talk about generic io/eth/* stuff and..., well some kind of a future
devs/eth/mc/spi/* eth_drv_.* routines, for example.  Why do you "link"
ya L2 controller with some kind of the TCP/IP? I do not understand it
enough. Will it be able to use that driver w/out interrupts in a
polling mode, i.e. to use RedBoot's TCP/IP=GDB? If it won't be, well,
that is code limits, why the lwIP 1.X.X TCP/IP only then?

Thank you for any clarifications, Regards

Sergei