ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
emerent has quit [Ping timeout: 244 seconds]
emerent has joined #rust-embedded
explore has joined #rust-embedded
fabic has joined #rust-embedded
_whitelogger has joined #rust-embedded
fooker has joined #rust-embedded
jasperw has joined #rust-embedded
stephe has quit [*.net *.split]
cr1901 has quit [*.net *.split]
thomas25 has quit [*.net *.split]
stephe has joined #rust-embedded
cr1901 has joined #rust-embedded
thomas25 has joined #rust-embedded
balaa[m] has quit [*.net *.split]
seds has quit [*.net *.split]
darknighte has quit [*.net *.split]
seds has joined #rust-embedded
darknighte has joined #rust-embedded
balaa[m] has joined #rust-embedded
Abhishek__ has joined #rust-embedded
rektide_ has joined #rust-embedded
Abhishek_ has quit [Ping timeout: 272 seconds]
Abhishek__ is now known as Abhishek_
agg has quit [Ping timeout: 272 seconds]
rektide has quit [Ping timeout: 272 seconds]
richardeoin has quit [Ping timeout: 272 seconds]
ni has quit [Ping timeout: 272 seconds]
richardeoin has joined #rust-embedded
bjc has left #rust-embedded [ERC 5.4 (IRC client for GNU Emacs 28.1)]
agg has joined #rust-embedded
ni has joined #rust-embedded
gsalazar has joined #rust-embedded
<re_irc> <taunusflieger> 9names: 9names -+
<re_irc> <Campbell He> Simon Sapin: I guess you want to implement a program runs on RV bare-metal. Maybe the first chapter of the blog_os ( and the rustsbi ( will help you.
crabbedhaloablut has quit [*.net *.split]
crabbedhaloablut has joined #rust-embedded
Amadiro__ has joined #rust-embedded
Amadiro_ has quit [Ping timeout: 248 seconds]
fabic has quit [Ping timeout: 246 seconds]
starblue has quit [Ping timeout: 276 seconds]
starblue has joined #rust-embedded
fabic has joined #rust-embedded
<re_irc> <Udayakumar Hidakal> Hi all,
<re_irc> After flash erasing and rewriting to the same sector in that case it's not writing to the sector, sector remains "FFFF"'s only , and also i am not able to read flash from the "stm32 cube programmer", for reading flash again i have to download some normal "Led blink" program.
<re_irc> I am working in "stm32f746" board and i am facing some flash rewriting problem.
<re_irc> - "stm32 cube programmer" showing error like this "Error : ST-LINK error (DEV_TARGET_NOT_HALTED)", is there any solutions?
fabic has quit [Ping timeout: 264 seconds]
talperud has joined #rust-embedded
<re_irc> <chemicstry> Udayakumar Hidakal: what kind of board is it? is it custom or a dev board from st? I had similar issues when your program changes swd pin mode and hardware reset is not wired to debugger so it can not override
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 246 seconds]
<re_irc> <James Munns> looks like atsam-rs is having a release day lol
<re_irc> <James Munns> ~70 PACs in the docs queue :p
<re_irc> <bugadani> _butterfly meme_ is this ddos?
<re_irc> <James Munns> last call on "postcard" bugs! Just released v1.0.0-alpha.4, this WILL be the last change (modulo bugs found) before the 1.0 release in the next 6-8 hours or so!
causal has joined #rust-embedded
<re_irc> <Udayakumar Hidakal> chemicstry: i am using nucleo-f746 dev board.
<re_irc> <chemicstry> ah, anyway it seems to be an issue with your (rust?) program, as it interferes with debugger. Is it a simply blinky or are you doing something else (for exmaple writing flash)?
<re_irc> <chemicstry> * example
<re_irc> <chemicstry> for exmaple here it says that if you initiate flash erase at the start of the program it interferes with st-link flashing, adding a delay resolves it
talperud has quit [Ping timeout: 248 seconds]
talperud has joined #rust-embedded
<re_irc> <lulf> James Munns: I gave it a spin the other day, it just works :)
<re_irc> <wassasin> Udayakumar Hidakal: if you are using "probe-rs", there is a known problem with the ST-Link crashing when debugging a STM32 that performs an erase operation
<re_irc> <wassasin> In which case your STM32 also stops running, which might be what you are seeing. Assuming you are using "probe-rs".
fabic has joined #rust-embedded
<Lumpio-> Unplugging the probe so it resets is always a good idea, makes sure it's not the probe having a problem instead of the target
<re_irc> <Lumpio−> Man this Heisenbridge thing sure is wordy
<re_irc> <hifi> it's a Dendrite bug with room membership
<re_irc> <firefrommoonlight> Can we ban it
<re_irc> <firefrommoonlight> I tried to mark it as Spam and ignore user, but got an Error 429, whatever that means
<re_irc> <firefrommoonlight> Btw, just watched this video -
<re_irc> <firefrommoonlight> In it, Jonathan Blow makes a point that if you conduct an experiment where you write down all times software shows bugs or unsuspected effects to the user, you will create a large list very fast, and won't even think that's weird because you're so used to software being crap
<re_irc> <James Munns> Ban Heisenbridge?
<re_irc> <James Munns> That's how we bridge to IRC.
<re_irc> <newam>
<re_irc> <James Munns> And Jonathan Blow certainly has opinions. I don't often agree with all of them :D
<re_irc> <James Munns> Heisenbridge is ALSO how we have persistent HTML logs of this room.
<re_irc> <firefrommoonlight> yea but it's annoying
<re_irc> <firefrommoonlight> It doesn't have to post
<re_irc> <hifi> the dendrite it runs on is buggy, the bridge itself is fine but it falls back to sending an overly verbose message if it detects messages come from out-of-channel
<re_irc> <firefrommoonlight> *Oh I think I get it
<re_irc> <firefrommoonlight> nvm
<re_irc> <firefrommoonlight> James Munns: I agree with most of his opinions, although not on manual memory management
<re_irc> <firefrommoonlight> Borrow checker is v nice
<re_irc> <firefrommoonlight> I think by nature, his opinions will alienate most professional devs since he poses an identity crisis, which no one responds well to!
<re_irc> <almindor> do we still expect any API breakages in embedded-hal [master] wrt. SPI/SpiDevice split code?
<Lumpio-> I don't have to post? :(
Amadiro_ has joined #rust-embedded
<re_irc> <James Munns> I like your posts Lumpio!
<re_irc> <James Munns> And Amanieu, even when his messages don't come through lol
Amadiro__ has quit [Ping timeout: 264 seconds]
<Lumpio-> Aww, thank you!
<Lumpio-> I seem to remember the bridge was less spammy on the Matrix side though.
<re_irc> <firefrommoonlight> I misread. Was mentally filtering the posts because they look weird
<re_irc> <James Munns> It's mostly just a few users, I think it's because you also exist here as Lumpio− (that's your matrix handle), so it tries not to impersonate you I think?
<Lumpio-> Hmm
<re_irc> <James Munns> I think that was Amanieu's problem too. Everyone else from matrix gets bridged "normally", your messages just look jank/extra bot-y
<Lumpio-> I think I even tried to use a weird unicode dash in my Matrix name
<Lumpio-> Let's see if just removing it fixes it
<re_irc> <James Munns> (still looks jank so far)
<Lumpio-> Hello
<re_irc> <Lumpio> Meh
Lumpio- has left #rust-embedded [WeeChat 3.1-dev]
Lumpio- has joined #rust-embedded
<Lumpio-> And again
<Lumpio-> Oh it only checks on join, looks better now.
<re_irc> <James Munns> Looks good!
fabic has quit [Ping timeout: 268 seconds]
<re_irc> <James Munns> 🍾
<re_irc> <bugadani> With probably the fastest rust leb128 implementation out there :D :D
<re_irc> <James Munns> If you start saying that out loud, someones going to start going all SIMD on us :p
<re_irc> <bugadani> I'd say show me SIMD on Xtensa LX6 and I'll retract my statement ^^
<re_irc> <bugadani> James Munns: By the way, what do you think about somehow controlling how fields get encoded? signed integers sometimes could have better represented as classic leb128 signed, not zig-zag (when a value is permitted to be negative, but is not expected to be)
<re_irc> <James Munns> I don't _really_ want any tunables, tbh
<re_irc> <James Munns> if you have a specific use case, then you can always impl a custom ser/de for your type!
<re_irc> <bugadani> got you, "MostlyPositive<T>" it is, then 😅
<re_irc> <James Munns> :D
<re_irc> <James Munns> I did land the "FixedIntLE<T>" and "FixedIntBE<T>" types, which do "old style" non-varint serialization
<re_irc> <bugadani> I have no idea which I would prefer... those or "#[postcard(fixed_width)]"
<re_irc> <bugadani> I somewhat lean to the latter, but attributes are ugly
<re_irc> <James Munns> I'm just plain bad at macros, proc or otherwise
<re_irc> <James Munns> Only reason the new features (max size and schema) exist is because Lachlan wrote them lol
<re_irc> <bugadani> Nah, writing them is a breeze (
<re_irc> <Lachlan> bugadani: I think it’d be hard to do this without postcard doing the serialize impl
<re_irc> <bugadani> hard is trying to represent enum variants out of order (spent an hour and a half porting some code of mine, then realizing postcard isn't really suitable 😅 )
<re_irc> <James Munns> ah yeah
<re_irc> <James Munns> I looked at that
<re_irc> <James Munns> there's serde_repr
<re_irc> <James Munns> but that only works with valueless enums
<re_irc> <James Munns> otherwise serde only gives you the "enum index"
<re_irc> <bugadani> James Munns: TIL, that's something
<re_irc> <firefrommoonlight> Hi - Do y'all know any DRY-busting tips for sharing structs and enums between devices (firmware), and Rust-coded desktop software used to config the firmware?
<re_irc> <firefrommoonlight> I've been using a "from_firmware" copy+paste module on the desktop software (using firmware as master), but this is a DRY / sync hazard
<re_irc> <James Munns> I usually have a "common" crate that is also no_std, and use it for data defs
<re_irc> <bugadani> firefrommoonlight: "#[repr(C)]" on your structs
<re_irc> <James Munns> wait, why repr(c)?
<re_irc> <firefrommoonlight> Yea, that's prob the answer. I guess the Q is is having the extra complexity associated with a 3rd module (cargo.toml etc) worth it over teh copy+paste approach
<re_irc> <bugadani> nah I was overcomplicating and thinking about sharing in-memory representation 🤣
<re_irc> <firefrommoonlight> bugadani: Thanks - how would that work in this case?
<re_irc> <bugadani> firefrommoonlight: sorry, brainfart on my part
<re_irc> <dirbaio> +1 for shared crates, also keep them all in the same repo to avoid cargo git spaghetti hell
<re_irc> <firefrommoonlight> Same repo's a good idea. Currently the 2 softwares are not in the same repo, but that could certainly help
<re_irc> <James Munns> There's a desktop app and embedded firmware in there
<re_irc> <firefrommoonlight> Nice - examples are great
<re_irc> <firefrommoonlight> Nice - exactly what I'm looking for
<re_irc> <firefrommoonlight> (Context: "Preflight" software for quad/fixed-wing drone firmware, werein you make sure all systems work)
<re_irc> <firefrommoonlight> I'll refactor into a third, shared crate for teh types in question
<re_irc> <Lachlan> Just realized I should’ve use #[serde(with = …)] support for fixed sized ints in postcard instead of new types
<re_irc> <James Munns> No worries, it's still experimental, no semver guarantees :D
<re_irc> <James Munns> oh
<re_irc> <James Munns> nevermind
<re_irc> <James Munns> no it's not lol
<re_irc> <James Munns> too late, shipped
<re_irc> <James Munns> open an issue for postcard 2.0
<re_irc> <James Munns> (or a "fixint2" module)
<re_irc> <bugadani> is that the quickest feature ever to be deprecated?
<re_irc> <James Munns> the docs aren't even live yet!
<re_irc> <James Munns> (still 38 atsam pacs to go)
<re_irc> <bugadani> I see I was semi-right with my ddos joke
<re_irc> <dirbaio> you can still yank 😂
<re_irc> <James Munns> postcard alpha.4 still hasn't been published yet
<re_irc> <firefrommoonlight> This postcard release is rmarkably apt for the question I posted about...
<re_irc> <firefrommoonlight> Maybe
<re_irc> <firefrommoonlight> I've been manually serializing/desrializing structs
<re_irc> <James Munns> That seems unpleasant!
<re_irc> <firefrommoonlight> eg stuff like:
<re_irc> /// 4 f32s = 16. In the order we have defined in the struct.
<re_irc> fn from(p: [u8; QUATERNION_SIZE]) -> Self {
<re_irc> impl From<[u8; QUATERNION_SIZE]> for Quaternion {
<re_irc> <firefrommoonlight> (And that's one of the smaller examples lol)
<re_irc> <firefrommoonlight> Keeping in sync between ser and deser is fragile
<re_irc> <firefrommoonlight> Would PC help here?
<re_irc> <dirbaio> lol it's been bulding atsamd pacs for 9h and it's only halfway done 😂
<re_irc> <James Munns> you know "#[derive(Serialize, Deserialize)]" is a thing, right? :D
<re_irc> <firefrommoonlight> yea; been a while though
<re_irc> <bugadani> James Munns: I knew it and still rolled my own worse serde...
<re_irc> <firefrommoonlight> So you can auto derive?
<re_irc> <James Munns> Like, in that example I sent you:
<re_irc> <James Munns> literally the ENTIRE wire spec is in that file
<re_irc> <James Munns> there is no other code
<re_irc> <James Munns> it's all derived.
<re_irc> <Lachlan> James Munns: Quick! Yank it!
<re_irc> <Lachlan> Nah, it’s fine haha
<re_irc> <firefrommoonlight> I should probably refactor. Current approach is fragile when I change things
<re_irc> <dirbaio> guess publshing 70 pacs is a way to get docs for every single chip
<re_irc> <dirbaio> someone try that with the 1200 stm32 chips
<re_irc> <dirbaio> * should try that with the 1200 stm32 chips 🔥
<re_irc> <bugadani> dirbaio: and doc generation for pacs is still like 900x faster than a year and a half ago, imagine what it would feel like now
<re_irc> <James Munns> firefrommoonlight: serde+postcard will likely be as fast and smaller on the wire (and WAY less error prone) than anything handrolled
<re_irc> <James Munns> The only usual downside is that the derived code can be a little bloaty
<re_irc> <dirbaio> svd2rust has been adding stuff though, pacs compile slower now (and probably doc slower?)
<re_irc> <firefrommoonlight> Thx for info!
<re_irc> <dirbaio> +to the generated code
<re_irc> <James Munns> but bloaty is relative
<re_irc> <firefrommoonlight> Hackign at it now
<re_irc> <firefrommoonlight> Yea, I think it's important to make case-by-case calls for things like this
<re_irc> <James Munns> I mean, "serde+postcard unless proven otherwise" is my go to
<re_irc> <James Munns> I am admittedly biased though
<re_irc> <James Munns> heck, I'm even using it as my syscall ABI for mnemos :p
<re_irc> <bugadani> James Munns: are we brainstorming bad ideas? varargs using serde!
<re_irc> <dirbaio> and gzip it for more compact arg passing!
<re_irc> <dirbaio> postcard deflate flavor when
<re_irc> <James Munns> honestly, pre 1.0 release, postcard already does pretty well in speed and size:
<re_irc> <James Munns> 1.0 will be roughly the same size on those benchmarks, but likely stupid faster, after adding inlines (that benchmark doesn't use LTO)
<re_irc> <bugadani> how can you improve 3x on it (looking at speedy...)
<re_irc> <James Munns> (that's my pre-release benches, "postcard" is basically 0.7, "postcard-rework-flavors" is pretty close to 1.0)
Amadiro__ has joined #rust-embedded
gsalazar_ has joined #rust-embedded
<re_irc> <James Munns> some of those other ones like speedy, alkahest, and rkyv are not using serde
<re_irc> <James Munns> and have some other approaches that work better in some cases.
<re_irc> <James Munns> and "abomonation" is basically just a memcpy lol
starblue has quit [Ping timeout: 240 seconds]
<re_irc> <bugadani> name checks out then
Amadiro_ has quit [Ping timeout: 264 seconds]
<re_irc> <James Munns> it's basically used in HPC clusters where they KNOW every device is exactly the same
gsalazar has quit [Ping timeout: 264 seconds]
<re_irc> <James Munns> so yolo memcpy is fine
<re_irc> <bugadani> "Warning: Abomonation should not be used on any data you care strongly about," LOL
starblue has joined #rust-embedded
<re_irc> <bugadani> love the warnings - embedded dma support when?
<re_irc> <bugadani> anyhow, after hijacking this thread for some time, congrats on the postcard release!
<re_irc> <dirbaio> abodmanation
<re_irc> <Lachlan> postcard impl in amaranth when
<re_irc> <James Munns> Lachlan: Tbh you could probably get the schema formatter to spit out hdl
dc740 has joined #rust-embedded
<re_irc> <Lachlan> I bet you could, yeah
<re_irc> <Lachlan> Or a python module for amaranth could do the same
Amadiro has joined #rust-embedded
Amadiro__ has quit [Ping timeout: 240 seconds]
<re_irc> <Ivan Levitskiy> Still having trouble with fatfs ( Seems like the filesystem has Send implemented for it, but the files don't. I'd like to log data into a file from an interrupt task in rtic, but I can't get an open file in it without opening it in the interrupt and opening a file at 1khz seems like not the best idea
<re_irc> <Ivan Levitskiy> Could there be a reason why send is not implemented for files?
<re_irc> <James Munns> Maybe their library isn't thread safe in some way, or takes a reference to the FS itself?
<re_irc> <James Munns> a decently common pattern for this would be to use some kind of Send/Sync queue to send data to one thread, that does the writing to the file itself
<re_irc> <Ivan Levitskiy> Or maybe a better way would be to have a data buffer where I collect the readings and just batch write them when it fills up
<re_irc> <mabez> Ivan Levitskiy: This is what I did when using fatfs with rtic
<re_irc> <James Munns> it takes a reference to the FileSystem
dc740 has quit [Remote host closed the connection]
<re_irc> <Ivan Levitskiy> Any recommendations for a circular buffer crate? Or should I do double buffers?
gsalazar_ has quit [Ping timeout: 246 seconds]
bjc has joined #rust-embedded
<re_irc> <chemicstry> Ivan Levitskiy: for byte slices or arbitrary types? For slices, embassy has a lightweight implementation but I'm not sure if you can use it without pulling a bunch of dependencies. Or if you need to store arbitrary types, then try heapless::spsc (it's also atomic)
<re_irc> <firefrommoonlight> Why are you looking for a dependency?