Ethernet over SPI driver for ENC424J600

Ethernet over SPI driver for ENC424J600

[Ilija Stanislevik]

Hi,

The work on the driver is pretty much done. I intend to spend a day or
two on additional testing before publishing the code.

1. Please suggest a place where I could put the code?
2. In what form I should give the files?

Ilija Stanislevik

Re: Ethernet over SPI driver for ENC424J600

[John Dallaway]

Hi Ilija

Ilija Stanislevik wrote:

> The work on the driver is pretty much done.

Great!

> I intend to spend a day or
> two on additional testing before publishing the code.
> 
> 1. Please suggest a place where I could put the code?
> 2. In what form I should give the files?

It's probably easiest to create a Bugzilla report for this. Attach the
new package as a .tar.bz2 file. Attach your changes to ecos.db and to
existing packages (if any) in the form of a plain text patch file. You
can generate the patch file using:

  cd packages
  cvs -q diff -u5 > ecos.patch

John Dallaway
eCos maintainer

Re: Ethernet over SPI driver for ENC424J600

[Ilija Stanislevik]

Hi,

I just put the driver in a Bugzilla report:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000910

Awaiting comments,

Ilija Stanislevik



John Dallaway wrote:
> Hi Ilija
>
> Ilija Stanislevik wrote:
>
>   
>> The work on the driver is pretty much done.
>>     
>
> Great!
>
>   
>> I intend to spend a day or
>> two on additional testing before publishing the code.
>>
>> 1. Please suggest a place where I could put the code?
>> 2. In what form I should give the files?
>>     
>
> It's probably easiest to create a Bugzilla report for this. Attach the
> new package as a .tar.bz2 file. Attach your changes to ecos.db and to
> existing packages (if any) in the form of a plain text patch file. You
> can generate the patch file using:
>
>   cd packages
>   cvs -q diff -u5 > ecos.patch
>
> John Dallaway
> eCos maintainer
>   

Re: Ethernet over SPI driver for ENC424J600

[Ilija Stanislevik]

Hi,

There is still no reaction from the maintainers to the code we
contributed in February. Any schedule?

Ilija

Ilija Stanislevik wrote:
> Hi,
>
> I just put the driver in a Bugzilla report:
> http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000910
>
> Awaiting comments,
>
> Ilija Stanislevik
>
>
>   
-- 

Ilija Stanislevik
SIvA doo
ul. Mladinska 43 lok. 6
p.f. 53
MK-2400 Strumica
Macedonia

Re: Ethernet over SPI driver for ENC424J600

[Ross Younger]

> John Dallaway wrote:
>> net/lwip_tcpip/current/include/netif/ppp/ is a new directory. 
>> [...]  you need the "-d" switch when updating

Ilija Kocho wrote:
> Is this some "unwanted feature" of CVS? If yes one more reason to switch
> to new VCS.

CVS has always been that way: you never get new directories in a cvs update
unless you use the -d option. Those of us who have been working heavily with
it for upwards of a decade (!) find it works its way into our finger macros,
and/or create a .cvsrc with "update -d" (and maybe -P as well for neatness).


Ross

-- 
Embedded Software Engineer, eCosCentric Limited.
Barnwell House, Barnwell Drive, Cambridge CB5 8UU, UK.
Registered in England no. 4422071.                  www.ecoscentric.com

Re: Ethernet over SPI driver for ENC424J600

[Ilija Kocho]

John Dallaway wrote:
> net/lwip_tcpip/current/include/netif/ppp/ is a new directory. Does it
> exist in your local CVS checkout? For avoidance of doubt, you need the
> "-d" switch when updating:
>
>    cd packages
>    cvs -q update -d -P net/lwip_tcpip io/eth
>   
Is this some "unwanted feature" of CVS? If yes one more reason to switch
to new VCS.

// Ilija

Re: Ethernet over SPI driver for ENC424J600

[Ilija Stanislevik]

