Update the start and stop flags for all read/write/read_write methods to match
those in the default blocking implementation of these methods (as well as
other RP2040 I2C implementations, and expected I2C behavior).
Also adds a write_read_async method that doesnt require using embedded-hal, as
this is required to use I2C in an idiomatic fashion (see TI Application Report
SLVA704).
The RP2040 datasheet indicates that I2C pins should have a limited
slew rate (Page 440 - 4.3.1.3.). This configures that for both
`I2c` and `I2cSlave`.
In addition, the pin configuration has been centralized to a single
fn.
They're heavily spamming logs for HIL tests, and I don't believe
they're valuable now that the thing they helped debug in their young
age is now solid and mature.
Move i2c to mod, split device and controller
Remove mode generic:
I don't think it's reasonable to use the i2c in device mode while
blocking, so I'm cutting the generic.
this is "generic" in that it doesn't require the user to set up anything
specific to go to dormant sleep, unlike the C sdk which requires clock
sources to be configured explicitly and doesn't much care about PLLs. we
will instead take a snapshot of the current clock configuration, switch
to a known clock source (very slow rosc, in this case), go to sleep, and
on wakeup undo everything we've done (ensuring stability of PLLs and
such).
tested locally, but adding tests to HIL seems infeasible. we'd need at
least another pico or extensive modifications to teleprobe since
dormant-sleep breaks SWD (except to rescue-dp), neither of which is
feasible at this point. if we *did* want to add tests we should check
for both rtc wakeups (with an external rtc clock source) and gpio wakeups.
this temporarily takes ownership of pins because we need to clear edge
interrupts before waiting for them (otherwise we may wait indefinitely),
we want to clean up the dormant-wake bits after a wakeup, and doing
anything *else* with the input while we're waiting for a wakeup isn't
possible at all. doing it like this lets us not impose any cost on those
who don't use dormant wakes without entangling dormant waits too badly
with regular interrupt waits.
with uniform treatment of adc inputs it's easy enough to add a new
sampling method. dma sampling only supports one channel at the moment,
though round-robin sampling would be a simple extension (probably a new
trait that's implemented for Channel and &[Channel]). continuous dma as
proposed in #1608 also isn't done here, we'd expect that to be a
compound dma::Channel that internally splits a buffer in half and
dispatches callbacks or something like that.
this lets us treat pins and the temperature sensor uniformly using the
same interface. uniformity in turn lets us add more adc features without
combinatorial explosion of methods and types needed to handle them all.
