ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
mattgirv has quit [Quit: No Ping reply in 180 seconds.]
mattgirv has joined #rust-embedded
Ekho has quit [Ping timeout: 256 seconds]
rektide has quit [Ping timeout: 256 seconds]
rektide has joined #rust-embedded
Ekho has joined #rust-embedded
starblue has quit [Ping timeout: 246 seconds]
starblue has joined #rust-embedded
xnor has quit [Ping timeout: 256 seconds]
xnor has joined #rust-embedded
<re_irc> <firefrommoonlight> Rust is at home on embedded
<re_irc> <firefrommoonlight> GL
<re_irc> <firefrommoonlight> It's a great match
<re_irc> <firefrommoonlight> Ie... There are only a handful of langs you can program embedded with, and it is, subjectively, the nicest to program in, due to thoughtful syntax, and nice tooling
<re_irc> <firefrommoonlight> I've been doing a lot of C translation lately, and the Rust versions are cleaner / more consistent
<re_irc> <firefrommoonlight> Ie... There are only a handful of langs you can program embedded with, and Rust is, subjectively, the nicest to program in, due to thoughtful syntax, and nice tooling
<re_irc> <firefrommoonlight> Downside is you may have to write libs for peripheral support etc yourself that would be provided by the manufacturer in C
fabic has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 240 seconds]
crabbedhaloablut has joined #rust-embedded
fabic has quit [Ping timeout: 246 seconds]
emerent has quit [Ping timeout: 260 seconds]
emerent_ has joined #rust-embedded
fabic has joined #rust-embedded
<re_irc> <Chris [pwnOrbitals]> repr(align(n)) aligns each field of a struct (and inserts padding) or only the whole struct must be at an aligned address ?
<re_irc> <Chris [pwnOrbitals]> +?
<re_irc> <Chris [pwnOrbitals]> +Hi ! anyone knows if
<re_irc> <9names (> struct fields are already aligned (with required padding) unless you specify packed. repr align will align the start of the struct.
<re_irc> <9names (> the fields may be re-ordered to minimise padding unless you specify repr(C)
<re_irc> <Chris [pwnOrbitals]> interesting, thanks
<re_irc> <9names (> the nomicon ( discusses this in detail. probably best to read through those sections to get a good feel for what each repr() does
<re_irc> <Chris [pwnOrbitals]> well, the paragraph about repr(align(n)) isn't very detailed tbh
<re_irc> <Chris [pwnOrbitals]> I had read it before asking :p
<re_irc> <Chris [pwnOrbitals]> but your answer makes sense so thanks a lot
fabic has quit [Ping timeout: 248 seconds]
fabic has joined #rust-embedded
<re_irc> <mmh> Hello everyone, I have some thoughts about the implementations of HAL libraries and want to discuss.
<re_irc> We all know that codes with macros are difficult to debug, difficult to set breakpoints.
<re_irc> It seems that almost all the HAL implementations rely on macros a lot, after reading some HAL's code, I found that they use macros because the PAC is too strict about the type so the HAL must use macros to repeat the code to satisfy the compiler. For example, the GPIO peripherals almost share the same set of registers, but they are different types in PAC, so the HAL have to repeat code a lot.
<re_irc> So, I hope to know that is it possible to rewrite an HAL with less macros?
<re_irc> <ryan-summers> How would you propose the HAL manipulate registers without the PAC to expose safe APIs in that case?
<re_irc> <ryan-summers> Because largely I agree with your point that the macros are suboptimal
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #rust-embedded
fabic has quit [Ping timeout: 246 seconds]
fabic has joined #rust-embedded
dreamcat4 has quit [Quit: Connection closed for inactivity]
crabbedhaloablut has quit [Ping timeout: 240 seconds]
crabbedhaloablut has joined #rust-embedded
<re_irc> <burrbull> mmh: what exact chip family do you mean?
crabbedhaloablut has quit [Ping timeout: 240 seconds]
crabbedhaloablut has joined #rust-embedded
<re_irc> <mutantbob> I have been experimenting with a modified version of "embedded-nal" to create a struct "StackAndSocket" which can "impl uWrite" ; Is there a better way to do this?
diagprov has quit [Read error: Connection reset by peer]
diagprov has joined #rust-embedded
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc> <dirbaio> mmh: macro spam in HALs is often a consequence of duplication in PACs
<re_irc> <dirbaio> because there's some tiny difference between them (different reset values I think?)
<re_irc> <dirbaio> but this means it's completely impossible to implement a GPIO HAL for that without macros
<re_irc> <dirbaio> you have to use macros to "copypaste" the same code with different types
<re_irc> <dirbaio> but it doesn't have to be this way
<re_irc> <dirbaio> * way, this is a design decision in the stm32-rs PACs
<re_irc> <dirbaio> in Embassy we're building a stm32 PAC designed to avoid HAL macro spam. This means unifying types and converting stuff to arrays as much as possible
<re_irc> <dirbaio> for example there's only one type for GPIO
<re_irc> <dirbaio> and bits for individual pins are an array ( you can set by index, vs 15 copied fields with different names (
<re_irc> <dirbaio> and this gets you a HAL GPIO implementation with zero macros:
<re_irc> <riskable> Very strange: Why am I suddenly getting "rust-lld: error: undefined symbol: _defmt_timestamp" when compiling my firmware? I swear it compiled with defmt just fine before. I had it commented out for a while and then I just re-enabled it and I can't seem to get it to work
<re_irc> <korken89> riskable: Did you forget to add the defmt.x as a link argument?
<re_irc> <riskable> korken89: Uhh... I've never added that as a link argument anywhere. Where do I put that?
fabic has quit [Ping timeout: 248 seconds]
<re_irc> <korken89> config.toml
<re_irc> <korken89> You can check their app template for an example
<re_irc> <riskable> Oh, right it's in the app template (that I copy from haha)
<re_irc> <riskable> Haha, sure enough that line was removed! I must've copied & pasted over it at some point
<re_irc> <korken89> :D
<re_irc> <riskable> Man, even after all that trouble trying out different panic handlers and whatnot I'm still getting this if I try to update my "epd-waveshare" display after "init()":
<re_irc> ❯ probe-run --chip RP2040 target/thumbv6m-none-eabi/release/serious-firmware --backtrace=always
<re_irc> (HOST) INFO success!
<re_irc> (HOST) INFO flashing program (23 pages / 92.00 KiB)
<re_irc> <korken89> Are you putting the core to sleep?
<re_irc> <korken89> Eg using WFI?
<re_irc> <riskable> korken89: Nope, nothing like that
<re_irc> <korken89> What probe are you using?
<re_irc> <riskable> Here's the function where the problem happens (but really, it'll happen anywhere outside of init whenever I try to use "epd"):
<re_irc> <riskable> I'm using the STM32F723 hs-probe
<re_irc> <korken89> Latest firmware?
<re_irc> <riskable> I have an ST-LINK around somewhere I can use if you think that'd help
<re_irc> <korken89> Just to be safe
<re_irc> <riskable> korken89: Yep, I just flashed it earlier to make sure
<re_irc> <korken89> Then it should be fine, in using the same
<re_irc> <korken89> * I'm
<re_irc> <riskable> Yeah I don't think it's a problem with the probe. I think my firmware is just crashing _hard_ somehow
<re_irc> <riskable> Well I've narrowed it down to a specific function inside "epd-waveshare":
<re_irc> /// Basic function for sending an array of u8-values of data over spi
<re_irc> ///
<re_irc> /// Enables direct interaction with the device with the help of [command()](Epd4in2::command())
<re_irc> <riskable> Well, I suppose it's that "write()" function
<re_irc> <riskable> (which just calls "spi.write(data)?;")
<re_irc> <adamgreig> room hi all, meeting time again! agenda's, please add anything you'd like to announce or discuss! it's been a fairly quiet week (at least on my inbox's rust-embedded tag...) so a slim agenda so far. we'll start in 5min or so :)
<re_irc> <adamgreig> riskable: i wonder if your spi pins are somehow interfering with swd
<re_irc> <adamgreig> or if the rp2040 is somehow having its bus blocked by the spi transfer and that's stopping the debugger too?
<re_irc> <riskable> adamgreig: Well the code is supposed to clear the screen but I can see that's not happening... Instead the whole thing resets and I get the startup screen
<re_irc> <Clark Kozak> should I put my name on the list if i'm just observing?
<re_irc> <adamgreig> you're welcome to! but you don't have to
<re_irc> <adamgreig> ok, let's start! couple of quick announcements, rust 1.60 is out thursday, though sadly naked functions didn't quite make the cut so we can't purge the last bits of weird assembly directives from cortex-m-rt just yet
<re_irc> <adamgreig> and for those who haven't seen, there's a series of fun/casual cross-team rust meetings called the CTCFT (cross-team collaboration fun times) which are organised every few weeks in various timezones to let different rust groups chat, there's a proposal to have one focused on embedded stuff, see for details
<re_irc> <adamgreig> see for more details on the meetings themselves
<re_irc> <adamgreig> anyone else have anything they'd like to announce?
<re_irc> <therealprof> I think James Munns was very keen on representing us.
<re_irc> <adamgreig> can also be fun blog posts or interesting things you've come across this week
<re_irc> <therealprof> Yes, was landed.
<re_irc> <James Munns> Oh yes, happy to do meet and greets!
<re_irc> <James Munns> (also, here!)
<re_irc> <therealprof> That was a hard one with many detours. 😅
<re_irc> <adamgreig> ah, yay on the teams PR!
<re_irc> <adamgreig> ok, there's a couple more points on the agenda, first up some open PRs for svd2rust: /
<re_irc> <adamgreig> 583 is new and i think pretty straightforwardly sensible, 541 is an older PR that dropped off the radar i guess, i need to check on the recent changes since my last review...
<re_irc> <therealprof> Yes and no.
<re_irc> <therealprof> burrbull asked me to put them on todays agenda.
<re_irc> <therealprof> The question about 583 was whether it's a worthy tradeoff to put addtional constants into the generated code.
<re_irc> <therealprof> Tradeoff being usefulness vs compile time hit.
<re_irc> <adamgreig> any measurements on compile time hit?
<re_irc> <adamgreig> from my experience in stm32ral i expect the constants shouldn't make a noticable difference but we should definitely check
<re_irc> <therealprof> From my experience anything that increases code volume and class size incurrs a performance hit and we're already doing not too great on that front.
<re_irc> <therealprof> But before we determine how bad that would be I'd be interested to here from potential users.
<re_irc> <dirbaio> agreed re compile times
<re_irc> <therealprof> * hear
<re_irc> <adamgreig> I guess a lot of users are going to do something more custom if they want the constants at all
<re_irc> <therealprof> Indeed.
<re_irc> <adamgreig> I was pondering if you could do something like the stm32ral macros just as macros on top of having these constants in the PAC
<re_irc> <adamgreig> so a few things like that might be neat, but it's not firm evidence of utilit
<re_irc> <adamgreig> * utility
<re_irc> <dirbaio> what's the use case? to me it looks like you'd only want them to bypass the "main" read/write/modify API, so maybe the question is whether the main API can be fixed to cover all the use cases
<re_irc> <therealprof> dirbaio: My thought exactly.
<re_irc> <dirbaio> for example you might want to "store" a register value as u32 and modify the fields on it
<re_irc> <dirbaio> without actually reading/writing it to the hardware?
<re_irc> <therealprof> I don't think we need an immediate answer but I do believe we should figure out whether there's a use case for this before adding it.
<re_irc> <adamgreig> 👍️, I don't have an immediate use case either but I think one could exist, having the constants exposed in the PACs feels useful somehow
<re_irc> <Clark Kozak> the more features the better! Just cuz you don't know the use case doesn't mean it won't be helpful
<re_irc> <dirbaio> > the more features the better
<re_irc> and before you know it, your PAC takes 10min to buidl :D
<re_irc> <dirbaio> * build
<re_irc> <adamgreig> we can't guess all the ways it will be helpful, but it would be good to know there's at least one or two such ways before we pay the compile-time hit
<re_irc> <therealprof> Clark Kozak: Err, not if it's contributing to an already large pain.
<re_irc> <Clark Kozak> Agreed! Compile time and speed are more important
<re_irc> <allexoll> if any of these will be documented in any way i think might break for a lot more crates
<re_irc> <adamgreig> what do you mean?
<re_irc> <adamgreig> the builds failing for the very large PACs?
<re_irc> <adamgreig> in my experience it's OK with lots of constants, works on despite having every constant for every field in every stm32
<re_irc> <dirbaio> adamgreig: not every stm32, there's 1200 of them :D
<re_irc> <adamgreig> (after breaking initially due to having 1.2 million html files lol)
<re_irc> <adamgreig> hmm, I think it has every constant for every field though, most of the stm32s have identical MMIO maps
<re_irc> <adamgreig> the variants it doesn't cover only differ in flash/ram/package, right?
<re_irc> <adamgreig> I don't think would like your version :P
<re_irc> <dirbaio> there's 400 different ones if you merge identical chips except flash/ram
<re_irc> <dirbaio> +size
<re_irc> <therealprof> ... and counting. 😅
<re_irc> <adamgreig> hah, yes, they keep coming 💀
<re_irc> <dirbaio> I did give up on
<re_irc> check out the chip picker at the top 😂
<re_irc> <adamgreig> anyway, my point is that the constants probably won't ruin the build, but they will have _some_ impact on build time
<re_irc> <adamgreig> and yea, we should check what that impact is
<re_irc> <therealprof> I'd do that after the determination of usefulness.
<re_irc> <therealprof> Just the timing of the difference takes significant amount of time.
<re_irc> <dirbaio> this is actually a pain I've had with svd2rust PACs, that the constants would solve kinda
<re_irc> <dirbaio> but I think there's better ways to do that, like allowing the read/write proxy structs to work on a value
<re_irc> <adamgreig> yea, but I wonder if it's worth having constants before we can/do change the api?
<re_irc> <dirbaio> chiptool ( does that by having "register value" structs example ( that wrap the u32
<re_irc> <therealprof> If GHA is any indication, at least it seems CI is running a fair bit slower on all stages I checked:
<re_irc> <dirbaio> and also read/write/modify use these. The downside is you can't have different values for reading and writing, which is not a good match for svd2rust's "support all crazy SVD features" goals
<re_irc> <adamgreig> I don't know that modelling "write 1 to clear" is such a wacky goal :P
<re_irc> <newam> therealprof: It works for a ballpark measurement, the 2 CPUs they allocate have a lot of variance from neighboring CI jobs.
<re_irc> <dirbaio> well
<re_irc> <dirbaio> in chiptool you just... write 1
<re_irc> <dirbaio> but it won't prevent you from writing 0, or make it "unsafe" to do so
<re_irc> <adamgreig> neither does svd2rust, you have to be able to write 0 to not-clear it anyway
<re_irc> <adamgreig> anyway
<re_irc> <adamgreig> the other point on the agenda is just a quick note that cortex-m's hardware-in-the-loop (and qemu-in-the-loop too) testing was merged, thanks to newam!
<re_irc> <adamgreig> now we just have to write lots of actual tests :D
<re_irc> <Clark Kozak> ooo tests! Is it possible for a new guy like me to write tests?
<re_irc> <newam> Clark Kozak: Yup, there's a README here on how it works if you're interested:
<re_irc> <Clark Kozak> just found that page too actually!! I'll take a look
* cr1901 forgot about DST again somehow
<re_irc> <adamgreig> i can't forget, it's still light driving home from work and even still light _now_, absolutely incredible
<re_irc> <therealprof> adamgreig: That's a clear indication you're not in Scotland then. 😀
<cr1901> Well better later than not at all?
<cr1901> :P
<re_irc> <adamgreig> it's light even longer in scotland now we're past the spring equinox!
<re_irc> <adamgreig> sunset there is about 15min after here, today
<re_irc> <therealprof> Scotland in Winter: It's dark when you go to lunch, it's dark when you get out of lunch.
<re_irc> <dirbaio> can't wait for DST to get abolished :P
<re_irc> <adamgreig> can't wait for the EU to abolish it and the UK stubbornly stick with it and it cause a huge rift on the irish border 😢
<re_irc> <Clark Kozak> Should I be able to do this entire tutorial in QEMU ?
<re_irc> <adamgreig> anyway good thing we've run out of agenda as we've gone somewhat off topic, I guess let's wrap up there unless anyone wanted to mention anything else?
<re_irc> <Clark Kozak> Is it possible to go through this tutorial still?
<re_irc> <adamgreig> yea, the old discovery on f3 is still totally valid
<re_irc> <adamgreig> I think probably qemu could run the rpi tutorials? not sure how well it models armv8
<re_irc> <newam> the pi ones should run on QEMU just fine, it's mostly doing MMU/GIC/translation table things which QEMU models well
<re_irc> <newam> Also if you're new to rust in general (and not just embedded rust) the rustlings tutorial is really good:
<re_irc> <Clark Kozak> I wanted to thank y'all for being so open, having all these great resources for beginners, answering my questions.
<re_irc> I'm not a very talented programmer or know much about Rust and embedded system, though the y'all really have paved the path to make it possible for someone with some programming experience to get started
<re_irc> Thank you all!
<re_irc> <andre-richter> Clark Kozak: Yes, full QEMU support (for RPi3).
<re_irc> <riskable> Why do I have to run "cargo run --release" twice every time I want to flash my RP2040-based board?
<re_irc> <riskable> ...and if I hit the reset button on the board that disconnects me from the probe which doesn't happen when I'm using that same probe with my STM32F411 board
<re_irc> <dirbaio> riskable: I've seen that too! No idea, would love to know why and fix it as well
<re_irc> <dirbaio> riskable: This is because RST also resets the SWD logic, it's how the chip is wired up. Other chips like nRF also do that, I think STM32 is the weird one here.
<re_irc> <riskable> dirbaio: Ahh. It's super annoying because it means I have to re-flash every time I reset in order to see debug messages
<re_irc> <dirbaio> probe-run has --no-flash but it disallows using it when using defmt
<re_irc> <dirbaio> I always patch it to allow it 😂
<re_irc> <riskable> I cannot get "probe-rs-debugger" to install. I keep getting linking errors
<re_irc> <dirbaio> try with --locked
<re_irc> <riskable> dirbaio: Tried "cargo install --git probe-rs-debugger --locked" but it didn't help
<re_irc> <riskable> Trying the non-git version now
<re_irc> <dirbaio> > warning: no Cargo.lock file published in probe-rs-debugger v0.12.0 (
<re_irc> <dirbaio> :(
<re_irc> <dirbaio> what error do you get?
<re_irc> <dirbaio> it installs fine for me
<re_irc> <Noah> dirbaio: we do not have the Cargo.lock committed because it's workspace shared and for a lib you actually do not want it. It was only later where we added tons of binaries to a point where it might be necessary.
<re_irc> <riskable> dirbaio: /usr/bin/ld: /tmp/cargo-installKLqMaI/release/deps/librusb-00e652d534ace684.rlib(rusb-00e652d534ace684.rusb.dc00654e-cgu.10.rcgu.o): in function `_ZN3std4sync4once4Once9call_once28_$u7b$$u7b$closure$u7d$$u7d$17hc4629d4876bae47aE.llvm.12325504550320277636':
<re_irc> rusb.dc00654e-cgu.10:(.text._ZN3std4sync4once4Once9call_once28_$u7b$$u7b$closure$u7d$$u7d$17hc4629d4876bae47aE.llvm.12325504550320277636+0x16): undefined reference to `libusb_init'
<re_irc> collect2: error: ld returned 1 exit status
<re_irc> = help: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
<re_irc> <riskable> (tail end of it)
<re_irc> <Noah> yeah, that message does not tell what's wrong ;) always post the full log :/
<re_irc> <riskable> I _do_ have "libusb-1.0-0-dev libftdi1-dev libudev-dev" installed
<re_irc> <Noah> do you also have libusb-dev?
<re_irc> <riskable> Noah: Here's the full log:
<re_irc> <riskable> Noah: Yes, that's installed
<re_irc> <Noah> riskable: that's not good :) please remove and purge it :)
<re_irc> <Noah> it's somehow not compatible with "libusb-1.0-0-dev"
<re_irc> <riskable> Bizarre
<re_irc> <Noah> "leave package managament to us distro maintaniners" ... good one I hear every day ...
<re_irc> <riskable> Noah: That did the trick! "probe-rs-debugger" is now installed 👍
<re_irc> <xgroleau> Are there guides on writing drivers for the embedded-hal other than the Embedded Rust Book? I started a driver for the mx25r tested on the nrf52dk. As of now I have a working but I'm not sure if I should move everything in traits, or keep in the struct impl and if typestate programming is standard or not. I come from C/C++ and went directly to embedded Rust so my experience is limited with the language.
<re_irc> <dirbaio> not afaik
<re_irc> <dirbaio> maybe looking at existing drivers is useful for inspiration
<re_irc> <dirbaio> and using your own driver yourself in a real project gives quite immediate feedback on whether the API is good :D
<re_irc> <dirbaio> for example with typestates, it becomes quite hard to have a struct own an instance of the driver while changing the state... I'm not a fan of typestates due to that
<re_irc> <dirbaio> > not sure if I should move everything in traits, or keep in the struct impl
<re_irc> <dirbaio> +what do you mean?
<re_irc> <xgroleau> dirbaio: Hmmm I see how it can be annoying when using the API
<re_irc> <xgroleau> dirbaio: As of now all the code is in the impl block of the struct. But idk if I should write traits for read write and implement the trait there or let the user do it.
<re_irc> <xgroleau> Here is the code. It is by no mean good Rust code and it's a WIP.
<re_irc> <dirbaio> ah
<re_irc> <xgroleau> Because as of now I need to declare all the generics parameters when I borrow the struct in a function since I'm not using traits.
<re_irc> <dirbaio> if there's "standard" traits, implementing them is nice
<re_irc> <dirbaio> for example in this case there's
<re_irc> <dirbaio> the point of traits here would be allowing writing generic code on top of multiple flash drivers, for example
<re_irc> <dirbaio> if there's no "standard" traits then defining your own doesn't help with that, they're still "your" traits
<re_irc> <dirbaio> it can help with reducing generics spam but it's a bit "weird", usually using type aliases for that is better
<re_irc> <xgroleau> dirbaio: I see, that definitely clarifies my understanding on the usage of traits.
<re_irc> <xgroleau> I'll try to implement the embedded_storage trait and see how it goes. Though I guess Ideally the trait would only be available if the write is enabled on the chip? Soooooo typestate it is?
<re_irc> <dirbaio> hahaha
<re_irc> <xgroleau> Though it's more to make sure the device is properly initialized vs managing state.
<re_irc> <dirbaio> if the user wants to change between readonly/readwrite at runtime, a typestate would be annoying
<re_irc> <dirbaio> if it's just "enable write at startup" then it might be ok..?
<re_irc> <xgroleau> But if the user is using the implementation of the nor_flash trait he could try to write when it's not enabled
<re_irc> <xgroleau> dirbaio: That is probably the sane thing to do and avoid overengineering things
<re_irc> <xgroleau> * avoids
<re_irc> <firefrommoonlight> xgroleau: I feel like a broken record with this but ... What project requirements are you writing the driver for?
<re_irc> <firefrommoonlight> If I had to pick one soft weakness in the Rust embedded ecosystem, it's writing libs without examining use cases and project requirements
<re_irc> <firefrommoonlight> * deletatious trend
<re_irc> <dirbaio> what makes you think they didn't? 🤔
<re_irc> <firefrommoonlight> Sorry good pt
<re_irc> <firefrommoonlight> Short answer is I'm pattern matching and it's usually true
<re_irc> <firefrommoonlight> You're right that I shouldn't have assumed
<re_irc> <firefrommoonlight> Short answer is I'm pattern matching and it's usually the case
<re_irc> <barafael> A platform-agnostic driver that takes into account project requirements isn't platform-agnostic, is it? Maybe I'm misunderstanding, though.
<re_irc> <dirbaio> right, if you want it for just one project you hardcode all the types 😂
<re_irc> <xgroleau> firefrommoonlight: It's more of a project to familiarize myself more with rust, but maybe it will be used to store data from multiple sensors. Though that is if we migrate to rust. So it's really just a hobby project to learn rust so the requirements are pretty slack.