Hi John,
> net/lwip_tcpip/current/include/netif/ppp/ is a new directory. Does it
> exist in your local CVS checkout? For avoidance of doubt, you need the
> "-d" switch when updating:
>
>    cd packages
>    cvs -q update -d -P net/lwip_tcpip io/et
Your suggestion solved the problem. Thank you.

Ilija Stanislevik

Re: Ethernet over SPI driver for ENC424J600

[John Dallaway]

Hi Ilija

Ilija Stanislevik wrote:

> home/iko/current_ecos/ecos/packages/net/lwip_tcpip/current/src/ecos/simple.c:72:27:
>     error: netif/ppp/ppp.h: No such file or directory

[ snip ]

> Any suggestions how to get on track?

net/lwip_tcpip/current/include/netif/ppp/ is a new directory. Does it
exist in your local CVS checkout? For avoidance of doubt, you need the
"-d" switch when updating:

   cd packages
   cvs -q update -d -P net/lwip_tcpip io/eth

John Dallaway
eCos maintainer

Re: Ethernet over SPI driver for ENC424J600

[Simon Kallweit]

Ilija Stanislevik wrote:
> Hi,
> 
> I tested the driver at Ethernet level: sending and receiving Ethernet
> packets, setting and getting ESA, etc. The tests have been done on
> STM3210E evaluation board (ST cortex M3 processor). Now I am trying to
> perform tests with lwip stack.
> 
> First I did some initial testing with ecos3.0. Using configtool I chose
> ecos3.0 repository, ST STM3210E EVAL board template and lwip_eth package
> instead of default. I added my driver source and CDL files to my local
> ecos3.0 repository. Everything builds fine.
> 
> Then I decided to try the lwip from the CVS. Using configtool I chose
> current ecos repository (taken from CVS  on February 2. 2010), ST
> STM3210E EVAL board template and lwip_eth package. I added my driver
> source and CDL files to my local repository. Building library does not
> yield:
> 
>     .
>     .
> 
> home/iko/current_ecos/ecos/packages/net/lwip_tcpip/current/src/ecos/simple.c:72:27:
>     error: netif/ppp/ppp.h: No such file or directory
> 
> /home/iko/current_ecos/ecos/packages/net/lwip_tcpip/current/src/ecos/simple.c:73:28:
>     error: netif/ppp/chat.h: No such file or directory
> 
> /home/iko/current_ecos/ecos/packages/net/lwip_tcpip/current/src/ecos/simple.c:190:8:
>     warning: multi-line comment
>     make[1]: Leaving directory
> 
> `/home/iko/Agenda/Energ/Ramnenje/Dizajn/STM32/EVALB/ecos/test_current_ecos_build/net/lwip_tcpip/current'
>     make[1]: *** [src/ecos/simple.o.d] Error 1
>     make: Leaving directory
> 
> `/home/iko/Agenda/Energ/Ramnenje/Dizajn/STM32/EVALB/ecos/test_current_ecos_build'
>     make: *** [build] Error 2
> 
> Any suggestions how to get on track?

Hmm, I just did the following, using the latest CVS repository:

ecosconfig new stm3210e_eval lwip_eth
ecosconfig tree
make
make -C net/lwip_tcpip/current/ tests

Everything builds, as far as I can see. Try to recreate your tree, or 
start with a clean configuration again.

Simon

Ethernet over SPI driver for ENC424J600

[Ilija Stanislevik]

Hi,

I tested the driver at Ethernet level: sending and receiving Ethernet
packets, setting and getting ESA, etc. The tests have been done on
STM3210E evaluation board (ST cortex M3 processor). Now I am trying to
perform tests with lwip stack.

First I did some initial testing with ecos3.0. Using configtool I chose
ecos3.0 repository, ST STM3210E EVAL board template and lwip_eth package
instead of default. I added my driver source and CDL files to my local
ecos3.0 repository. Everything builds fine.

