drivers/periph: making bus drivers thread safe

[haukepetersen]

As pointed out in #2289, our current bus driver implementations are not thread save. A solution is proposed in #2290 (for the STM32F4 cpu). If we use that proposed solution or if we do something else - either way we need to do this for all cpus and bus drivers. This issue is for tracking the implementation status of this effort.

Thread safe bus drivers:

• [x] cc2538
  • [x] i2c (does not exist right know)
  • [x] spi (does not exist right know)
• [x] sam3x8e
  • [x] i2c (does not exist right know)
  • [x] spi (@PeterKietzmann) #2317
• [x] samd21
  • [x] i2c #2323
  • [x] spi #2317
• [x] stm32f0
  • [x] i2c (does not exist right know)
  • [x] spi (@PeterKietzmann) #2317
• [x] stm32f1
  • [x] i2c #2323
  • [x] spi #2317
• [x] stm32f3
  • [x] i2c (does not exist right know)
  • [x] spi #2317
• [x] stm32f4
  • [x] i2c #2323
  • [x] spi -> (merged #2290)
• [x] stm32l1
  • [x] i2c #2323
  • [x] spi #2317
• [x] kinetis_common #2265
  • [x] i2c #2265
  • [x] spi https://github.com/jfischer-phytec-iot/RIOT/pull/11 (@gebart)

Question: do we need to make the UART thread safe?

Edit [@thomaseichinger]: To keep things centralised I add a list of drivers needing adoption.

• [x] SPI
  • [x] at86rf231 #2317
  • [x] cc110x #2317
  • [x] nrf24l01p #2317
  • [x] lis3dh #2296
• [x] I2C
  • [x] hdc1000 (@jfischer-phytec-iot ) #2354
  • [x] isl29020 (@PeterKietzmann) #2326
  • [x] l3g4200d (@PeterKietzmann) #2326
  • [x] lps331ap (@PeterKietzmann) #2326
  • [x] mag3110 (@PeterKietzmann) #2326
  • [x] mma8652 (@PeterKietzmann) #2326
  • [x] mpl3115a2 (@PeterKietzmann) #2326
  • [x] srf02 (@PeterKietzmann) #2326
  • [x] srf08 (@PeterKietzmann) #2326
  • [x] tmp006 (@PeterKietzmann) #2326
  • [x] lsm303dlhc (@PeterKietzmann) #2326

[thomaseichinger]

Question: do we need to make the UART thread safe?

If we are at it, let's do this.

[thomaseichinger]

Question: do we need to make the UART thread safe?

After thinking about it some more it would break usage of DEBUG() in ISR context and similar, so probably not. Other opinions?=

[jnohlgard]

@thomaseichinger Can it be avoided by letting the UART IRQ have a higher priority? To be able to transmit while another ISR is waiting for the lock?

[haukepetersen]

@gebart: I would not start with higher IRQ priorities - as for (i) some platforms do not support this and (ii) we have not really investigated if the kernel is actually able to run with different priorities (it's still an open task...).

But I think we could add a lock for the UART, but we can just not use it for stdout...

[jnohlgard]

I got an idea: Using atomic counters it should be possible to implement the UART buffering functions without locking, with the drawback that we may drop bytes when the buffer gets full.

[haukepetersen]

This would work if the UART driver would buffer... But it is explicitly designed not to buffer, as this is something intended to do by the higher-level modules put on top of the UART.

[thomaseichinger]

I updated the description to also include parts using the updated interfaces to track adoption.

[jnohlgard]

Just for completeness I added the kinets_common stuff still being worked on in #2265

[jnohlgard]

After #2326 was merged tonight I believe this can be closed as resolved.

[PeterKietzmann]

jap, correct