search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.97k stars 6.68k forks source link

sensors: Fully hardware handled triggers #71777

Open teburd opened 7 months ago

teburd commented 7 months ago

Is your enhancement proposal related to a problem? Please describe. Some hardware allows for triggering DMA transfers from things such as GPIO triggers perhaps, where a GPIO software interrupt handler may not be needed at all to read data from a sensor fifo. This is useful in cases where it is costly to jump to an interrupt handler (xip from slow flash) or when cycles spent swapping into/out of ISR handling only to program the DMA/Bus controller could be better spent elsewhere.

Describe the solution you'd like A platform agnostic way of allowing for this functionality without massively disrupting the sensor API or drivers.

Today most sensor drivers themselves directly connect and implement a GPIO ISR to then generically do bus transaction work. It would require programming, indirectly, bus transactions tied to an interrupt trigger in a descriptive format rather than by programming this in C.

E.g. describe that given a GPIO trigger I want to do a SPI transceive.

Additional context It was noted by @PetervdPerk-NXP at EOSS2024 this would be very useful in the context of i.MX RT parts running from external flash (and likely others such as rp2040) where jumping into an ISR is costly.

@yperess @MaureenHelm @bperseghetti @jgoppert might also be interested in the above.

RichardSWheatley commented 6 months ago

@teburd Silabs has cascading triggers that require setup only and no code after that. Is this what you are speaking of? For example: GPIO input triggers timer which then triggers GPIO output.

I believe this would be odd to do in Zephyr in any current driver context and if you can describe a way to do this in DT and driver, that would be helpful. I can provide code and context for that in Silabs. Or I can provide a Silabs contact for you to work with on a sample/test.

teburd commented 6 months ago

@teburd Silabs has cascading triggers that require setup only and no code after that. Is this what you are speaking of? For example: GPIO input triggers timer which then triggers GPIO output.

Partially yes, but in this case another bus master (DMA)for doing SPI/I2C transfers...

e.g. when configuring a sensor device in zephyr to read when DRDY/FIFO_WM/etc occur (via GPIO interrupt) have the DMA then trigger an i2c/spi bus transfer.

This is hard in Zephyr for a few reasons...

  1. Exclusive access to the i2c/spi bus isn't guaranteed
  2. We don't have a generic platform agnostic API for doing this sort of thing

I think we mostly have 2 partially covered through the updated sensor API which lets you describe triggers that signal data collection should occur. The second half of that is a way to have the bus driver set this up for you. Maybe one way would be having an RTIO OP code be... a interrupt trigger await OP that links to a spi transaction/i2c transaction.

This still doesn't solve issue 1 though, bus exclusive access. Unless you say that waiting on an interrupt implies exclusive access until that interrupt occurs.

I believe this would be odd to do in Zephyr in any current driver context and if you can describe a way to do this in DT and driver, that would be helpful. I can provide code and context for that in Silabs. Or I can provide a Silabs contact for you to work with on a sample/test.