<M9names[m]>
but you should be able to include libm and the libm ext traits and it should work
<dinkelhacker>
oh yeah sure... i've been looking into std instead of core silly me.
mrkajetanp has joined #rust-embedded
<dinkelhacker>
but you might be able to use core::intrinsics::sqrtf32
<korken89[m]>
dinkelhacker: This one also does not exist :( It's as 9names say it's not in `core` yet
mrkajetanp has quit [Ping timeout: 252 seconds]
mrkajetanp has joined #rust-embedded
<dinkelhacker>
It works for me. You should be able to use it. Its unstable of course so you have to use #![feature(core_intrinsics)]
<korken89[m]>
That's what I meant by not working :) Just using it anyways might be fine though, does not feel like something they will remove anytime soon.
<JamesMunns[m]>
basically target features for asm blocks don't get passed right in LTO because of an LLVM bug
<korken89[m]>
Aaaah
<korken89[m]>
Sneaky
<korken89[m]>
Thanks for finding!
Foxyloxy has joined #rust-embedded
Foxyloxy__ has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 265 seconds]
Foxyloxy_ has quit [Ping timeout: 260 seconds]
Foxyloxy_ has joined #rust-embedded
mrkajetanp has joined #rust-embedded
Foxyloxy has quit [Ping timeout: 246 seconds]
Foxyloxy has joined #rust-embedded
sugoi has quit [Ping timeout: 246 seconds]
Foxyloxy___ has joined #rust-embedded
Foxyloxy__ has quit [Ping timeout: 246 seconds]
mrkajetanp has quit [Ping timeout: 246 seconds]
Foxyloxy_ has quit [Ping timeout: 246 seconds]
Foxyloxy has quit [Ping timeout: 246 seconds]
mrkajetanp has joined #rust-embedded
sugoi has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 244 seconds]
Foxyloxy has joined #rust-embedded
mrkajetanp has joined #rust-embedded
sugoi has quit [Ping timeout: 260 seconds]
Foxyloxy_ has joined #rust-embedded
Foxyloxy___ has quit [Ping timeout: 246 seconds]
Foxyloxy__ has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 246 seconds]
Foxyloxy has quit [Ping timeout: 244 seconds]
Foxyloxy has joined #rust-embedded
Foxyloxy_ has quit [Ping timeout: 244 seconds]
mrkajetanp has joined #rust-embedded
Foxyloxy__ has quit [Ping timeout: 244 seconds]
Foxyloxy_ has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 255 seconds]
Foxyloxy has quit [Ping timeout: 244 seconds]
mrkajetanp has joined #rust-embedded
Foxyloxy has joined #rust-embedded
sugoi has joined #rust-embedded
Foxyloxy_ has quit [Ping timeout: 252 seconds]
mrkajetanp has quit [Ping timeout: 252 seconds]
<thejpster[m]1>
My that github avatar looks like a handsome fellow
<thejpster[m]1>
I found this one writing Cortex-R demo code and it wouldn’t let me set up the FPU. Very annoying.
sugoi has quit [Ping timeout: 246 seconds]
mrkajetanp has joined #rust-embedded
<thejpster[m]1>
chrisnc fixed it but accidentally used some internal LLVM API and so they won’t merge it. I think it’s still stuck waiting on a stable API we can use?
Foxyloxy_ has joined #rust-embedded
Foxyloxy has quit [Ping timeout: 252 seconds]
mrkajetanp has quit [Ping timeout: 248 seconds]
mrkajetanp has joined #rust-embedded
Foxyloxy has joined #rust-embedded
Foxyloxy__ has joined #rust-embedded
Foxyloxy_ has quit [Ping timeout: 248 seconds]
Foxyloxy has quit [Ping timeout: 252 seconds]
Foxyloxy__ has quit [Ping timeout: 252 seconds]
mrkajetanp has quit [Ping timeout: 260 seconds]
mrkajetanp has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 272 seconds]
mrkajetanp has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 246 seconds]
mrkajetanp has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 252 seconds]
mrkajetanp has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 260 seconds]
GuineaWheek[m] has quit [Quit: Idle timeout reached: 172800s]
mrkajetanp has joined #rust-embedded
starblue has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 246 seconds]
mrkajetanp has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 252 seconds]
sugoi has joined #rust-embedded
sugoi has quit [Ping timeout: 252 seconds]
mrkajetanp has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 260 seconds]
mrkajetanp has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 252 seconds]
mrkajetanp has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 246 seconds]
mrkajetanp has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 260 seconds]
sugoi has joined #rust-embedded
sugoi has quit [Ping timeout: 265 seconds]
mrkajetanp has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 246 seconds]
mrkajetanp has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 246 seconds]
mrkajetanp has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 255 seconds]
mrkajetanp has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 260 seconds]
mrkajetanp has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 246 seconds]
sugoi has joined #rust-embedded
sugoi has quit [Ping timeout: 252 seconds]
mrkajetanp has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 264 seconds]
cr1901 has joined #rust-embedded
mrkajetanp has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 246 seconds]
mrkajetanp has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 252 seconds]
AugustoRoman[m] has quit [Quit: Idle timeout reached: 172800s]
mrkajetanp has joined #rust-embedded
dirbaio[m] has quit [Quit: Idle timeout reached: 172800s]
mrkajetanp has quit [Ping timeout: 255 seconds]
mrkajetanp has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 252 seconds]
mrkajetanp has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 246 seconds]
d3zd3z[m] has quit [Quit: Idle timeout reached: 172800s]
Gnome[m] has quit [Quit: Idle timeout reached: 172800s]
PeterKrull[m] has quit [Quit: Idle timeout reached: 172800s]
sugoi has joined #rust-embedded
mrkajetanp has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 260 seconds]
mrkajetanp has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 248 seconds]
sugoi has quit [Ping timeout: 246 seconds]
mrkajetanp has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 252 seconds]
mrkajetanp has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 246 seconds]
mrkajetanp has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 255 seconds]
mrkajetanp has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 246 seconds]
<danielb[m]>
<dav1d> "Seems like I have the same issue..." <- I'm not very familiar with RMT, are you using functionality that's not currently available by the esp-hal driver? The current idea is that you probably shouldn't manually set up pins, but instead configure a Flex and pass that to the peripheral, but I'm in the process of overhauling the GPIO drivers and I'm interested where we should be more flexible
mrkajetanp has joined #rust-embedded
roklobsta[m] has joined #rust-embedded
<roklobsta[m]>
Is using unwrap() in embedded code a bad idea?
<roklobsta[m]>
ie should really handle none and Err better than just ignoring?
<nandnor[m]>
unwrapping an error will panic
<GrantM11235[m]>
It depends, but it's not a bad idea in general
<roklobsta[m]>
Yeah I was coming around to the idea that maybe, just maybe, a panic might be bad....
mrkajetanp has quit [Ping timeout: 248 seconds]
<nandnor[m]>
It really depends though, obviously if its production code then its a no-no
<roklobsta[m]>
unwrap is just so convinient.
<roklobsta[m]>
ok time for a refactor ... hunt the unwraps.
<nandnor[m]>
if it dosnt actually matter to the rest of the program's logic you can do something like "unwrap_or_default()"
<dav1d>
danielb[m], yeah so from what it seems like we can get half of the necessary functionality from the Flex but we cannot setup the rmt in and output on the same pin, apparently there is an open discussion here https://github.com/esp-rs/esp-hal/issues/1662
<dav1d>
But I must admit that this is outside my comfort zone and my understanding of this is very minimal
<dav1d>
It seems like we'd need the InterconnectedPin sketched in the issue
mrkajetanp has joined #rust-embedded
<danielb[m]>
Dominic likes to overcomplicate (in terms of end user ergonomics) his solutions so maybe, maybe not. We'll think up something but in the very immediate future, the very least we can do is actually make it not impossible to conjure up a private::Internal.
<roklobsta[m]>
right, so for example say embassy's spawn() function might return a busy error in some situations but if a task is only ever spawned once this is unlikely/nevergoingtohappen so unwrap is safe to use.
mrkajetanp has quit [Ping timeout: 252 seconds]
<danielb[m]>
<roklobsta[m]> "right, so for example say..." <- can I tolerate random panics in my toy? sure! in my car's power steering? weeeeeell maybe not :D but even if you unwrap everywhere, you'll at least have a marker in your code where something may blow up. Not every possible panicing point will be marked, but you'll have a lot of help already. Safe to use depends on what the hardware does if the firmware suddenly loses control, though
<danielb[m]>
* suddenly loses/gives, * up control, though
<GrantM11235[m]>
If spawn fails, it's because there is a bug in your code that needs to be fixed, and panicking is the best way to tell you that. (it could also be due to an embassy bug or a hardware failure, but it's best not to think about things like that)
newam[m] has joined #rust-embedded
<newam[m]>
> can I tolerate random panics in my toy? sure! in my car's power steering? weeeeeell maybe not :D
<newam[m]>
Well, you wouldn't have a panic in power steering because rust is not MISRA certified for automotive use :P
<danielb[m]>
regardless, "is it safe to unwrap?" is quite nuanced in embedded I'm afraid
<roklobsta[m]>
i'd like to avoid all panics in my embedded app.
<danielb[m]>
if only panic_never was a viable idea for the real world 😅
mrkajetanp has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
<GrantM11235[m]>
There is a difference between eliminating panics that could reasonably occur at runtime, and eliminating all panics that exist in your binary. The former is viable, it's just called fixing bugs. The latter is infeasible and unnecessary in my opinion
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 245 seconds]
<roklobsta[m]>
right, i guess though it's a trap for the embedded newbie given so much of the teaching material and examples use unwrap a lot.
mrkajetanp has joined #rust-embedded
<nandnor[m]>
I think for newbies they just need to learn the basics and obviously panics/uwnrapping for embedded is as others have said fairly nuanced and a sort of advanced topic. My personal rule of thumb for personal/non-prod projects is, use unwrap if you are reasonably confident an error is unlikely, and for everything else, maybe use it to get a PoC up and running quickly and then after that point get rid of them when hardening your code.
<nandnor[m]>
Panics in general can be very useful for the debugging stage especially if you implement custom panic handlers to dump info right before halting (like with the esp-backtrace lib). It can help figure out where things went wrong for things that -have- to go right / that you cant otherwise recover from. And sometimes there is stuff you know can go wrong but you want to handle it gracefully so instead of panicking you can just set the
<nandnor[m]>
board to reset itself so it remains operational
<nandnor[m]>
Theres lots to consider. How is the project deployed (can you easily manually restart it if you need to / if theres a panic), does it have an OS where you can set up a watchdog to restart if theres a panic or not, etc
<nandnor[m]>
Not the best thing to burden newbies with that
<thejpster[m]1>
I mean, I know you were kidding. But it felt worth the explaination anyway.
<newam[m]>
Ah, did not know that
<roklobsta[m]>
Ando “Thor” Nando: right so unwraps are fine when you have probe-rs plugged in but really consideration should be given in advance to deal with them properly at some point.
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 260 seconds]
mrkajetanp has joined #rust-embedded
jonored has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 265 seconds]
<jonored>
Hello, hopped in here because dav1d is using an rmt crate I put together. Much of the fuss that we've got with rmt and onewire is that we want to connect _two_ peripherals (an input and an open-drain output) to the same pin and from what I recall need to configure it to invert as well. There's an open issue about that configuration but it hasn't been merged up yet, so there's some hackish bits ...
<jonored>
... involved in the meantime.
<jonored>
we basically just need InterconnectPin to get finished up and merged.
mrkajetanp has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 260 seconds]
<jonored>
I've been sorely tempted to hook up an RMT input to the same pin as an spi (routed via gpio matrix) port just for "internal logic analyzer"-ish debugging, as well.