ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
AtleoS has joined #rust-embedded
blaine[m] has joined #rust-embedded
<blaine[m]> Hey all – Is there a "shining" example of an SPI device driver that conforms to embedded-hal 1.0's traits and does both input/output and (ideally) does so with a choice of either sync and async approaches? The drivers in the awesome embedded rust docs ( are a bit out of date, and I'm not experienced enough to gauge a "good" driver vs a
<blaine[m]> not-so-good one. If there's a driver that you're proud of or just think is great, I'd love to take a look and learn from the design!
Foxyloxy has quit [Read error: Connection reset by peer]
Foxyloxy has joined #rust-embedded
<M762spr[m]> <blaine[m]> "Hey all – Is there a "shining..." <- I need exactly this! 😅
<M762spr[m]> specifically I am trying to do a SPI transaction with a builder pattern in my driver...
<M762spr[m]> You construct the builder with a register ID, set if it is read or write, any additional flags for the device, and then "build"/send it.
<M762spr[m]> I'm running into some snags though. I don't want to put the SpiBus and CS pin in the builder struct as it would be dropped. I thought I would just pass a reference to each and the buffer in fn send(), but the compiler complains that the associated type 'error' in ...spi::ErrorType must be specified. I'm a little stumped
GuineaWheek[m] has joined #rust-embedded
<GuineaWheek[m]> how would one stop probe-rs from putting rtt into blocking mode with defmt_rtt?
bpye has quit [Quit: Ping timeout (120 seconds)]
bpye has joined #rust-embedded
<JamesMunns[m]> <GuineaWheek[m]> "how would one stop probe-rs..." <- I didn't think it does that, actually. probe-run used to do that, but I didn't think probe-rs did that yet
<JamesMunns[m]> Is the issue to ADD support for that in the future
<danielb[m]> * technically, that issue is broader as @tiwalun wants to change mode for all RTT channels (for whatever reason), not just defmt. We switch to blocking by default for defmt, but the change hasn't been released yet. `cargo embed` includes an option to override this, probe-rs does not
<GuineaWheek[m]> guess we'll have to learn cargo-embed then
<danielb[m]> why are you so intent on corrupting your own log stream?
<GuineaWheek[m]> i'd rather the firmware not freeze/potentially set things on fire than have pristine logs
<JamesMunns[m]> yeah, it's a reasonable flag to have, IMO
<GuineaWheek[m]> and that fire could be literal (power electronics)
<JamesMunns[m]> with the rzcobs encoding you can recover from corrupt logs, tho IMO you might be better off dropping the level of those logs in hot loops to TRACE or something, and filtering them out at compile time
<JamesMunns[m]> you'll still pay the encoding costs (lower than fmt, but still present) if you log but discard
<JamesMunns[m]> setting the log level to DEBUG means TRACE logs don't even get compiled in at all.
<JamesMunns[m]> (and so on for all the levels)
<JamesMunns[m]> but yeah, IMO it should be POSSIBLE to control all those behaviors, it just isn't yet, and "block on logs" is a good default, IMO, as it is more predictable for people.
<GuineaWheek[m]> that makes sense
<JamesMunns[m]> Also, not sure what probe you're using, but IIRC daplink and similar are faster at RTT (through probe-rs) than JLinks, so you might get better throughput, or potentially raising your SWD link speed (this might require a shorter or better shielded cable)
<GuineaWheek[m]> i'll look into that, thanks!
<GuineaWheek[m]> side note: is there a math library that's inbetween micromath (fast, imprecise, doesn't use processor instructions) and libm (more "correct" but really slow) -- we find ourselves writing wrappers around core::intrinsics to make sure we actually use the single-precision sqrt instruction the cortex-m happens to have
<GuineaWheek[m]> (for example)
<GuineaWheek[m]> a lot of the libm routines also tend to use double-precision floats which don't mesh well when you only have single-precision going on
<JamesMunns[m]> how you're doing it is probably how I'd do it: use intrinsics or inline asm to make my own custom functions. not sure if cortex-m::asm contains those functions
<JamesMunns[m]> I haven't heard of one, it might be worth making your own crate so we can share with other folks!
<JamesMunns[m]> I don't see any math intrinsics there
<GuineaWheek[m]> iirc not all cortex-ms have the single precision fpu
<GuineaWheek[m]> it'd be interesting to make a math library tailored to say cortex m4f though
<JamesMunns[m]> idsp is the other one that gets mentioned here
<JamesMunns[m]> it might be more "big picture" than single operations tho? not sure
<JamesMunns[m]> also also I think there's a wrapper for cortex-m dsp:
<JamesMunns[m]> again, might be more "big picture"
bomb has joined #rust-embedded
<GuineaWheek[m]> idsp looks cool
<JamesMunns[m]> yeah, the stabilizer folks use it pretty heavily
<GuineaWheek[m]> stabilizer?
ryan-summers[m] has joined #rust-embedded
<ryan-summers[m]> Feel free to ping me or Robert (@jordens) with questions on idsp :) The whole point of idsp is to be super fast and use architecture intrinsics wherever possible
<ryan-summers[m]> idsp has largely been optimized for use with the M7F core, but I imagine it should still work quite well on m4
<thejpster[m]> restarted the Arm target docs update in
<thejpster[m]> I'll update it later with the target-cpu and target-feature tables. Feel free to send PRs to my branch so we can collate all the changes together and then send an upstream PR.
RobertJrdens[m] has joined #rust-embedded
<RobertJrdens[m]> <thejpster[m]> "I'll update it later with the..." <- Awesome! Do you plan on adding material from your hackmd on the target-feature stuff as well?
IlPalazzo-ojiis1 has joined #rust-embedded
IlPalazzo-ojiis1 has quit [Ping timeout: 264 seconds]
IlPalazzo-ojiis1 has joined #rust-embedded
<thejpster[m]> yes. that's the target-cpu and target-feature tables bit
AtleoS has quit [Ping timeout: 245 seconds]
AtleoS has joined #rust-embedded
mabez[m] has quit [Quit: Idle timeout reached: 172800s]
IlPalazzo-ojiis1 has quit [Quit: Leaving.]
AtleoS has quit [Ping timeout: 252 seconds]
AtleoS has joined #rust-embedded
ximp has quit [Ping timeout: 260 seconds]
<Ecco> Hi! Is it possible to have "cargo test" run tests on the host?
<JamesMunns[m]> In a `bin` project, probably not, or it would be fairly hacky.
<JamesMunns[m]> In a `lib` project, definitely!
<JamesMunns[m]> The general suggestion for testing is to push as much "logic" into a library crate, that isn't hardware specific (e.g. it uses `embedded-hal(-async)` traits and not specific hardware, like `embassy_stm32`), and use something like `embedded-hal-mock` or your own trait impls for testing.
<dngrs[m]> <JamesMunns[m]> "also also I think there's a..." <- > <> also also I think there's a wrapper for cortex-m dsp: (full message at <>)
<dngrs[m]> <Ecco> "Hi! Is it possible to have "..." <- this blog post goes into detail:
<JamesMunns[m]> dngrs[m]: I think that's the opposite, that's cargo test on the target :)
<dngrs[m]> (imho needing two nested workspaces is indicative of cargo needing some improvements, but that's another discussion…)
<dngrs[m]> JamesMunns[m]: it has a section on host testing
<JamesMunns[m]> ah, that's true!
<JamesMunns[m]> also, I forget how long postcard has been around. I was a little surprised they were mentioning it in that blog post :p
<dngrs[m]> it would've been clearer if I had said "this blog post discusses a thorough approach for testing an embedded project - target-only, host-only and with host-target communication"
<dngrs[m]> I do wonder about the nested workspaces thing though. Are we stuck in a local maximum with cargo?
<thejpster[m]> OK I think I'm done:
<thejpster[m]> I really hope I'm done.
<JamesMunns[m]> <dngrs[m]> "I do wonder about the nested..." <- IMO cargo workspaces really don't handle multiple *kinds* of targets well at all. I think there are some things that are in progress now (like the nightly cargo features we use in mnemos) that *improves* that, but tbh it's an edge of the tool that doesn't work well.
<JamesMunns[m]> it should be better, but I think someone needs to explain HOW it could be better, what needs to be done to get there, and how to avoid any currently tools (incl R-A and cargo extensions), and then do that work
<dngrs[m]> Glad to hear there's some progress tho
<dngrs[m]> Yeah...
<JamesMunns[m]> it's not IMPOSSIBLE (afaik), it's just a lot of work to get there, and IMO, I think you'd lose a lot of benefits of workspaces to begin with (since you need to recompile deps for multiple targets anyway!)
<dngrs[m]> Maybe have a hackmd or GH issue where we collect pain points?
<JamesMunns[m]> That, and `cargo` is pretty bad in the "People Who Have Loud Opinions" to "People Who Maintain and Make Improvements" ratio, historically
<JamesMunns[m]> s/People/Users/
<JamesMunns[m]> (might be better in recent years, I think RF is possibly paying maintainers? not sure tho)
<dngrs[m]> Hmrngh.
<dngrs[m]> Ok maybe something for an upcoming agenda..
<JamesMunns[m]> Honestly, like many things, it's "will someone/some people show up and have energy for a (positive) fight and make it happen"
<JamesMunns[m]> cargo needs a few heroes, for sure :)
<dngrs[m]> Yeah, I'm not against working doing that myself
<dngrs[m]> But not if I'm the only one interested
<dngrs[m]> I'll bring it up in some ewg meeting I guess
<JamesMunns[m]> I'd like it to work (waves hands) nebulously better for multiple targets! let me give you some notes I have
<JamesMunns[m]> step by step "how setting up a multiarch workspace usually fails"
<JamesMunns[m]> IIRC this highlights the "shared dep with mutually exclusive features", but I think it also touches on some other issues that are potentially work-around-able
<dngrs[m]> Sweet, thanks!
bomb has quit [Quit: 💣]
vollbrecht[m] has quit [Quit: Idle timeout reached: 172800s]
Lumpio[m] has quit [Quit: Idle timeout reached: 172800s]
esben[m] has quit [Quit: Idle timeout reached: 172800s]
feerless[m] has joined #rust-embedded
<feerless[m]> Hello, I am pretty new to embedded and new to rust. I have done some embedded in C. Do I need to take any rust specific aspects into account when selecting MCs, etc
<feerless[m]> Is it safe to assume that if C was able to compile for the MC, then rust will do the same?
AtleoS has quit [*.net *.split]
pflanze has quit [*.net *.split]
merayen has quit [*.net *.split]
fooker has quit [*.net *.split]
cr1901 has quit [*.net *.split]
GenTooMan has quit [*.net *.split]
AdamHorden has quit [*.net *.split]
Allie has quit [*.net *.split]
Amnesia has quit [*.net *.split]
jsolano has quit [*.net *.split]
Darius has quit [*.net *.split]
vancz has quit [*.net *.split]
Ekho has quit [*.net *.split]
Foxyloxy has quit [*.net *.split]
exark has quit [*.net *.split]
crabbedhaloablut has quit [*.net *.split]
nohit has quit [*.net *.split]
sigmaris has quit [*.net *.split]
NishanthMenon has quit [*.net *.split]
Benn[m] has joined #rust-embedded
<Benn[m]> I'm also fairly new to doing embedded in rust, but the answer seems to be "there's support for a lot of MCUs, but its not guaranteed". also just because your MCU is supported, doesn't mean your particular board is defined. I'm currently translating the pin assignments from an arduino board to rust for a supported MCU (nRF52840 MCU, board is a XIAO BLE). it sure seems to work, there's just extra C-spelunking to make it work
NishanthMenon has joined #rust-embedded
sigmaris has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
nohit has joined #rust-embedded
exark has joined #rust-embedded
Foxyloxy has joined #rust-embedded
AtleoS has joined #rust-embedded
pflanze has joined #rust-embedded
cr1901 has joined #rust-embedded
fooker has joined #rust-embedded
GenTooMan has joined #rust-embedded
AdamHorden has joined #rust-embedded
Allie has joined #rust-embedded
Amnesia has joined #rust-embedded
Darius has joined #rust-embedded
Ekho has joined #rust-embedded
vancz has joined #rust-embedded
jsolano has joined #rust-embedded
<JamesMunns[m]> In general, if the MCU is `cortex-m`, Rust will probably handle it. If it's `risc-v`, it'll PROBABLY work. Otherwise, if `clang` specifically can support it (e.g. LLVM based, not GCC based?), there's a good chance Rust CAN support it, but it might be some work.
<JamesMunns[m]> The next step is "are there drivers for this chip", which will take some more searching.
merayen has joined #rust-embedded
Lumpio[m] has joined #rust-embedded
<Lumpio[m]> The real problem with pin mappings is board manufacturers being "helpful" and coming up with arbitrary pin naming schemes instead of just using, you know, the actual pin names on the chip (anything that starts with A and ends with rduino is often pretty egregious about this)
<Benn[m]> ^ yeah this. having to delve through several header/source files to find what the actual mapping to the underlying pin is actually called is "Fun"
<feerless[m]> can't you just look at the data sheet?
<Benn[m]> at least in my case, the board doesn't have a datasheet for how they've assigned the nRF52 pins, and the nRF52 lets you do whatever you want
<Benn[m]> for the qspi interface, nordic has some recommendations, but lets you use whatever pins you want, really
<Benn[m]> so the nrf52-dk (development kit) qspi pinout is different from my board
<dngrs[m]> don't you just love it when chip pin 27 is GPIO4 is board pin 15
<dirbaio[m]> pin mapping is usually in the board's documentation, either in text form in some datasheet/manual or in schematics.
<dirbaio[m]> if it's completely undocumented except in C code it's a problem of bad documentation.
<Benn[m]> it is in the schematic, the C code is just easier to read
<Benn[m]> also since that's from the code people are using, i trust it more than a document that is not executed
<dirbaio[m]> i've never had to read C code to figure out pinouts for many stm32 and nrf boards 🤷
<feerless[m]> what is a good JTAG capable programmer. I hate how the one I have right now won't let me debug
<Benn[m]> there actually is a decent pinout spreadsheet for this board, i just missed it somehow
IlPalazzo-ojiis1 has joined #rust-embedded
LiamRosenfeld[m] has joined #rust-embedded
<LiamRosenfeld[m]> Hi! I have been using the ssd1306 crate on 0.7 for a while now. However, once I updated to 0.8, it now longer draws properly. It is drawing strangely (the top left corner is in the middle of the display with the overflow wrapping). Has anyone else run into this issue. And if so, how did you fix it?
<LiamRosenfeld[m]> * Hi! I have been using the ssd1306 crate pinned to 0.7 for a while now. However, once I updated to 0.8, it now longer draws properly. It is drawing strangely (the top left corner is in the middle of the display with the overflow wrapping). Has anyone else run into this issue. And if so, how did you fix it?
<LiamRosenfeld[m]> * Hi! I have been using the ssd1306 crate pinned to 0.7 for a while now. However, once I updated to 0.8, it now longer draws properly. It is drawing strangely (the top left corner is in the middle of the display with the overflow wrapping). Has anyone else run into this issue. And if so, how did you fix it? I'm just drawing bitmaps onto the display.
AtleoS has quit [Ping timeout: 245 seconds]
newam[m] has quit [Quit: Idle timeout reached: 172800s]
bomb has joined #rust-embedded
bomb has quit [Ping timeout: 260 seconds]
therealprof[m] has quit [Quit: Idle timeout reached: 172800s]
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
bartmassey[m] has quit [Quit: Idle timeout reached: 172800s]
AdamHott[m] has quit [Quit: Idle timeout reached: 172800s]
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
rmsyn[m] has quit [Quit: Idle timeout reached: 172800s]
geky[m] has quit [Quit: Idle timeout reached: 172800s]
NickStevens[m] has quit [Quit: Idle timeout reached: 172800s]
IlPalazzo-ojiis1 has quit [Remote host closed the connection]
eldruin[m] has quit [Quit: Idle timeout reached: 172800s]
<slabity[m]> So I'm still learning how to use `embassy` effectively and I'm struggling with how to handle defining tasks to handle hardware functions. For example, I have this awful function signature here: `async fn adc_task(i2c: i2c::I2c<'static, peripherals::I2C1, i2c::Blocking>, mut interrupt: gpio::Input<'static, peripherals::PIN_13>)`
<slabity[m]> This technically works, but I really don't like that I'm explicitly saying it *needs* to take `I2C1` and `PIN_13`. But if I make it a generic then it complains that task functions cannot take generics.
<slabity[m]> I can technically pass the I2C and interrupt pins as an AnyPin, but then I need to do the setup for that completely in the task itself and I'm not sure how to handle errors in that situation.
<slabity[m]> And not sure if I can technically even do that with the I2C pins as AnyPin can't implement the SclPin or SdaPin traits required to set that up
<dirbaio[m]> for the gpio you can use AnyPin
<dirbaio[m]> in embassy-rp git master the generic param for the pin is completely removed, it's `Input<'static>` now.
<dirbaio[m]> and the plan is to get rid of more generics in the future
<dirbaio[m]> for example i2c will be just `I2c<'static, Blocking>`
<slabity[m]> Oh, well that's convenient
<dirbaio[m]> so tldr yes: we know the generics are not great :P
<dirbaio[m]> there's some work alreayd started on removing them... (full message at <>)
<dirbaio[m]> but it'll take a while 🫠
<dirbaio[m]> in the meantime you'll have to write `I2c<'static, I2C1, Blocking>`
<dirbaio[m]> you can use type aliases to "centralize" all the peripheral definitions in a single place if you want to
<slabity[m]> Fair enough. I am just glad I wasn't crazy and creating awful abominations of function signatures.
<slabity[m]> I can definitely use the master branch
bomb has joined #rust-embedded
bomb has quit [Quit: 💣]