Then I decided to try the lwip from the CVS. Using configtool I chose
current ecos repository (taken from CVS  on February 2. 2010), ST
STM3210E EVAL board template and lwip_eth package. I added my driver
source and CDL files to my local repository. Building library does not
yield:

    .
    .

home/iko/current_ecos/ecos/packages/net/lwip_tcpip/current/src/ecos/simple.c:72:27:
    error: netif/ppp/ppp.h: No such file or directory

/home/iko/current_ecos/ecos/packages/net/lwip_tcpip/current/src/ecos/simple.c:73:28:
    error: netif/ppp/chat.h: No such file or directory

/home/iko/current_ecos/ecos/packages/net/lwip_tcpip/current/src/ecos/simple.c:190:8:
    warning: multi-line comment
    make[1]: Leaving directory

`/home/iko/Agenda/Energ/Ramnenje/Dizajn/STM32/EVALB/ecos/test_current_ecos_build/net/lwip_tcpip/current'
    make[1]: *** [src/ecos/simple.o.d] Error 1
    make: Leaving directory

`/home/iko/Agenda/Energ/Ramnenje/Dizajn/STM32/EVALB/ecos/test_current_ecos_build'
    make: *** [build] Error 2

Any suggestions how to get on track?

Ilija Stanislevik

Re: Ethernet over SPI driver for ENC424J600

[Chris Holgate]

Hi Ilija,

Ilija Stanislevik wrote:

> The driver makes use of external interrupt (from one of the general
> purpose I/O pins in case of STM32) to get interrupt request from
> Ethernet chip. I've found that, in eCos 3.0 implementation for STM32,
> the cyg_drv_interrupt_... functions don't set up the AFIO_EXTICRx
> register, which is necessary in order to connect particular I/O pin with
> the EXTI logic. The driver can always arrange for this outside the
> standard functions, but such an approach produces a driver which is tied
> not only to Ethernet chip, but to platform too.

I think that it's the general case that when using external interrupts
there will be some form of platform specific setup, so it's good idea to
isolate this anyway.

> Another solution is external function provided from application within
> the private data structure, to be called from drivers init function. The
> driver is still platform-independent and the application programmer
> should take care for marshaling of interrupt.

Rather than adding a callback in the private data structure, you can add
the external interrupt setup to your platform specific initialisation
code and then just include the interrupt vector ID in the private area
of your SPI device data structure.  Once the generic driver knows the
vector ID it can then take care of managing the interrupt itself.

Chris.

-- 
Christopher J. Holgate

Thinking Of The Future @ Zynaptic Limited (www.zynaptic.com)

Ethernet over SPI driver for ENC424J600

[Ilija Stanislevik]

Hi all,

I am developing the driver on STM32 platform and my intention is to make
it independent of platform.

The driver makes use of external interrupt (from one of the general
purpose I/O pins in case of STM32) to get interrupt request from
Ethernet chip. I've found that, in eCos 3.0 implementation for STM32,
the cyg_drv_interrupt_... functions don't set up the AFIO_EXTICRx
register, which is necessary in order to connect particular I/O pin with
the EXTI logic. The driver can always arrange for this outside the
standard functions, but such an approach produces a driver which is tied
not only to Ethernet chip, but to platform too.

I wish if some of cyg_drv_interrupt_...() could arrange the whole
external interrupt signal train based solely on the interrupt vector
given to it. This is possible for STM32, since interrupt vectors bear
unambiguous info on the assigned GPIO pin. Are there plans to provide
such functionality?

Another solution is external function provided from application within
the private data structure, to be called from drivers init function. The
driver is still platform-independent and the application programmer
should take care for marshaling of interrupt.

Thoughts or suggestions?

Ilija Stanislevik

Re: Ethernet over SPI driver for ENC424J600

[John Dallaway]

Ilija Stanislevik wrote:

