This is the mail archive of the 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]

Semantics of cyg_spi_transaction_tick?


the docs state that

  If the device requires additional clock ticks in the middle
  of a transaction without being selected, cyg_spi_transaction_tick
  can be used. This will drop the device's chip select if necessary,
  then generate the appropriate number of ticks. The arguments
  are the same as for cyg_spi_tick.

This does not correspond to what the present SPI drivers do;
they state that they do not touch the chip select.

My problem is that the protocol of the dataflash device
I am using returns a byte specifying the number of following
data, that can be either zero, or can fit in the specified
buffer, or the user supplied a buffer of insufficient length.

So I read the number of the present data with
  cyg_spi_transaction_transfer(..., false);
and now I can have three cases

- no further data. I am done and need to simply deassert the CS.

- additional data and I have place for them - I just read
  them using
    cyg_spi_transaction_transfer(..., true);

- insufficient buffer - I should tick the device to throw the
  data away, deselect and return error to the caller.

>From what I read in the code I can throw the unused data using
cyg_spi_transaction_tick (which does not touch the CS) and
rely on cyg_spi_transaction_end to deassert the CS; however,
this does not correspond with the documentation. Can I rely
on what the code does, or is it possible that another SPI
driver implements it another way?


Before posting, please read the FAQ:
and search the list archive:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]