<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!
<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>
<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> 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>
<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>
<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>
<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>
<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>
<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> 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 (https://github.com/rafalh/rust-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 https://github.com/embassy-rs/embassy/blob/master/embassy-hal-common/src/ring_buffer.rs 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?