starblue1 has quit [Ping timeout: 240 seconds]
starblue1 has joined #rust-embedded
emerent has quit [Ping timeout: 250 seconds]
emerent has joined #rust-embedded
gsalazar has joined #rust-embedded
gsalazar_ has joined #rust-embedded
gsalazar has quit [Ping timeout: 256 seconds]
gsalazar_ has quit [Quit: Leaving]
gsalazar has joined #rust-embedded
starblue1 has quit [Ping timeout: 256 seconds]
starblue1 has joined #rust-embedded
_whitelogger has joined #rust-embedded
edm_ is now known as edm
darknighte_ is now known as darknighte
VShell is now known as Shell
rektide_ has quit [Ping timeout: 256 seconds]
rektide has joined #rust-embedded
cr1901_ is now known as cr1901
cr1901 has quit [Ping timeout: 240 seconds]
cr1901 has joined #rust-embedded
<re_irc> <> Is there a place where I can find a description how to read an analog input pin? I'm using the Micro:bit v2.
<re_irc> <> [this]( reads the board microphone using SAADC, does that help to get started?
<re_irc> <> great, that's exactly what I'm using right now. but I would like to read m:B ring 0 (Pin0.02?) as input
<re_irc> <> Looks like there's `board.pins.p0_02`
<re_irc> <> And `board.pins.pX_YZ` in general
<re_irc> <> In the example they also enable the microphone like this:
<re_irc> <> board
<re_irc> <> .microphone_pins
<re_irc> <> // enable microphone
<re_irc> <> do I need something similar?
<re_irc> <> No
<re_irc> <> That's to provide power to the microphone
<re_irc> <> Whatever you're reading is probably powered externally
<re_irc> <> ah, okay. that makes sense. thank you!
xnor has quit [Quit: leaving]
xnor has joined #rust-embedded
<re_irc> <> re: the nrf5340 discussions from a couple days ago, looks like nimble has support
<re_irc> <> 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?
<re_irc> <> HCI is below the "host" part of the stack, so it's still quite lowlevel. The host part still needs certification
<re_irc> <> so you'd have to invent your own IPC that's above the host layer, ie not HCI
<re_irc> <> but otherwise yes, I guess..?
<re_irc> <> also huh, it has its own radio driver from scratch, using the registers directly. I wonder how mature it is
<re_irc> <> so, on the SPI ManagedCs traits
<re_irc> <> Would this make sense?
<re_irc> <> pub trait SpiDevice {
<re_irc> <> ```rust
<re_irc> <> type Transaction<'a>: spi::ReadWrite where Self: 'a;
<re_irc> <> fn transaction<'a>(&'a mut self) -> Result<Self::Transaction<'a>, Self::Error>;
<re_irc> <> }
<re_irc> <> `spi::ReadWrite` is the "classic" SPI trait that has read/write/transfer/etc
<re_irc> <> it represents "ownership over the bus"
<re_irc> <> while SpiDevice represents "ownership over a single SPI device in the (possibly shared) bus"
<re_irc> <> so you can't directly read/write to it, you "start a transaction", which locks the entire bus and lowers CS
<re_irc> <> then you can read/write/transfer etc on the Transaction, possibly multiple times
<re_irc> <> then you drop it, which automatically deasserts CS
<re_irc> <> it's implementing the idea here, although slightly differently
<re_irc> <> what I like about it is you "explicitly" start the transaction, so you can do multiple reads/writes on it
<re_irc> <> so the Transactional traits to do "multiple operations within a single transaction" are no longer needed maybe...??