I have successfully implemented nonblocking I2C, but haven't found a good way to prevent simultaneous use by similar devices or the SDK routines.
The SDK source seems to access the I2C device with no locking. I think there's a risk that both cores would send transactions simultaneously and corrupt each other. Is that true, or is there some protection I don't see?
Every transaction 1) sets TAR, 2) writes to TX FIFO, and maybe (3) reads from RX FIFO. It's easy to imagine both cores racing to set TAR before either one writes to the FIFO, leading to sadness and confusion.
I'd appreciate any recommendations for best practices. My best idea so far is to point all my I2C code to a user-supplied global lock, and trust the user to grab that lock themselves before using the SDK I2C functions.
My working code:
https://eric.buddington.net/code/pico/I ... -05-05.hpp
The SDK source seems to access the I2C device with no locking. I think there's a risk that both cores would send transactions simultaneously and corrupt each other. Is that true, or is there some protection I don't see?
Every transaction 1) sets TAR, 2) writes to TX FIFO, and maybe (3) reads from RX FIFO. It's easy to imagine both cores racing to set TAR before either one writes to the FIFO, leading to sadness and confusion.
I'd appreciate any recommendations for best practices. My best idea so far is to point all my I2C code to a user-supplied global lock, and trust the user to grab that lock themselves before using the SDK I2C functions.
My working code:
https://eric.buddington.net/code/pico/I ... -05-05.hpp
Statistics: Posted by Eric Buddington — Sun May 05, 2024 10:37 pm — Replies 0 — Views 30