[ECOS] Ethernet on top of SPI

Chris Holgate chris@zynaptic.com
Wed Oct 14 11:10:00 GMT 2009

Ilija Stanislevik wrote:

> Our intention is to develop an Ethernet driver for ENC424J600 on top of
> the SPI driver. We also intend to make this Ethernet-over-SPI general
> regarding SPI hardware, but it seems that there are some obstacles there.

An interesting project - that looks like quite a neat device.

> The polarity and phase of STM32's SPI should be adjusted to the
> requirements of ENC424J600. In the SPI's API there is no get/set-config
> support for this. The configtool has no provision to set this either.
> The only way to adjust this is to poke the driver's private data
> structure. This means that our Ethernet driver must be written
> specifically for STM32's SPI.

This isn't actually the case, since the clock polarity is set by the SPI
_device_ data structure, which should be passed to the driver by the
application.  Unfortunately, when you are working within the context of
another API (ie, the Ethernet driver API) there is not always an obvious
way to pass this information in from the application code.

I wrapped most of the details of setting up SPI device data structures
for the STM32 in macros.  This arguably makes it easier to use than
other SPI drivers which don't have the macros, since the application
code ends up looking something like the following (example for the
M25Pxx SPI flash driver running on the STM3210E-EVAL board).

// Create the SPI device configuration and attach it to the correct
// SPI bus.

    m25pxx_spi_device, 1, 0, false, 0, 0, 25000000, 1, 1, 1

// Create and initialise an instance of the M25Pxx driver using
// the SPI device configuration.

    m25pxx_flash_device, 0, &m25pxx_spi_device

Within the flash V2 API it is possible to pass in the SPI device data
structure as an anonymised driver data structure during initialisation.
 I'm not sure if it is possible to do something similar within the
context of the Ethernet driver API.  If not, I'd recommend creating your
own driver initialisation function which accepts the SPI device data
structure as a parameter and then use a similar macro to the M25Pxx one
to ensure that it is called during startup for each instantiation of the


P.S. If you're using the STM3210E-EVAL board, I found it very handy to
use the QST connector as a SPI expansion header.

P.P.S. There is a bit of a gotcha with the STM32 SPI implementation, in
that all devices on the bus need to have the same clock polarity and
this must be matched with a suitable pullup or pulldown resistor on the
clock line.

Christopher J. Holgate

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

Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

More information about the Ecos-discuss mailing list