sajattack[m]1 has quit [Quit: Idle timeout reached: 172800s]
StephenD[m] has joined #rust-embedded
<StephenD[m]>
How does the rp2040 compare to the stm32 in terms of maturity wrt hals and whatnot? I'm considering switching it up for my next project
<JamesMunns[m]>
haven't used the rp-hal, but embassy-rp works pretty well, used it for personal and client projects, haven't done anything crazy, but the basics like USB, SPI, I2C, timers, PWM, etc. all have worked super well.
<StephenD[m]>
So embassy I've heard of and it seems cool. The only thing I'm slightly worried about is it appears higher level than what I'm used to and I'm afraid it'll limit flexibility if I need, for example, to do something with strict timing requirements
<JamesMunns[m]>
I have no interest in convincing you otherwise, but I'd probably challenge you that it would limit you or preventing you doing whatever you want to do :)
<StephenD[m]>
Okay (: Good to know, ty
<StephenD[m]>
I definitely want to get into it. The rp2040 seems strictly superior to the stm32 in so many ways. Clock speed, core count, memory amount, price...
<JamesMunns[m]>
It has some quirks, like requiring external flash, and is a cortex-m0+ (no FPU, no atomics), but it IS really quick, and relatively featureful!
<adamgreig[m]>
you can definitely get lots of stm32s with faster clocks, 2 cores, way more memory (not hard when the rp2040 has no flash :p)
<adamgreig[m]>
but the price one is tough, the same price gets you a lot less stm32!
<JamesMunns[m]>
It's a fun and flexible little chip, and probably a reasonable middle of the road choice if you don't need some really specific peripheral or feature
<adamgreig[m]>
yea
<adamgreig[m]>
the pio is very cool to make up for any of the provided peripherals being a bit weird, too
<JamesMunns[m]>
you can overcome a lot of deficiencies with 2x 133MHz cores too :p
<StephenD[m]>
adamgreig[m]: True, sorry I meant in terms of price
<adamgreig[m]>
you can also use the embassy HAL without using embassy's async runtime if you want, I believe
<JamesMunns[m]>
the only things I'd say it's objectively Not Great at would be really heavy floating point number crunching, or very low power usage
<StephenD[m]>
That is good to know for FFT things
<adamgreig[m]>
for example, rtic provides tools to help with stricter timing/pre-emption requirements, and you could use embassy-rp with that
<adamgreig[m]>
whether it's "lower level" then embassy, though, depends how you measure it I guess :p
<adamgreig[m]>
probably looks about the same
<JamesMunns[m]>
adamgreig[m]: "lower level" is a misnomer/red herring/wrong question IMO :p
<JamesMunns[m]>
nobody gets extra points for "it put hair on your chest", the real question is "does it help me solve the kinds of problems I am trying to solve"
<JamesMunns[m]>
and I think embassy and rtic both (or neither!) can make that possible
<adamgreig[m]>
I think that's one important axis of consideration
<adamgreig[m]>
but sometimes I'm not trying to solve problems, I guess? and sometimes you just have a personal preference
<adamgreig[m]>
if you're a consultant working on a customer project, it's maybe the 100% most and only important thing
<JamesMunns[m]>
Yeah, that's fair, but "I like working with this and know how to use it" is an important facet of solving problems :p
<JamesMunns[m]>
maybe I'm being overly vague with "solving problems", mostly "can I make it do what I want it to do"
<adamgreig[m]>
anyway, definitely worth checking out embassy, and don't be put off by thinking it's high level
<JamesMunns[m]>
strong +1 to "try stuff out if you can instead of having pre-conceived notions about it" :)
<adamgreig[m]>
i've "solved problems" with embassy where the async was really convenient, and "solved problems" with rtic where i had sooo many interrupt priorities and its sharing-across-interrupts thing made everything really slick and made it possible to meet a bunch of annoying timing deadlines, both are really nice
<JamesMunns[m]>
Yeah, I've not actually come back around to use rtic2, but I've written a ton of rtic1 stuff
<JamesMunns[m]>
but I haven't had any horrifically timing critical projects since starting to use embassy more heavily, once I do it'd be a fun time to try out more embassy multiprio stuff and rtic2 honestly
mirko___ has quit [Quit: mirko___]
starblue has quit [Ping timeout: 264 seconds]
<JamesMunns[m]>
The fun part about using different tools is that for a while you figure out how to wrap your head around a new tool, then your brain starts seeing problems in the context of the new tool. RTIC and Embassy have both changed the way I see certain problems, and there are for sure stuff I can look at now and go "oh yeah that's exactly what I'd do".
starblue has joined #rust-embedded
<dirbaio[m]>
✨
IlPalazzo-ojiisa has quit [Quit: Leaving.]
starblue has quit [Ping timeout: 264 seconds]
starblue has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 268 seconds]
emerent_ has joined #rust-embedded
emerent has quit [Killed (erbium.libera.chat (Nickname regained by services))]
emerent_ is now known as emerent
<thejpster[m]>
Microsoft just gave ThreadX to the eclipse foundation.
<thejpster[m]>
I think there’s still room for the classic message passing RTOS in Rust, whether that’s wrapping FreeRTOS or ThreadX or doing it from scratch.
<thejpster[m]>
I guess there’s Hubris. I should try that.
Dr_Viper[m] has quit [Quit: Idle timeout reached: 172800s]
K900 has joined #rust-embedded
<K900>
So it's officially dead now?
<M9names[m]>
folks managed to reanimate the corpse of Virtuoso RTOS into Zephyr so i guess anything is possible, given sufficient money, marketing and motivation
jamwaffles[m] has quit [Quit: Idle timeout reached: 172800s]
starblue has quit [Ping timeout: 255 seconds]
starblue has joined #rust-embedded
rukai[m] has quit [Quit: Idle timeout reached: 172800s]
IlPalazzo-ojiisa has joined #rust-embedded
Guest7221 has left #rust-embedded [Error from remote client]
Guest7221 has joined #rust-embedded
cr1901_ is now known as cr1901
ducks2788[m] has quit [Quit: Idle timeout reached: 172800s]
<spinfast[m]>
<thejpster[m]> "I think there’s still room for..." <- Wrapping ThreadX might actually make the most sense, given its safety stamps
<spinfast[m]>
but the porting layer is kind of crazy, one directory per compiler+arch variant with a bunch of asm...
<spinfast[m]>
ugh
<spinfast[m]>
* of crazy/painful I imagine, one
<spinfast[m]>
really though I think rtic did so many things right... unless you actually need time slicing (I haven't...) it doesn't seem like the traditional multi-stack rtos brings much to the table
<JamesMunns[m]>
specifically for cortex-m or more no_std targets?
mirko___ has quit [Read error: Connection reset by peer]
<JamesMunns[m]>
Or is the answer still `Mutex<RefCell<T>>`? because whew
<JamesMunns[m]>
* still `cortex_m::Mutex<RefCell<T>>`? because
<adamgreig[m]>
It's critical_section::Mutex<RefCell<T>>, but it does at least implement a bunch of helper methods for that special case that let you directly call the RefCell methods
<PhilMarkgraf[m]>
I'm trying to build a object with several items on a shared bus, but am having problems getting the ownership right. I've tried several variations, but I always end up with some combination of "error[E0515]: cannot return value referencing local variable" or "error[E0505]: cannot move out of `i2c_ref_cell` because it is borrowed... (full message at
<JamesMunns[m]>
you can't move something that is borrowed
<JamesMunns[m]>
since a borrow/reference is just a pointer, when you return the refcell by ownership, its address moves
<JamesMunns[m]>
you'd instead want to make the refcell in the most-outer context, and pass that in to the things that need it. Phil Markgraf ^
<JamesMunns[m]>
The general name of this want/concept would be "self referential borrows", since a member of the struct "wants to" borrow something within the same struct. It's not generally possible today.
<JamesMunns[m]>
(there are a couple of crates that offer something like this, like ouroborus, but they are all generally unsound iirc)
<PhilMarkgraf[m]>
Thank you for the explanation James Munns . It seems like this _should_ be possible... maybe someday. The compiler certainly knows the lifetimes and should be able to figure out the order of initialization (if you, in an ideal world, could do the linkages in-place in the structure.)
<JamesMunns[m]>
yeah, it'd have to be a somewhat complicated transform, with the referenced structure "placed" NRVO-style, and references created from THAT.
<JamesMunns[m]>
I think it could be possible in sooooome cases, but then if you ever want to move the struct afterwards, it'll blow up again.
<JamesMunns[m]>
So, maybe someday, but that day is not today unfortunately :)
<JamesMunns[m]>
in `std` land you'd probably put the "borrowed thing" in an `Rc`/`Arc`, and hold on to that.
fu5ha[m] has joined #rust-embedded
<fu5ha[m]>
<JamesMunns[m]> "(there are a couple of crates..." <- Not true, there's a few that are all sound nowadays. I haven't used it myself but I've heard https://docs.rs/self_cell/latest/self_cell/ recommended
<JamesMunns[m]>
Ah! Good to know!
<JamesMunns[m]>
My knowledge is definitely out of date. There was a post 6-12 mo ago? that pointed out soundness issues in the 2-3 most popular, but maybe solutions have been found :)
<fu5ha[m]>
<PhilMarkgraf[m]> "Thank you for the explanation..." <- It's not about the resource not being initialized (though drop interactions and ordering would be one complication), but rather the fact that the owned value may be moved (it's memory gets copied to a new location) when the outer struct gets moved, and the outer struct has no way of being notified that it has been moved so therefore the references (which are just pointers) would
<fu5ha[m]>
still point to the old memory location and therefore dangle.
<fu5ha[m]>
JamesMunns[m]: I *believe* they have -- t-opsem/UCGWG has done some good work on this regard :))
<dirbaio[m]>
Phil Markgraf: don't bother with self-referential structs, even if there's cursed crates that can be made it to work, it's harder than needed
<dirbaio[m]>
it's much easier to make the refcell static
<fu5ha[m]>
dirbaio[m]: I do still agree with this take tho regardless haha
<JamesMunns[m]>
fu5ha[m]: I think he was suggesting the compiler could combine "order of initialization" + NRVO/placement new tricks to assemble them in a valid/reasonable order