This is the mail archive of the
mailing list for the eCos project.
Semantics of cyg_spi_transaction_tick?
- From: Stanislav Meduna <stano at meduna dot org>
- To: eCos Discussion <ecos-discuss at ecos dot sourceware dot org>
- Date: Sun, 21 Jun 2009 13:42:18 +0200
- Subject: [ECOS] 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
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
- 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: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss