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
