This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Spi Drivers
- From: Bart Veer <bartv at ecoscentric dot com>
- To: roman dot rycerz at motorola dot com
- Cc: ecos-discuss at sources dot redhat dot com
- Date: Tue, 11 Jan 2005 21:16:11 +0000 (GMT)
- Subject: Re: [ECOS] Spi Drivers
- References: <5D454811D0A1D711A12A00065BF36FAD08B9E47B@il06exm11>
>>>>> "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