This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Ethernet on top of SPI


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]