<Darius>
the timing is pretty critical for these and if it's not right it can get very confusing
<re_irc>
<evils (@evils:nixos.dev)> Darius: yea, unfortunately it caught fire last time i used it
<Darius>
RIP
<re_irc>
<evils (@evils:nixos.dev)> i'll try to use the scope at the hackerspace, thanks for the suggestion
giripriyadarshan has joined #rust-embedded
giripriyadarshan has quit [Client Quit]
giripriyadarshan has joined #rust-embedded
<Darius>
I would suggest first trying with a single 1wire device and checking that the micro sees the presence pulse (and conversely does not see it when the device is disconnected)
<re_irc>
<Chris [pwnOrbitals]> Has anyone ever seen cases where the panic handler’s code causes miscompilation of the rest of the code ?
<re_irc>
<Chris [pwnOrbitals]> I might be onto a compiler bug but not sure how to troubleshoot it
<re_irc>
<Chris [pwnOrbitals]> basically I use some external memory in my program, and also use it in my panic handler. When the external memory init code is present in the panic handler, all other (non-panic) memory accesses fail, but when the external memory init code is commented in my panic handler, all memory accesses succeed
<re_irc>
<Chris [pwnOrbitals]> (the panic handler is "[inline(never)]")
<re_irc>
<Chris [pwnOrbitals]> Has anyone ever seen cases where the panic handler’s code causes miscompilation of the rest of the program ?
<re_irc>
<James Munns> Hard to say - it could be UB in your panic handler, or other related code. Especially if you are doing (a lot) of unsafe somewhere else, UB/miscompilations can show up in weird unexpected places
<re_irc>
<Chris [pwnOrbitals]> any idea how I could find the root issue ?
<re_irc>
<Chris [pwnOrbitals]> * to
<re_irc>
<Chris [pwnOrbitals]> * I
mattgirv has quit [Ping timeout: 260 seconds]
dc740 has joined #rust-embedded
emerent has joined #rust-embedded
re_irc has quit [Ping timeout: 248 seconds]
emerent has quit [Killed (tungsten.libera.chat (Nickname regained by services))]
thomas25 has quit [*.net *.split]
re_irc has joined #rust-embedded
agg has quit [Ping timeout: 268 seconds]
seer has quit [Ping timeout: 250 seconds]
starblue has quit [*.net *.split]
creich has quit [*.net *.split]
cr1901 has quit [*.net *.split]
emerent has quit [*.net *.split]
dc740 has quit [*.net *.split]
genpaku has quit [*.net *.split]
m5zs7k has quit [*.net *.split]
Foxyloxy has quit [*.net *.split]
WSalmon has quit [*.net *.split]
vancz has quit [*.net *.split]
Shell has quit [*.net *.split]
wose has quit [*.net *.split]
jr-oss_ has quit [*.net *.split]
sknebel has quit [*.net *.split]
jasperw has quit [*.net *.split]
SanchayanMaity has quit [*.net *.split]
Amanieu has quit [*.net *.split]
seds has quit [*.net *.split]
dnm has quit [*.net *.split]
dequbed has quit [*.net *.split]
re_irc has quit [*.net *.split]
neceve has quit [*.net *.split]
Rahix has quit [*.net *.split]
limpkin has quit [*.net *.split]
Lumpio- has quit [*.net *.split]
mightypork has quit [*.net *.split]
richardeoin has quit [*.net *.split]
dne has quit [*.net *.split]
cyrozap has quit [*.net *.split]
edm has quit [*.net *.split]
dreamcat4 has quit [*.net *.split]
stephe has quit [*.net *.split]
ni has quit [*.net *.split]
inara has quit [*.net *.split]
hifi has quit [*.net *.split]
crabbedhaloablut has quit [*.net *.split]
xnor has quit [*.net *.split]
seer has joined #rust-embedded
emerent has joined #rust-embedded
re_irc has joined #rust-embedded
dc740 has joined #rust-embedded
Foxyloxy has joined #rust-embedded
neceve has joined #rust-embedded
starblue has joined #rust-embedded
dne has joined #rust-embedded
genpaku has joined #rust-embedded
m5zs7k has joined #rust-embedded
WSalmon has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
creich has joined #rust-embedded
cr1901 has joined #rust-embedded
dnm has joined #rust-embedded
jr-oss_ has joined #rust-embedded
vancz has joined #rust-embedded
wose has joined #rust-embedded
Shell has joined #rust-embedded
limpkin has joined #rust-embedded
mightypork has joined #rust-embedded
richardeoin has joined #rust-embedded
Lumpio- has joined #rust-embedded
Rahix has joined #rust-embedded
seds has joined #rust-embedded
dequbed has joined #rust-embedded
xnor has joined #rust-embedded
hifi has joined #rust-embedded
ni has joined #rust-embedded
dreamcat4 has joined #rust-embedded
stephe has joined #rust-embedded
cyrozap has joined #rust-embedded
edm has joined #rust-embedded
jasperw has joined #rust-embedded
SanchayanMaity has joined #rust-embedded
sknebel has joined #rust-embedded
Amanieu has joined #rust-embedded
inara has joined #rust-embedded
agg has joined #rust-embedded
thomas25 has joined #rust-embedded
<re_irc>
<James Munns> Not easily :p
thomas25 has quit [Max SendQ exceeded]
Darius has quit [*.net *.split]
causal has quit [*.net *.split]
<re_irc>
<James Munns> Finding a minimal repro case is usually a good place to start, so you have less surface area to manually check/debug
<re_irc>
<James Munns> A good first sanity check is to see if it reproduces the same NOT in release mode
<re_irc>
<James Munns> It's not guaranteed, but compiler optimizations tend to "exploit" UB (or rather, make the "wrong" assumptions" based on assuming your code isn't UB)
mattgirv has joined #rust-embedded
<re_irc>
<James Munns> if the bad behavior still happens in debug mode, I might look harder at your other hardware/init code. If it does only happen in release mode, I'd try really hard to make a minimal repro case, by hacking out as much other code as possible until you find the minimal set required to trigger the bug.
<re_irc>
<James Munns> If you're cutting code, I'd make a ridiculous number of commits, to make it easier to bisect the error cases, sometimes the changes needed to trigger UB is super subtle
Darius has joined #rust-embedded
causal has joined #rust-embedded
<re_irc>
<James Munns> you might be able to diff the assembly/objdump/binary with and without your panic handler to see where things actually meaningfully change, but it might end up being too noisy to be helpful.
<re_irc>
Another good practice is to add as many sanity debug asserts as possible (which you can turn on in release mode with a profile setting), to see if:
<re_irc>
1. having the asserts changes the behavior
<re_irc>
2. try and catch the "weird" behavior as early as possible.
<re_irc>
<James Munns> If your code is relatively "stand alone", you could try testing/running the code on your PC with Miri or other sanitizers like ASAN/UBSAN, but if it's tightly couple to your HW or OS or something, that's going to be much harder.
<re_irc>
<James Munns> The rest of my "good" advice requires knowing a lot more about what your code is doing, so that's about all the "super general" advice I can give :p
<re_irc>
<James Munns> So, good luck, make a lot of commits, and take a lot of notes, and take walks when things start feeling impossible :p
thomas25 has joined #rust-embedded
giripriyadarshan has joined #rust-embedded
giripriyadarshan has quit [Client Quit]
<re_irc>
<riskable> I'm working with the "smart-leds" crate on my keyboard firmware and I want to implement some cool effects... Has anyone got any resources or just _decent programming patterns_ for handling such things?
<re_irc>
<chrysn (@chrysn:matrix.org)> Oh nice, that'll make a much nicer RIOT demo application than blinq ... and I won't even have a bad conscience for migrating to a different developer's tools :-D
<re_irc>
<James Munns> :D
<re_irc>
<James Munns> I use blinq for the simple monochromatic leds, and choreographer for the fancier rgb ones
<re_irc>
<James Munns> I've been doing some fun fixed-point math recently so I can run similar stuff on devices without an FPU (Cortex-M0+s, mostly), I need to port that in as an option too.
<re_irc>
<chrysn (@chrysn:matrix.org)> That's cool -- LED brightnesses are kind of logarithmic in their perception, but it's not like one'd really _need_ floats for that, conceptually. (They're just so often Just There...).
<re_irc>
<James Munns> Yup :)
<re_irc>
<James Munns> On Cortex-M4F (nrf52), it was easier to just smash everything with floats
<re_irc>
<James Munns> didn't work so well on an STM32G0
<re_irc>
<chrysn (@chrysn:matrix.org)> And if I finally get to run things on AVRs, this board will shine with it:
<re_irc>
<James Munns> choreographer is a little memory heavier than my balcony code, since it stores more state per pixel
<re_irc>
<James Munns> I haven't benchmarked it (the balcony code), but it's definitely faster than 3.8k cycles/led, since it's able to hit the rendering speed targets (see this tweet (https://twitter.com/bitshiftmask/status/1566558259066159105) for math)
<re_irc>
<James Munns> that's with all the RNG stuff and sine and LUT adjustment, etc.
<re_irc>
<chrysn (@chrysn:matrix.org)> I don't quite get yet from the documentation how it acts with multiple LEDs -- do you typically have one sequence and just access it with different offsets in different LEDs to get the motion impression, or is it separate sequences for all of them?
<re_irc>
<James Munns> for choreographer? Yeah, the idea is you have a "script" for each node
<re_irc>
<James Munns> that demo code does everything with an incrementing starting offset, which is what gives the "motion" effect
<re_irc>
<James Munns> (the choreographer demo code, not the balcony stuff, which is all random)
<re_irc>
<James Munns> Each LED becomes an "actor" (hence the crate name)
<re_irc>
<chrysn (@chrysn:matrix.org)> Yeah, the "script" makes even more sense then :-)
<re_irc>
<James Munns> what good is open source if you can't come up with elaborate puns for everything
<re_irc>
<chrysn (@chrysn:matrix.org)> Ah, works in standardization as well. Quoting one of the RFC8995 authors: "It took us a while to agree on a backronym for 'R' to make it sound like the canadian slang term for beer"
<re_irc>
<chrysn (@chrysn:matrix.org)> I should look around for embedded crates more often. The way how choreographer uses groundhog (demanding that the timer have a Default) could be a pattern well usable with the ztimer backend, and once one more PR is through, the default instanciation will ensure that the timer actually keeps running (versus switching off to save power) for as long as that rolling timer is around.
<re_irc>
<James Munns> Yeah, I don't think anyone but me uses groundhog, but I tend to use it everywhere :p
<re_irc>
<chrysn (@chrysn:matrix.org)> It's one of these things people keep implementing on their own, but with crates like groundhog we can find common languages.
<re_irc>
<James Munns> I'm open! It seems like most of the ecosystem (seems?) to be using embedded-time? But I haven't really kept track
<re_irc>
<James Munns> I was aiming for "dumb, but good" with groundhog, and would be open to PRs/usage, I just didn't need the bells + whistles of embedded-time (and I think I wrote groundhog before it was around, or as it was being written)
<re_irc>
<chrysn (@chrysn:matrix.org)> I'm not sold on embedded time -- it's storing human concepts, and I prefer these to be removed by the compiler.
<re_irc>
<James Munns> I'm not here to criticize other people's work, especially when I'm sure I don't understand it :)
<re_irc>
I just build stuff that is useful for me, and if other folks like it, it's out there.
giripriyadarshan has joined #rust-embedded
giripriyadarshan has quit [Client Quit]
<re_irc>
<adamgreig> room meeting time again! agenda is https://hackmd.io/VqwuzqiaS_-Evk55S4EvXg, please add anything you'd like to announce or discuss and we'll start in about 5 min :)
<re_irc>
<dirbaio> oh it's tuesday again already?
<re_irc>
<newam> it feels like it happens every week!
<cr1901>
adamgreig: Still preparing the issue, but made progress since last week. I'm not feeling particularly well, so I'll be in read-only mode
<re_irc>
<adamgreig> it sneaks up on me every time
<re_irc>
<adamgreig> especially since I was on holiday weds last week til yesterday so it feels like the last meeting was basically yesterday 😅
<re_irc>
<adamgreig> also yesterday was a public holiday here so it has super monday feels
<re_irc>
<adamgreig> which may be why i only got home at 19:01 😅
<re_irc>
<adamgreig> and https://github.com/rust-lang/rust/pull/78802/ which should allow network types like SocketAddr and Ipv4Addr to move to core, which would let things like smoltcp and embedded-nal etc all use them
<re_irc>
<thalesfragoso> adamgreig: Hmm, but there's nothing preventing someone from getting a &mut RegisterBlock, right ?
<re_irc>
<dirbaio> not with the safe API
<re_irc>
<thalesfragoso> Also, it should still apply if everything is inside the UnsafeCell, but we must be careful, because we use several UnsafeCell fields instead of a big UnsafeCell having everything
<re_irc>
<thalesfragoso> But I don't think our use case has a problem with that, no padding bytes or anything
<re_irc>
<adamgreig> hmm, from the actual code change I thought a &mut would still not get dereferenceable, I haven't checked in detail though
<re_irc>
<adamgreig> ah no, I see
<re_irc>
<thalesfragoso> It's just &UnsafeCell, &mut UnsafeCell<T> is basically &mut T
<re_irc>
<adamgreig> &mut would be UniqueBorrowed PointerKind which is dereferenceable
<re_irc>
<thalesfragoso> I haven't seen anyone using &mut for registers though. All methods take &self anyway
<re_irc>
<dirbaio> thalesfragoso: iiuc it's "if T contains an unsafecell somewhere then &T is not dereferenceable", not "everything is inside the UnsafeCell"
<re_irc>
<dirbaio> and you can't get a "&mut RegisterBlock" with the safe API anyway
<re_irc>
<thalesfragoso> dirbaio: Don't we also implement DerefMut for the proxies types returned by take ?
<re_irc>
<adamgreig> either way I think the future still lies with using pointers instead of references to memory mapped structs
<re_irc>
<thalesfragoso> No, we don't, sorry
<re_irc>
<adamgreig> the other quick announcement is critical-section 1.1.1 is out with a fix for poisoned mutexes in the std impl
<re_irc>
<adamgreig> and cr1901 gave me a quick update that he's making progress on the c-s bloat on msp430 and should have an issue filed soon
<re_irc>
<dirbaio> therealprof: those were required by clippy 🤷
<re_irc>
<dirbaio> the repo doesn't have a pinned clippy version
<re_irc>
<thalesfragoso> Weird, do we block PRs due to clippy ? I thought we used just for general warning
<re_irc>
<eldruin> clippy passing is not a requirement for a bors merge
<re_irc>
<thalesfragoso> Differently from rustfmt
<re_irc>
<eldruin> we should definitely pin the version, clippy is too volatile ATM
<re_irc>
<Tom> I have to say I really like chiptool compared to the svd2rust for a few reasons, is there path towards merge or replace?
<re_irc>
<Tom> even if the dereference thing is no longer an issue
<re_irc>
<eldruin> I have not managed to re-review #394, will try to do so this week
<re_irc>
<dirbaio> eldruin: oh now i remember. I actually noticed that and thought it was a mistake, so the PR changes it to enforce... 😓
<re_irc>
<eldruin> ah, no we should not do that, clippy changes back and forth a lot
<re_irc>
<Tom> being able to describe register maps in yaml was surprisingly easy on the eyes and the code generated was quite nice
<re_irc>
<dirbaio> imo i can't see why not enforce clippy (as long as we pin it)
<re_irc>
<dirbaio> it's weird to have red stuff in CI that's actually not blocking
<re_irc>
<dirbaio> but no strong opinion from me though, i'll revert it on this PR
<re_irc>
<dirbaio> and then we can discuss it in a separate PR
<re_irc>
<James Munns> (sorry for speaking out of turn, but I'm about to run out the door: This is happening again this month, in 10 days, I will poke more aggressively next week, but same deal: I want everyone to hype their projects at the end of the month, feel free to start DMing RE twitter or DM me here on Matrix, and I'll add you to the queue: https://twitter.com/rustembedded/status/1561362532832579590 - consider this the first early reminder if you're...
<re_irc>
... working on something atm)
<re_irc>
<dirbaio> (I only changed it because I thought it the intent was to enforce)
<re_irc>
<therealprof> It would be great to have the feelings of clippy addressed separately.
<re_irc>
<adamgreig> (thanks James Munns!)
<re_irc>
<adamgreig> Tom, there's no active plan atm, my feeling is some move in that direction makes sense but i don't know exactly what it looks like and currently no one's pushing for it with any urgency
<re_irc>
<thalesfragoso> The error in that example would be nasty, but I guess the docs are very clear, so...
<re_irc>
<GrantM11235> The error looks the same when you change "Some(bus)" to "Some(&mut *bus)"
<re_irc>
<adamgreig> (gotta run, thanks all! 👋)
tokomak has quit [Ping timeout: 244 seconds]
<re_irc>
<GrantM11235> dirbaio: wasn't there a nightly feature that made it Just Work ™️ without any workarounds?
<re_irc>
<GrantM11235> It was either the new trait solver or the new borrow checker
<re_irc>
<thalesfragoso> GrantM11235: Thanks for checking
<re_irc>
<dirbaio> GrantM11235: -Zchalk can deal with projections under "for<'a>" better
<re_irc>
<dirbaio> but it's nowhere near production ready, for example generators/async is not implemented at all :D
<re_irc>
<GrantM11235> I just checked all four convenience methods with all for combinations. They all work with "move |bus| async move {}", read works with "move |bus| async {}" and transfer_in_place works with "|bus| async move {}". All other combinations don't work
<re_irc>
<dirbaio> wat
<re_irc>
<GrantM11235> exactly
<re_irc>
<dirbaio> why would "read" work with one and "transfer_in_place" with the other??
<re_irc>
<dirbaio> they're the same, just a "buf: &mut [u8]"
<re_irc>
<GrantM11235> wait
<re_irc>
<GrantM11235> False alarm, spreadsheet mishap. It is "|bus| async move {}" for both
<re_irc>
<dirbaio> hmm so... the reason why "no move at all" doesn't work is due to the "&mut" we obtain from the raw pointer?
<re_irc>
<dirbaio> it lives for the closure only
<re_irc>
<dirbaio> so the future can't borrow it because it outlives the closure (it's returned from it)
<re_irc>
<dirbaio> so it has to move it
<re_irc>
<dirbaio> but if you do "async move{}" it moves that... AND everything else, which is not what you want
<re_irc>
<dirbaio> so is this caused by the anti-smuggling trick?
<re_irc>
<dirbaio> if the macro forces using "move" it's going to be super unergonomic, because it'll try to move the buffer into the future which is not what you want
explore has joined #rust-embedded
<re_irc>
<GrantM11235> I get the same results when I deref the pointer inside the async block
<re_irc>
<dirbaio> ah I see why the helpers need "move": it's because they're not "async fn"s, they're returning the future
<re_irc>
<dirbaio> in normal async code (like the cyw43 snippet above) it works fine without "move"
<re_irc>
<dirbaio> > error[E0200]: the trait "embedded_hal_async::spi::SpiDevice" requires an "unsafe impl" declaration
<re_irc>
oh oops, we already need embedded-hal-async 0.2 :D
<re_irc>
<dirbaio> GrantM11235: I meant that, if we find we need either "two "move"s" or "no "move"", we could simplify the macro syntax so there's only one "move"
<re_irc>
<dirbaio> like make it mirror the syntax of sync closures
<re_irc>
<dirbaio> instead of the current "async block inside sync closure"
<re_irc>
<dirbaio> but it's probably not worth it
<re_irc>
<dirbaio> better to not get "creative" with macro syntax
<re_irc>
<GrantM11235> Yeah, I would like to keep the syntax identical to the ideal transaction method if possible
<re_irc>
<GrantM11235> So that someday we can just replace "transaction_helper!" with "SpiDevice::transaction" with no other changes
<re_irc>
<dirbaio> makes sense
<re_irc>
<dirbaio> sounds good to me then
<re_irc>
<dirbaio> the only weird thing is the macro being exported with 2 names
<re_irc>
<dirbaio> thalesfragoso: just tried this, it doesn't work
<re_irc>
<dirbaio> error[E0364]: `spi_transaction_helper` is only public within the crate, and cannot be re-exported outside
<re_irc>
<GrantM11235> I saw someone talking about it on the rust forums, they said it should be pretty easy to fix, but I guess no one ever got around to it
<re_irc>
<dirbaio> omg that workaround... "#[cfg(nightly)] pub macro $name {"... MY EYES
<re_irc>
<GrantM11235> Did you ever look in to the "send"/"sync" situation?
<re_irc>
<dirbaio> with the transaction macro?
<re_irc>
<dirbaio> I think it's OK now that it derefs the pointer outside the async{} block
<re_irc>
<dirbaio> so the future only ever "owns" the "&mut Bus", which should make it impl the right send/sync automatically
<re_irc>
<GrantM11235> Do the SpiDevice docs need to mention send/sync in the safety contract?
<re_irc>
<dirbaio> hmmm
<re_irc>
<dirbaio> i don't think so?
<re_irc>
<dirbaio> the future returned by the user should autoimpl send/sync as required in all cases
<re_irc>
<dirbaio> if anything, if the user holds the raw pointer for _too long_ it'll make the future _not_ send/sync when it should
<re_irc>
<dirbaio> which can't cause unsoundness
<re_irc>
<GrantM11235> Are you allowed to "send" the pointer and deref it in another thread/isr?
<re_irc>
<dirbaio> raw pointers are always !Send, !Sync
<re_irc>
<GrantM11235> What happens if you deref the pointer and then send the reference?
<re_irc>
<GrantM11235> I think you would need to use something like scoped-threads to send a non-static reference
<re_irc>
<GrantM11235> If the SpiDevice impl has a "!Send" refcell "Ref<T>", it has to turn it in to a raw pointer, then the transaction helper turns that in to a reference, which is "Send" as long as T is
<re_irc>
<GrantM11235> Maybe the SpiDevice impl would need to give a "*mut Ref<T>" instead of a "*mut T"
<re_irc>
<GrantM11235> Except "Ref" has a lifetime, so we are right back where we started
<re_irc>
<dirbaio> GrantM11235: sending a "&mut T" is always fine (if "T: Send") even if it points to inside a RefCell
<re_irc>
<dirbaio> as long as the "&mut T" only exists while the RefCell is locked
<re_irc>
<dirbaio> * borrowed
<re_irc>
<dirbaio> it's hard to do because sending usually requires "'static"
<re_irc>
<dirbaio> you could do it with scoped threads
<re_irc>
<dirbaio> * but you can
<re_irc>
<dirbaio> and the borrow checker will enforce the child thread has exited before allowing you to unborrow the RefCell
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 268 seconds]
cr1901_ is now known as cr1901
crabbedhaloablut has quit [Remote host closed the connection]