> John Dallaway wrote:
> 
>> The main ideas behind project registration are to encourage
>> collaboration on new eCos components, to minimise duplicated effort and
>> to allow for early feedback from the eCos maintainers. With this mind,
>> we would expect:
>>
>> a) contribution of the code to eCos CVS when it is ready (subject to
>> review by the eCos maintainers and copyright assignment to FSF)
>>
>> b) sharing of your pre-release code with others in the eCos community on
>> request
>>
>> c) responsiveness to feedback from the community
> 
> Hi John,
> 
> We decided to register this project.

Great. Thank you, Ilija.

John Dallaway

Re: Ethernet over SPI driver for ENC424J600

[Ilija Stanislevik]

John Dallaway wrote:
> The main ideas behind project registration are to encourage
> collaboration on new eCos components, to minimise duplicated effort and
> to allow for early feedback from the eCos maintainers. With this mind,
> we would expect:
>
> a) contribution of the code to eCos CVS when it is ready (subject to
> review by the eCos maintainers and copyright assignment to FSF)
>
> b) sharing of your pre-release code with others in the eCos community on
> request
>
> c) responsiveness to feedback from the community
Hi John,

We decided to register this project.

Ilija

Re: Ethernet over SPI driver for ENC424J600

[Sergei Gavrikov]

Ilija Kocho wrote:

> John Dallaway wrote:

> >Sergei Gavrikov wrote:
> >>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.
> >
> >In theory, of course, you are correct. The network abstractions
> >should ensure compatibility between any ethernet device driver and
> >any TCP/IP stack. But in practice, testing can reveal all manner of
> >issues which no-one was expecting.

Hello Guys,

Agreed. I just thought about those `eth_hwr_funs' for new ENC chip:
http://ecos.sourceware.org/docs-latest/ref/io-eth-drv-generic1.html
and then for start a test-path would be one from

    io/eth
    `-- src
        |-- lwip
        |-- net
        |-- **newlwip**
        `-- stand_alone

Of course, that will be a choice of hardware keepers. But, looking on
the picture I see why Alex suggested to go by a way without asterisks,
because, "...testing can reveal all manner of issues which no-one was
expecting" :-)

> This is our first eCos driver of this kind and we take the
> abstraction and stack independence for granted. It may save us some
> effort and help bring the driver sooner if somebody more experienced
> points out potential potholes.

Ilija, which hardware (board) do you plan to use in a development? Is
that STM3210E-EVAL? Certainly, if target has not a lot of RAM, then
choices can be `lwip' derivatives then. On the other hand, two new
fresh projects (yours enc_eth and Simon's lwip-1.3.1) would help each
other in a self testing. Keep up the good work.

Regards,
Sergei

Re: Ethernet over SPI driver for ENC424J600

[Ilija Kocho]

John Dallaway wrote:
> Hi Sergei
>
> Sergei Gavrikov wrote:
>
>   
>> 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.
>>     
>
> In theory, of course, you are correct. The network abstractions should
> ensure compatibility between any ethernet device driver and any TCP/IP
> stack. But in practice, testing can reveal all manner of issues which
> no-one was expecting.
>   
This is our first eCos driver of this kind and we take the abstraction 
and stack independence for granted. It may save us some effort and help 
bring the driver sooner if somebody more experienced points out 
potential potholes.

Regards
Ilija Kocho

Re: Ethernet over SPI driver for ENC424J600

[John Dallaway]

Hi Sergei

Sergei Gavrikov wrote:

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

In theory, of course, you are correct. The network abstractions should
ensure compatibility between any ethernet device driver and any TCP/IP
stack. But in practice, testing can reveal all manner of issues which
no-one was expecting.

We have a port of the lwIP 1.3.1 stack in development and it would
certainly be useful to test new ethernet drivers against this stack.
However, I am _not_ suggesting that the other stacks should now be
neglected.

John Dallaway

Re: Ethernet over SPI driver for ENC424J600

[Sergei Gavrikov]

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

Re: Ethernet over SPI driver for ENC424J600

[John Dallaway]

Hi Ilija

Ilija Stanislevik wrote:

> I have already harnessed the Microchip board with ENC624J600 to my
> STM3210E-EVAL. The 424 and 624 chips are identical regarding the SPI
> functionality. I plan to do most of the development on 624, till our
> hardware with 424 gets ready.

Great. Hopefully your driver will correctly initialise both parts for
operation in SPI mode with no extra effort.

> We intend to use lwip.

That's good. I envisage that the lwIP 1.3.1 stack will become popular
with eCos developers.

> Please explain what will be our obligations if we decide to register
> this project.

The main ideas behind project registration are to encourage
collaboration on new eCos components, to minimise duplicated effort and
to allow for early feedback from the eCos maintainers. With this mind,
we would expect:

a) contribution of the code to eCos CVS when it is ready (subject to
review by the eCos maintainers and copyright assignment to FSF)

