[ECOS] Ethernet on top of SPI

[ECOS] Ethernet on top of SPI

[Ilija Stanislevik]

Hi,

We are developing hardware based on STM32. For Ethernet we use
Microchip's ENC424J600, connected on one of the STM32's SPI buses.

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.

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.

Also, I have found no provision to refer SPI driver by device name,
another reason to stick the Ethernet driver to specific SPI hardware.

Am I right with above conclusions? Of course, if there is no other
solution, we will live with an Ethernet driver married to our SPI hardware.

Anyway, are there any rules/directions on SPI's API regarding hardware
independence?

Thank you,

Ilija Stanislevik

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

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

Re: [ECOS] Ethernet on top of SPI

[Mandeep Sandhu]

On Wed, Oct 14, 2009 at 12:27 PM, Ilija Stanislevik <ilijas@siva.com.mk> wrote:
> Hi,
>
> We are developing hardware based on STM32. For Ethernet we use
> Microchip's ENC424J600, connected on one of the STM32's SPI buses.
>
> 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.

We have a similar requirement, where we are going to connect a
wireless ethernet controller, over SPI,  to the AT91SAM7X SoC.

Do you have plans to conribute back your ethernet-over-SPI driver?

Regards,
-mandeep

>
> 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.
>
> Also, I have found no provision to refer SPI driver by device name,
> another reason to stick the Ethernet driver to specific SPI hardware.
>
> Am I right with above conclusions? Of course, if there is no other
> solution, we will live with an Ethernet driver married to our SPI hardware.
>
> Anyway, are there any rules/directions on SPI's API regarding hardware
> independence?
>
> Thank you,
>
> Ilija Stanislevik
>
> SIvA doo
> ul. Zejnel Ajdini 5
> MK-1060 Skopje
> Macedonia
>
> --
> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
>
>

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

Re: [ECOS] Ethernet on top of SPI

[Bart Veer]

>>>>> "Ilija" == Ilija Stanislevik <ilijas@siva.com.mk> writes:

    Ilija> We are developing hardware based on STM32. For Ethernet we
    Ilija> use Microchip's ENC424J600, connected on one of the STM32's
    Ilija> SPI buses.

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

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

    Ilija> Also, I have found no provision to refer SPI driver by
    Ilija> device name, another reason to stick the Ethernet driver to
    Ilija> specific SPI hardware.

    Ilija> Am I right with above conclusions? Of course, if there is
    Ilija> no other solution, we will live with an Ethernet driver
    Ilija> married to our SPI hardware.

    Ilija> Anyway, are there any rules/directions on SPI's API
    Ilija> regarding hardware independence?

There are two entities to consider: the cyg_spi_device object for the
ENC424J600, and the code which uses that object i.e. the ethernet
driver.

The ethernet driver should not care exactly how the SPI device is
wired up on any given board, e.g. how the chip select is handled. All
it should care about is that there is a cyg_spi_device object
somewhere in the system which can be used via the SPI API to talk to
the chip.

The code which instantiates the cyg_spi_device object, typically the
platform HAL, should not care about how other code uses the device.
That other code may be your driver, some other driver, or application
code directly. It should simply make sure that the cyg_spi_device
object contains all the information needed by the SPI bus driver to
allow interaction with the physical device, i.e. polarity and phase
info, chip select wiring details, etc. The details of this will depend
on the SPI bus driver. There should be no need to change any of these
settings by configury or at run-time.

So, the way things are expected to work is that the platform HAL will
instantiate a cyg_spi_device object with a well-known name, e.g.
cyg_spi_enc424j600_0. All the hardware-specific details are encoded
inside that object. The ethernet driver will expect that something
else provides an object cyg_spi_enc424j600_0 If that expectation is
not met then you'll get a bunch of errors at compile-time. If you
prefer you can get the errors at configure-time by having a CDL
interface and constraints on that interface. The ethernet driver does
not need to worry about any of the hardware-specific details.

If you take a look at devs/disk/generic/mmc, that code already works
along similar lines. The driver looks for a cyg_spi_device
cyg_spi_mmc_dev0. It is up to the platform HAL (usually) to
instantiate that object with the right settings.

Bart

-- 
Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.

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

Re: [ECOS] Ethernet on top of SPI

[Chris Holgate]

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.

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

CYG_DEVS_FLASH_SPI_M25PXX_DRIVER (
    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
driver.

Chris.

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

Re: [ECOS] Ethernet on top of SPI

[Ilija Stanislevik]

Mandeep Sandhu wrote:
> Do you have plans to conribute back your ethernet-over-SPI driver?
>   
Yes, this is in our plans, but right now I can not promise meeting any
deadline.

Ilija Stanislevik

SIvA doo
Macedonia



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

Re: [ECOS] Ethernet on top of SPI

[Ilija Stanislevik]

Bart Veer wrote
> The code which instantiates the cyg_spi_device object, typically the
> platform HAL, should not care about how other code uses the device.
> That other code may be your driver, some other driver, or application
> code directly. It should simply make sure that the cyg_spi_device
> object contains all the information needed by the SPI bus driver to
> allow interaction with the physical device, i.e. polarity and phase
> info, chip select wiring details, etc. 
> The details of this will depend
> on the SPI bus driver. There should be no need to change any of these
> settings by configury or at run-time.
>   
> So, the way things are expected to work is that the platform HAL will
> instantiate a cyg_spi_device object with a well-known name, e.g.
> cyg_spi_enc424j600_0. All the hardware-specific details are encoded
> inside that object. The ethernet driver will expect that something
> else provides an object cyg_spi_enc424j600_0 If that expectation is
> not met then you'll get a bunch of errors at compile-time. If you
> prefer you can get the errors at configure-time by having a CDL
> interface and constraints on that interface. The ethernet driver does
> not need to worry about any of the hardware-specific details.
>   
My idea is to produce an Ethernet-on-top-of-SPI driver which can be used
on ANY particular SPI driver or, in other words, I wish if the low-level
Ethernet driver does not care which SPI driver is below. This way I (or
anyone) will be able to use the same low-level Ethernet driver with any
SPI driver, without going into depths of specific SPI implementation. 
> If you take a look at devs/disk/generic/mmc, that code already works
> along similar lines. The driver looks for a cyg_spi_device
> cyg_spi_mmc_dev0. It is up to the platform HAL (usually) to
> instantiate that object with the right settings.
>
> Bart
>
>   
Thank you for the comprehensive explanation and for directions. I find
it very useful.

Going to dig some code and manuals,

Ilija Stanislevik

SIvA doo
Macedonia


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

Re: [ECOS] Ethernet on top of SPI

[Ilija Stanislevik]

Chris Holgate wrote:
> 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.
>   
> .
> .
> .
>   

Thank you for the thorough explanation and for the advices on
STM3210E-EVAL. Both are very useful.

Ilija Stanislevik

SIvA doo


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