17:44 <re_irc> <@urbanaut78:matrix.org> Is there a place where I can find a description how to read an analog input pin? I'm using the Micro:bit v2.

17:49 <re_irc> <@dngrs:matrix.org> urbanaut78:matrix.org: [this](https://github.com/nrf-rs/microbit/blob/main/examples/v2-microphone/src/main.rs) reads the board microphone using SAADC, does that help to get started?

17:52 <re_irc> <@urbanaut78:matrix.org> great, that's exactly what I'm using right now. but I would like to read m:B ring 0 (Pin0.02?) as input

17:52 <re_irc> <@k900:0upti.me> Looks like there's `board.pins.p0_02`

17:53 <re_irc> <@k900:0upti.me> And `board.pins.pX_YZ` in general

17:56 <re_irc> <@urbanaut78:matrix.org> In the example they also enable the microphone like this:

17:56 <re_irc> <@urbanaut78:matrix.org> board

17:56 <re_irc> <@urbanaut78:matrix.org> .microphone_pins

17:56 <re_irc> <@urbanaut78:matrix.org> // enable microphone

17:56 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/ecf56bde2aeb28081be1e8eb76dbfacf938fe5a830870da6c58a73ece6715f81 (6 lines)

17:56 <re_irc> <@urbanaut78:matrix.org> do I need something similar?

17:57 <re_irc> <@k900:0upti.me> No

17:58 <re_irc> <@k900:0upti.me> That's to provide power to the microphone

17:58 <re_irc> <@k900:0upti.me> Whatever you're reading is probably powered externally

17:59 <re_irc> <@urbanaut78:matrix.org> ah, okay. that makes sense. thank you!

19:23 <re_irc> <@unrelentingtech:mozilla.org> re: the nrf5340 discussions from a couple days ago, looks like nimble has support https://github.com/apache/mynewt-nimble/tree/master/nimble/drivers/nrf5340/src

19:24 <re_irc> <@unrelentingtech:mozilla.org> including an IPC thing https://github.com/apache/mynewt-nimble/blob/master/nimble/transport/nrf5340/src/nrf5340_ble_hci.c

19:24 <re_irc> <@unrelentingtech:mozilla.org> which makes me think.. would it be possible to run all the C nimble stuff on the radio core and a Rust app on the other core, with the Rust app only knowing that "HCI" interface and them being independently built?

21:07 <re_irc> <@dirbaio:matrix.org> HCI is below the "host" part of the stack, so it's still quite lowlevel. The host part still needs certification

21:07 <re_irc> <@dirbaio:matrix.org> so you'd have to invent your own IPC that's above the host layer, ie not HCI

21:07 <re_irc> <@dirbaio:matrix.org> but otherwise yes, I guess..?

21:11 <re_irc> <@dirbaio:matrix.org> also huh, it has its own radio driver from scratch, using the registers directly. I wonder how mature it is

22:09 <re_irc> <@dirbaio:matrix.org> so, on the SPI ManagedCs traits

22:09 <re_irc> <@dirbaio:matrix.org> Would this make sense?

22:09 <re_irc> <@dirbaio:matrix.org> pub trait SpiDevice {

22:09 <re_irc> <@dirbaio:matrix.org> ```rust

22:09 <re_irc> <@dirbaio:matrix.org> type Transaction<'a>: spi::ReadWrite where Self: 'a;

22:09 <re_irc> <@dirbaio:matrix.org> fn transaction<'a>(&'a mut self) -> Result<Self::Transaction<'a>, Self::Error>;

22:09 <re_irc> <@dirbaio:matrix.org> }

22:09 <re_irc> <@dirbaio:matrix.org> `spi::ReadWrite` is the "classic" SPI trait that has read/write/transfer/etc

22:10 <re_irc> <@dirbaio:matrix.org> it represents "ownership over the bus"

22:10 <re_irc> <@dirbaio:matrix.org> while SpiDevice represents "ownership over a single SPI device in the (possibly shared) bus"

22:11 <re_irc> <@dirbaio:matrix.org> so you can't directly read/write to it, you "start a transaction", which locks the entire bus and lowers CS

22:11 <re_irc> <@dirbaio:matrix.org> then you can read/write/transfer etc on the Transaction, possibly multiple times

22:11 <re_irc> <@dirbaio:matrix.org> then you drop it, which automatically deasserts CS

22:12 <re_irc> <@dirbaio:matrix.org> it's implementing the idea here, although slightly differently https://github.com/rust-embedded/embedded-hal/issues/299

22:12 <re_irc> <@dirbaio:matrix.org> what I like about it is you "explicitly" start the transaction, so you can do multiple reads/writes on it

22:13 <re_irc> <@dirbaio:matrix.org> so the Transactional traits to do "multiple operations within a single transaction" are no longer needed maybe...??