b) sharing of your pre-release code with others in the eCos community on
request

c) responsiveness to feedback from the community

In fact, the lwIP 1.3.1 port is a good example of how the community can
work together in this way. There are several people already making use
of this code.

John Dallaway

Re: Ethernet over SPI driver for ENC424J600

[Alex Schuilenburg]

Hi Ilija


John Dallaway wrote on 2009-10-26 09:05:
> Hi Ilija
>
> Ilija Stanislevik wrote:
>
>   
>> Dear fellows,
>>
>> I use this opportunity to announce our development project. It is a
>> driver for Microchip's ENC424J600 Ethernet controller.
>>
>> My company's goal is to obtain a low level Ethernet driver which will
>> use standard SPI support to communicate with the Ethernet chip. The
>> development is underway on STM3210E-EVAL board. We will be glad if we
>> succeed to make it independent from platform and SPI hardware.
>>
>> Further, we plan to contribute the result of this development, as
>> proposed in http://ecos.sourceware.org/contrib.html. Please advise us on
>> the next step in this direction.
>>     
>
> This is great news. Thank you for letting the eCos community know of
> your plans at an early stage.
>
> This driver could be useful for many eCos developers who need to add
> ethernet to an existing hardware design. I note that Microchip offers a
> daughter board which includes the (similar) ENC624J600 and should make
> it easy for others to start experimenting with these parts:
>
> http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en543132
>
> 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/
>
> lwIP is a good fit for eCos and I hope lwIP 1.3.1 will be integrated in
> eCos CVS soon.
>   
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
than do your initial development on the newer lwIP port which is still
undergoing testing. That way at least you will ensure you are debugging
your own code initially, rather than also somebody else's.

Once you are happy with the stability of the your device driver, please
also test it against Simon's lwIP 1.3.1 port as well since it obviously
needs testers and it will most likely replace the older lwIP stack. 

Please note that I am not suggesting that Simon's 1.3.1 port is unstable
or broken in any way, just that it is still relatively new and unknown
and that you ought to be aware of this when choosing which tcpip stack
to initially test your driver against.

Thanks for your notice and we look forward to seeing your contribution soon.

-- Alex Schuilenburg

Managing Director/CEO                                eCosCentric Limited
www.ecoscentric.com

Re: Ethernet over SPI driver for ENC424J600

[Ilija Stanislevik]

Hi John,

I have already harnessed the Microchip board with ENC624J600 to my
STM3210E-EVAL. The 424 and 624 chips are identical regarding the SPI
functionality. I plan to do most of the development on 624, till our
hardware with 424 gets ready.

We intend to use lwip.

I have sent the requirement for assignment form to gnu.org.

Please explain what will be our obligations if we decide to register
this project.

Ilija Stanislevik

Re: Ethernet over SPI driver for ENC424J600

[John Dallaway]

Hi Ilija

Ilija Stanislevik wrote:

