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 (@9names:matrix.org)> struct fields are already aligned (with required padding) unless you specify packed. repr align will align the start of the struct.
<re_irc>
<9names (@9names:matrix.org)> the fields may be re-ordered to minimise padding unless you specify repr(C)
<re_irc>
<9names (@9names:matrix.org)> the nomicon (https://doc.rust-lang.org/nomicon/repr-rust.html) 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]> 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>
<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>
<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>
<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"): https://bpa.st/LHFQ
<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>
/// 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 https://hackmd.io/8lYix3OGSn27XVcwDw9_0Q, 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 https://github.com/rust-lang/ctcft/issues/30 for details
<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 docs.rs 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, http://docs.rs/stm32ral works on docs.rs 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 docs.rs 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 docs.rs would like your version :P
<re_irc>
<dirbaio> there's 400 different ones if you merge identical chips except flash/ram
<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> 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: https://github.com/rust-lang/rustlings
<re_irc>
<Clark Kozak> I JUST CAME ACROSS THAT YESTERDAY I WAS SO EXCITED
<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>
<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>
<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> 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.