<re_irc>
<@tomasbarton:matrix.org> Is there a consensus on what is the best way of representing register bitfields of externally connected peripheral devices? Lets say an ADC or an IMU connected over SPI or I2C.
<re_irc>
I have looked at several driver crates and found a variety of approaches going from just using u8 constants with addresses and bitmasks, to defining macros to generate the register structs from a custom DSL. Are there any examples of elegant solutions to this problem?
<re_irc>
<@firefrommoonlight:matrix.org> No consensus. I've been doing this:
<re_irc>
#[repr(u8)]
<re_irc>
pub enum Reg {
<re_irc>
#[derive(Clone, Copy)]
<re_irc>
PsrB2 = 0x00,
<re_irc>
PsrB1 = 0x01,
<re_irc>
PsrB0 = 0x02,
<re_irc>
TmpB2 = 0x03,
<re_irc>
<@firefrommoonlight:matrix.org> No consensus. I've been doing this:
<re_irc>
#[derive(Clone, Copy)]
<re_irc>
pub enum Reg {
<re_irc>
PsrB2 = 0x00,
<re_irc>
#[repr(u8)]
<re_irc>
PsrB1 = 0x01,
<re_irc>
PsrB0 = 0x02,
<re_irc>
// ..
<re_irc>
}
<re_irc>
TmpB2 = 0x03,
<re_irc>
<@firefrommoonlight:matrix.org> No consensus. I've been doing this:
<re_irc>
#[derive(Clone, Copy)]
<re_irc>
#[repr(u8)]
<re_irc>
pub enum Reg {
<re_irc>
PsrB2 = 0x00,
<re_irc>
PsrB1 = 0x01,
<re_irc>
PsrB0 = 0x02,
<re_irc>
TmpB2 = 0x03,
<re_irc>
// ..
<re_irc>
}
<re_irc>
<@firefrommoonlight:matrix.org> Then something like this in a "setup" or "new" fn:
<re_irc>
// Set 64x oversampling, and 32 measurements per second, for both temp and pres.
<re_irc>
i2c.write(ADDR, &[Reg::PrsCfg as u8, 0b0101_0110])?;
<re_irc>
// See datasheet, table 8.3
<re_irc>
<@diondokter:matrix.org> Tomas Barton: Hi, I created the device driver crate. I would say there is no consensus and no best way. But obviously I do have a preference of direction.
<re_irc>
I think a type per register is very logical. I don't wanna do bit shifting. It's tedious and easy to screw up.
<re_irc>
But how you make those types is a different question. You could do it manually, but like I said, I don't want it to be tedious.
<re_irc>
That leaves two possibilities. A macro with a DSL implementation like my crate or a code generator based of off a structured file, similar to SVD and the PACs.
<re_irc>
<@firefrommoonlight:matrix.org> If you intent to make it easy to use arbitrary configs, abstract further, eg with per-field enums that or together to set the value. If you know what config you want, I find the binary directly from datasheet to be simpler
<re_irc>
<@firefrommoonlight:matrix.org> * intend to make it easy to use arbitrary configs, abstract further, eg with per-field enums that "or"
<re_irc>
<@firefrommoonlight:matrix.org> : I think basing off a structured file would be ideal, but with no standard from manufacturerers and datasheets being in all kinds of formats, I don't see a practical means to this
<re_irc>
<@diondokter:matrix.org> : We'll just have to create a format we have consensus on and make Rust so big that manufacturers will want to use the format 😈
<re_irc>
<@firefrommoonlight:matrix.org> Yea; if every manufacturer put a dedicated person to this tag, it would be an easy play
<re_irc>
<@firefrommoonlight:matrix.org> Maybe some day
<re_irc>
<@firefrommoonlight:matrix.org> Yea; if every manufacturer put a dedicated person to this task, it would be an easy play
<re_irc>
<@diondokter:matrix.org> It's kinda on my radar to create
<re_irc>
<@firefrommoonlight:matrix.org> Love it
<re_irc>
<@diondokter:matrix.org> Just need the time and energy haha
<re_irc>
<@diondokter:matrix.org> Let's base it on yaml 😇
<re_irc>
<@tomasbarton:matrix.org> : I will take a look at your crate, thanks!
<re_irc>
<@tomasbarton:matrix.org> maybe svd is a good candidate. There is already a lot of infrastructure that could be reused 🤷♂️
<re_irc>
<@ragarnoy:matrix.org> hey, any clue why I can only get a trace of anything i'm running on --release (running lora examples) ? If I'm on the default profile i'll get "Finished in 6.801s" and nothing else, but in release everything works but I can't locate where my traces are coming from
<re_irc>
<@diondokter:matrix.org> Btw, ideally Rust would have native bitfields. Just give is arbitrarily sized integers and a #[repr(bitpacked)] and we're set to go
<re_irc>
<@diondokter:matrix.org> : Traces? You mean stack traces?
<re_irc>
Add this section to your cargo.toml with the debug and LTO set to true. (You only need debug to be true, but setting LTO to true is also good practice)
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
<re_irc>
<@shakencodes:matrix.org> I am working with the STM32WLxx_hal on an STM32WL55. As I understand this derives from an STM32F4 (or is it an STM32L4) core, with the addition of a LoRa-capable radio and (optionally) an M0+ core. I am working on setting up the watchdog timer, but do not find that supported in the HAL.
<re_irc>
Is it practical to bring the watchdog in from the STM32F4_hal, or is this something I need to build from scratch?
<re_irc>
<@jamesmunns:beeper.com> I know has a spreadsheet that shows all the shared peripherals between the different stm32 cores
<re_irc>
<@jamesmunns:beeper.com> (looking for it now...)
<re_irc>
<@jamesmunns:beeper.com> Not sure how to "work backwards" from there and figure out which watchdogs are related though
<re_irc>
<@shakencodes:matrix.org> The STM32WL55 includes the Independent Watchdog peripheral, and there is an implementation of this in stm32f4xx-hal. I'm not sure whether I should cherry-pick the one file, or if there is some way to share it between the two hals. (I'm actually surprised how different the two hals are, given how similar the parts are.)
<re_irc>
<@shakencodes:matrix.org> Does working with embassy entail shifting the HAL being used? How much do you commit to this framework? (And how does this relate to the overall Rust Embedded WG efforts?) -- Just trying to figure out how this piece fits into the greater landscape.
<re_irc>
<@diondokter:matrix.org> : You can use the embassy executor without using its HAL. But using an async runtime doesn't give you much if you don't have an async HAL.
<re_irc>
<@diondokter:matrix.org> So realistically, you'd want to use the embassy HAL. But it implements all the embedded-hal traits you'd expect, so you're still able to use any generic blocking driver
<re_irc>
<@firefrommoonlight:matrix.org> : Yea. Would also like arbitrary-sized integer types natively
<re_irc>
<@firefrommoonlight:matrix.org> I recently started using the [https://docs.rs/bitvec/latest/bitvec/](bitvec crate) when needing to serialize and deserialize non-byte-aligned structs
<re_irc>
<@diondokter:matrix.org> : Yeah it's great! The device driver crate uses this internally as well
<re_irc>
<@diondokter:matrix.org> : What's the reason for the internal refcell and why wouldn't you just let the user do it externally if they need the interaction through an immutable reference?
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
Foxyloxy has quit [*.net *.split]
hmw has quit [*.net *.split]
Foxyloxy has joined #rust-embedded
hmw has joined #rust-embedded
<re_irc>
<@flooore:matrix.org> !!! Enjoy the most profitable financial market (crypto market ) as you get 100% profit...and you can also make up to $100k or more in 3days send me a private message and ask me HOW on TG