This is the mail archive of the
mailing list for the eCos project.
Re: Semantics of cyg_spi_transaction_tick?
- From: Chris Holgate <chris at zynaptic dot com>
- To: Bart Veer <bartv at ecoscentric dot com>
- Cc: Stanislav Meduna <stano at meduna dot org>, ecos-discuss at ecos dot sourceware dot org
- Date: Mon, 22 Jun 2009 15:12:16 +0100
- Subject: Re: [ECOS] Semantics of cyg_spi_transaction_tick?
- References: <4A3E1C9A.firstname.lastname@example.org> <email@example.com>
Bart Veer wrote:
>>>>>> "Stanislav" == Stanislav Meduna <firstname.lastname@example.org> writes:
> Stanislav> Hi,
> Stanislav> the docs state that
> Stanislav> If the device requires additional clock ticks in the
> Stanislav> middle of a transaction without being selected,
> Stanislav> cyg_spi_transaction_tick can be used. This will drop
> Stanislav> the device's chip select if necessary, then generate
> Stanislav> the appropriate number of ticks. The arguments are
> Stanislav> the same as for cyg_spi_tick.
> Stanislav> This does not correspond to what the present SPI
> Stanislav> drivers do; they state that they do not touch the chip
> Stanislav> select.
> I am not sure which existing SPI drivers you are referring to. The
> documentation is correct: a tick means clock signals with no device
> selected. If a device is currently selected as part of a transaction,
> the chip select should be deasserted first. The tick functionality was
> incorporated into the API because of MMC cards, where the protocol
> requires clock ticks on the SPI bus with no data being transferred.
As far as I can tell, all the SPI drivers in the public CVS have this
behaviour. Certainly the AT91 does because I used it as a reference
when implementing the STM32 one. I think the same is also true for the
LPC driver. From the AT91 comments for the tick function:
// Transfer count zeros to the device - we don't touch the
// chip select, the device could be selected or deselected.
// It is up to the device driver to decide in wich state the
// device will be ticked.
If this is incorrect it looks as though some patches are required.
> Stanislav> From what I read in the code I can throw the unused
> Stanislav> data using cyg_spi_transaction_tick (which does not
> Stanislav> touch the CS) and rely on cyg_spi_transaction_end to
> Stanislav> deassert the CS; however, this does not correspond with
> Stanislav> the documentation. Can I rely on what the code does, or
> Stanislav> is it possible that another SPI driver implements it
> Stanislav> another way?
> In theory the correct way to handle this is to use
> cyg_spi_transaction_transfer() with NULL arguments for both RX and TX
> buffers. In other words you transfer data to/from the current data
> device, but you do not care what data gets sent to the device and any
> data coming from the device should be discarded. I do not know if all
> current drivers handle this correctly.
I think that both the AT91 and STM32 drivers will behave correctly here
- although a quick look at the AT91 code suggests that it will send
invalid data starting from address 0. This could be considered a
security issue in that it gives an attacker visibility of the contents
of the ARM exception jump table.
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss