This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: bugs on spi API
- From: Bart Veer <bartv at ecoscentric dot com>
- To: rainti_1212 at hotmail dot com
- Cc: ecos-discuss at sources dot redhat dot com
- Date: Tue, 26 Jul 2005 19:52:03 +0100 (BST)
- Subject: Re: [ECOS] bugs on spi API
- References: <BAY13-F299C27DC9052461241565C99CD0@phx.gbl>
>>>>> "liang" == liang rainti <rainti_1212@hotmail.com> writes:
liang> i am writing a qspi drivers on mcf5272 for eCos, the qspi
liang> has a character:read and write in a transfer at one time.
liang> Referering generic SPI API, cyg_spi_transfer( ) function
liang> can read spi device a transfer at one time or write that.
liang> But read operation and write operation can not be finished
liang> at the same time in the transfer( ) function.
I am not sure what you are getting at here. The nature of SPI is such
that on every clock tick a bit goes out to the device and a bit comes
back from the device. There is no concept of separate reads and
writes, both happen at the same time.
liang> eg. A typical transaction might involve the following.
liang> First a command should be sent to the device, consisting of
liang> four bytes. The device will then respond with a single
liang> status byte, zero for failure, non-zero for success. If
liang> successful then the device can accept another n bytes of
liang> data, and will generate a 2-byte response including a
liang> checksum. The device's chip select should remain asserted
liang> throughout. The code for this would look something like:
There are a number of ways to code the example you describe. One
approach would be:
cyg_uint8 command[5];
cyg_uint8 status[5];
...
cyg_spi_transaction_begin(&spi_dev);
cyg_spi_transaction_transfer(&spi_dev, 0, 5, command, status, 0);
if ( status[4] ) {
...
} else {
cyg_spi_transaction_tick(&spi_dev, 0, 1);
}
cyg_spi_transaction_end();
The first cyg_spi_transaction_transfer() sends the command and reads
back the status in a single operation involving 5 bytes worth of SPI
clock ticks.
A slightly unfortunate aspect of this example you need to fill a dummy
value for command[4] and provide space for 4 unused reply bytes before
the status byte. The SPI bus driver has no way of knowing which
outgoing or incoming bytes are significant so they all have to be
supplied by higher-level code. With your device there may not be any
overlap between the outgoing and incoming data, but that is not
necessarily true of other SPI devices.
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