> Dear fellows,
> 
> I use this opportunity to announce our development project. It is a
> driver for Microchip's ENC424J600 Ethernet controller.
> 
> My company's goal is to obtain a low level Ethernet driver which will
> use standard SPI support to communicate with the Ethernet chip. The
> development is underway on STM3210E-EVAL board. We will be glad if we
> succeed to make it independent from platform and SPI hardware.
> 
> Further, we plan to contribute the result of this development, as
> proposed in http://ecos.sourceware.org/contrib.html. Please advise us on
> the next step in this direction.

This is great news. Thank you for letting the eCos community know of
your plans at an early stage.

This driver could be useful for many eCos developers who need to add
ethernet to an existing hardware design. I note that Microchip offers a
daughter board which includes the (similar) ENC624J600 and should make
it easy for others to start experimenting with these parts:

http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en543132

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/

lwIP is a good fit for eCos and I hope lwIP 1.3.1 will be integrated in
eCos CVS soon.

At some point, you will need to complete the FSF copyright assignment
paperwork. All contributors to your driver will need to make a copyright
assignment. I would recommend getting this sorted out early to avoid
delays when the driver is ready. Full instructions are available at:

  http://ecos.sourceware.org/assign.html

Finally, if you are able to collaborate with the wider eCos community on
this project, we can add it to the list of registered projects. Ref:

  http://ecos.sourceware.org/contrib.html#registered

John Dallaway

Re: Ethernet over SPI driver for ENC424J600

[Ilija Stanislevik]

Hi Krishnan,

Yes, our application is humble enough to be satisfied with the maximum
affordable SPI bit rate, which is 14Mbps in case of ENC424J600. The bit
rate at Ethernet side can be either 10M or 100M, depending on what
pleases the network.

Ilija


Mr navaneethan krishnan wrote:
> Hi LLija
> Peoples were moving to 1gig network and with less thru put on spi even
> 100mbps itself will be difficult.
> What is an application that you want to try with SPi+ethernet
> Have you done data thruput calculations when used with SPi +ethernet.
> or , definitly needed, we appriciate your effort which will make cost
> less for ethernet core in the chip.
> K.Navaneetha Krishnan
>
>
> --- On *Mon, 10/26/09, Ilija Stanislevik /<ilijas@siva.com.mk>/* wrote:
>
>
>     From: Ilija Stanislevik <ilijas@siva.com.mk>
>     Subject: Ethernet over SPI driver for ENC424J600
>     To: ecos-devel@ecos.sourceware.org
>     Date: Monday, October 26, 2009, 6:51 AM
>
>     Dear fellows,
>
>     I use this opportunity to announce our development project. It is a
>     driver for Microchip's ENC424J600 Ethernet controller.
>
>     My company's goal is to obtain a low level Ethernet driver which will
>     use standard SPI support to communicate with the Ethernet chip. The
>     development is underway on STM3210E-EVAL board. We will be glad if we
>     succeed to make it independent from platform and SPI hardware.
>
>     Further, we plan to contribute the result of this development, as
>     proposed in http://ecos.sourceware.org/contrib.html. Please advise
>     us on
>     the next step in this direction.
>
>     Ilija Stanislevik
>     SIvA doo
>     ul. Zejnel Ajdini 5
>     MK-1060 Skopje
>     Macedonia
>
>

Ethernet over SPI driver for ENC424J600

[Ilija Stanislevik]

Dear fellows,

I use this opportunity to announce our development project. It is a
driver for Microchip's ENC424J600 Ethernet controller.

My company's goal is to obtain a low level Ethernet driver which will
use standard SPI support to communicate with the Ethernet chip. The
development is underway on STM3210E-EVAL board. We will be glad if we
succeed to make it independent from platform and SPI hardware.

Further, we plan to contribute the result of this development, as
proposed in http://ecos.sourceware.org/contrib.html. Please advise us on
the next step in this direction.

Ilija Stanislevik
SIvA doo
ul. Zejnel Ajdini 5
MK-1060 Skopje
Macedonia