This is the mail archive of the ecos-discuss@sources.redhat.com 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: Spi Drivers


>>>>> "Roman" == Rycerz Roman-G11565 <roman.rycerz@motorola.com> writes:

    Roman>     I have downloaded the spi driver package, post here
    Roman>     some time ago. While I have no trouble building it, I
    Roman>     do have some general comments and questions
 
    Roman>     I think I understand what its doing and how it gets
    Roman>     started, but the question is... why does it not follow
    Roman>     the general i/o development template. device name,
    Roman>     lookup read/write...

Actually, I believe the majority of eCos devices don't follow the
open/read/write/close model. Disks, fileio, and serial do. Flash can
use the model, but there is also a flash-specific API which can be
more efficient. USB-slave can use the model but again there is a
USB-specific API which is what gets used in practice. Ethernet, PCI,
PCMCIA, wallclock, and watchdog are always accessed via their own
APIs, never via open/read/write/close.

One specific problem with SPI is that there is no distinction between
read and write operations. Any time you transfer data to a device on
the SPI bus you will also get data back. Any time you try to read data
from a device on the SPI bus you must also send it the same amount of
data. While designing the SPI bus I did come across an embedded Linux
SPI driver based on open/read/write/close and did not like how it
operated. For example to read some data from a device you first had to
perform a write(), and during that operation the driver would cache
the data coming back from the device. A subsequent read() call would
extract the cached data. Compared with the eCos SPI API that meant an
extra copy operation, plus the driver would need extra memory for the
cache.

There were other complications. An SPI-specific API just made more
sense.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

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