[ECOS] bugs on spi API

[ECOS] bugs on spi API

[liang rainti]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb2312; format=flowed, Size: 2149 bytes --]

hi,all,
  i am writing a qspi drivers on mcf5272 for eCos, the qspi has a 
character:read and write in a transfer at one time. Referering generic SPI 
API, cyg_spi_transfer( ) function can read  spi device a transfer at one 
time or write that. But read operation and write operation can not be 
finished at the same time in the transfer( ) function.

eg.
A typical transaction might involve the following. First a command
should be sent to the device, consisting of four bytes. The device
will then respond with a single status byte, zero for failure,
non-zero for success. If successful then the device can accept another
n bytes of data, and will generate a 2-byte response including a
checksum. The device's chip select should remain asserted throughout.
The code for this would look something like:

#include <cyg/io/spi.h>
#include <cyg/hal/hal_io.h>    // Defines the SPI devices

    cyg_spi_transaction_begin(hal_spi_eprom);
    // Interrupt-driven transfer, four bytes of command
   !!! cyg_spi_transaction_transfer(hal_spi_eprom, 0, 4, command, NULL, 0);
    // Read back the status
   !!! cyg_spi_transaction_transfer(hal_spi_eprom, 0, 1, NULL, status, 0);
    
Why not be 
cyg_spi_transaction_transfer(hal_spi_eprom,0,4,command,status,0)???  This 
will be OK??? I am wondering.
   if (!status[0]) {
        // Command failed, generate some extra ticks to drop the chip 
select
        cyg_spi_transaction_tick(hal_spi_eprom, 0, 1);
    } else {
        // Transfer the data, then read back the final status. The
        // chip select should be dropped at the end of this.
        cyg_spi_transaction_transfer(hal_spi_eprom, 0, n, data, NULL, 0);
        cyg_spi_transaction_transfer(hal_spi_eprom, 0, 2, NULL, status, 1);
        // Code for checking the final status should go here 
    }

_________________________________________________________________
ÓëÊÀ½ç¸÷µØµÄÅóÓѽøÐн»Á÷£¬Ãâ·ÑÏÂÔØ MSN Messenger:  
http://messenger.msn.com/cn 


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] bugs on spi API

[Bart Veer]

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