[riot-notifications] [RIOT] drivers/spi: updated SPI driver interface (#3216)

Joakim Gebart notifications at github.com
Wed Jun 24 22:41:27 CEST 2015


@haukepetersen 
>With the CS I see a different difficulty: this is how we handle CS inside device drivers. I would hate to see constructs involving ifdefs on weather to call gpio_set/clear manually or not...

I completely agree, which is why I would like to open the discussion on how to handle CS lines within the device drivers.

>Hm, wait: I might have an idea: We could introduce another parameter for the transfer functions:
>```c
void spi_transfer_bytes(spi_t dev, gpio_t cs, ...);
```
>Now the spi driver can deicide itself, if it just ignores the given parameter (and uses internal HW CS lines instead). Even both is possible, as you could implement your CPUs spi driver in a way, that it will use some HW CS pin in case the parameter 'GPIO_UNDEF' is given, and use SW CS.

>Using an additional parameter has the advantage, that the SPI driver does not need to keep state. Because keeping say an instance struct for each device that is run on a SPI bus, it would lead to redundant data that can be saved this way. What do you say?

This is similar to what we have been using in Contiki for a while. You need to add one more parameter though, `void spi_transfer_bytes(spi_t dev, gpio_t cs, bool continue, ...);` to tell the spi_transfer_bytes function to keep asserting the CS line after the transfer is completed. Some transactions are made up of multiple transfers while the CS line is held (e.g. write address+read data bytes).

---
Reply to this email directly or view it on GitHub:
https://github.com/RIOT-OS/RIOT/pull/3216#issuecomment-115004724
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20150624/8895576b/attachment-0001.html>


More information about the notifications mailing list