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


Bart

	Thanks..... That's just what I was looking for....


Roman


-----Original Message-----
From: Bart Veer [mailto:bartv@ecoscentric.com] 
Sent: Tuesday, January 11, 2005 3:16 PM
To: Rycerz Roman-G11565
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] 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]