We were using OSPI in indirect mode via DMA and noticed that the transfer future would never resolve. It was forever busy-looping in `finish_dma()` on the `while !regs.sr().read().tcf() {}` line.
After some debugging we noticed that the the `TEF` flag is set. The data sheet says the following about this flag:
> The following errors set the TEF flag in OCTOSPI_SR and generates an interrupt if enabled (TEIE = 1 in OCTOSPI_CR):
> - in indirect or automatic status-polling mode, when a wrong address has been programmed in OCTOSPI_AR (according to the device size defined by DEVSIZE[4:0]).
> - in indirect mode, if the address plus the data length exceed the device size: TEF is set as soon as the access is triggered.
Indeed we were configuring our device size to 0 while specifying a non-zero address.
Detect this condition and return an error early - as soon as we configure the registers (which, according to the data sheet, should be enough to raise the flag)
Also document this behavior on the respective TransferConfig and Config fields.
Testing
-------
See https://github.com/goodhoko/spi-error-test/blob/main/src/main.rs
DS18B20 sensors require a strong pullup to be applied for the duration
of the temperature conversion, within 10us of the command. The rp2xxx
pins have sufficient drive strength to use as the pullup (no external
mosfet needed).
Add a new write_bytes_pullup() that will apply the pullup after
bytes are written. Existing read_bytes()/write_bytes() has no change to
onewire timing.
A pio_onewire_parasite example reads multiple sensors individually,
applying the strong pullup.
Since `MutexGuard` has `T: ?Sized`, `U` does not need to be restricted
to `Sized` types. This now allows using `map` to cast from
`MutexGuard<'_, M, ImplsTrait>` to `MutexGuard<'_, M, dyn Trait>`.
