<re_irc>
<@martb99:matrix.org> Hello guys, I am trying to set up embedded rust for VScode and I'm at the point where I can flash and debug the code. But sometimes after leaving debug mode I get this cargo error message
<re_irc>
<@martb99:matrix.org> It says that the OS system cant find the .cargo-lock file in debug. How can I fix this?
<re_irc>
<@9names:matrix.org> not running over a network share would probably help a lot here
<re_irc>
<@mathias_koch:matrix.org> I have the following snippet
<re_irc>
<@mathias_koch:matrix.org> Hi guys!
<re_irc>
<@mathias_koch:matrix.org> I could really use a guide in ASM :p
<re_irc>
<@mathias_koch:matrix.org> Seems to do the trick.. Now im just getting `relocation R_ARM_THM_JUMP11 out of range: 2457 is not in [-2048, 2047]; references RealBusFault`
<re_irc>
<@dirbaio:matrix.org> Uh no idea why it works with asm! Lolol
<re_irc>
<@dirbaio:matrix.org> try b.w instead of b ...?
<re_irc>
<@mathias_koch:matrix.org> `Error: bad instruction `b.w RealBusFault'`
<re_irc>
<@mathias_koch:matrix.org> still doesn't seem to work with a branch instruction
<re_irc>
<@mathias_koch:matrix.org> But it doesn't seem like the `BusFault` function is correctly called? Do i need to do something more than this? I think the default exception vector would pick it up from the naming of `BusFault`?
<re_irc>
<@mathias_koch:matrix.org> I already have `scb.enable(cortex_m::peripheral::scb::Exception::BusFault);`
<re_irc>
<@mathias_koch:matrix.org> And the rust nightly version worked great
<re_irc>
<@dirbaio:matrix.org> strange.. check the vectors to see if they have the right ptr..?
<re_irc>
<@mathias_koch:matrix.org> Any suggestions on what this means? `(.HardFault.user+0x4): has non-ABS relocation R_ARM_THM_JUMP24 against symbol 'RealBusFault'`
<re_irc>
<@mathias_koch:matrix.org> Huh, the fault debug is news to me
<re_irc>
<@mathias_koch:matrix.org> But what i had here worked great with nightly.. Just wanted to rid the asm macro feature, so i could compile with stable
<re_irc>
<@dirbaio:matrix.org> yea it's so weird..
<re_irc>
<@dirbaio:matrix.org> try to get the disassembled asm for both to match :S
<re_irc>
<@mathias_koch:matrix.org> Yeah, thats where im going now 👍️
<re_irc>
<@mathias_koch:matrix.org> I can't seem to make `.section .HardFault.user` work..
<re_irc>
<@mathias_koch:matrix.org> It compiles without it, but then `BusFault` is located miles away from `RealBusFault` and `HardFault`..
<re_irc>
<@mathias_koch:matrix.org> `(.HardFault.user+0x4): has non-ABS relocation R_ARM_THM_JUMP24 against symbol 'RealBusFault'`
<re_irc>
<@mathias_koch:matrix.org> `.section .HardFault.user, "ax"` did the trick
fabic has joined #rust-embedded
<re_irc>
<@mathias_koch:matrix.org> Now its Working! Woohoo
<re_irc>
<@dirbaio:matrix.org> looks ok to me too, dunno
<re_irc>
<@xiretza:xiretza.xyz> mathias_koch:matrix.org: just element doing element things, it's formatted correctly but without syntax highlighting here
<re_irc>
<@mathias_koch:matrix.org> fair enough ;) I'll accept it
<re_irc>
<@mathias_koch:matrix.org> Version : 1.7.34-1
karlp has joined #rust-embedded
<karlp>
just this one I guess, with single #?
<karlp>
I've got a question abotu intended end user consumption of the embedded-hal impls.
<karlp>
should my downstream "app" _only_ use the blah-device-hal as hal; and _not_ have any dependencies on embedded-hal itself? or am I meant to be depending on both?
Yruama has joined #rust-embedded
<karlp>
should the -hal layer be re-exporting all the types and traits or not?
<re_irc>
<@9names:matrix.org> which hal are you using? i think most of them will re-export embedded-hal
<karlp>
where it cals in that embeddedhal:digital:v2: manually,
<karlp>
that should have been accessible via the hal::hal then?
<re_irc>
<@dirbaio:matrix.org> `led.set_high();` uses that trait
<re_irc>
<@dirbaio:matrix.org> set_high is a trait method, for it to work you need the trait to be in scope
<re_irc>
<@dirbaio:matrix.org> and yes, `use embedded_hal::digital::v2::OutputPin;` and `use hal::hal::digital::v2::OutputPin;` do exactly the same in this case
<re_irc>
<@eldruin:matrix.org> Generally it is better to reexport the traits in the HAL impl and use that to avoid mismatches in the `embedded-hal` version used
<re_irc>
<@9names:matrix.org> speaking of such things: is there any guidance around whether such things should be in [device]-hal::prelude?
<re_irc>
<@eldruin:matrix.org> as a matter of fact, `OutputPin` is part of the `embedded-hal::prelude`
<re_irc>
<@dirbaio:matrix.org> but the prelude is going to be deleted in e-h 1.0 :D
<karlp>
yeah, that's exactly what I was at, only OutputPin is, not the rest of it, so i was curious what was meant to be going there.
<karlp>
I briefly tried to sue eh1.0, but I don't thnk I have enough rust experience to go there :)
<re_irc>
<@dirbaio:matrix.org> irc_libera_karlp:psion.agg.io: 1.0 is not out yet and (almost) no HAL implements it, so don't even bother :)
<re_irc>
<@9names:matrix.org> also, even if your hal does it makes it a pain to deal with the rest of the ecosystem since none of the drivers uses it
<karlp>
dirbaio: that's _exactly_ where I got to :)
<re_irc>
<@eldruin:matrix.org> ah karlp I think you have not enabled the "unproven" feature. Many traits are behind that feature in the 0.2.x versions
<re_irc>
<@eldruin:matrix.org> like `InputPin` and such
<re_irc>
<@dirbaio:matrix.org> InputPin is unproven? 🤣
<re_irc>
<@eldruin:matrix.org> on the 0.2 yes
gsalazar has joined #rust-embedded
<karlp>
meh, even trying to use cortex-m 0.7 is a wreck of busted dep trees
<re_irc>
<@jamesmunns:matrix.org> Sounds like a good job for a project group: Hunt and find old deps and PR updates to move the ecosystem on :D
<re_irc>
<@jamesmunns:matrix.org> Cargo reverse deps + the awesome rust embedded list should basically be the to-do list for 95% of the ecosystem
<re_irc>
<@adamgreig:matrix.org> hopefully cortex-m 0.7 is ok by now! cortex-m-rt 0.7 is still pretty new and needs PACs to update though
<re_irc>
<@dirbaio:matrix.org> automated PR bot
<karlp>
can you use cortex-m 0.7 with 0.6 rt?
<re_irc>
<@dirbaio:matrix.org> yes
<karlp>
this rust experiment has become a lot further downt he rabbit hole than I had originally hoped :|
<re_irc>
<@jamesmunns:matrix.org> One thing that I've gotten pretty comfortable with, but I see other folks struggling with: I'm never afraid to fork a project if it needs a couple touch-ups, like bumping versions
<re_irc>
<@dirbaio:matrix.org> I've been living inside the rabbit hole for 2y already :P
dcz has joined #rust-embedded
<re_irc>
<@jamesmunns:matrix.org> Like, usually the fixes are typically small, and I PR them back
<re_irc>
<@jamesmunns:matrix.org> But I find some people wait until it is released upstream, which causes delays.
<karlp>
I'm fine with that, it's having to be familiar enough with the ecosystem to know if these are bugs that can be fixed, or user error.
<re_irc>
<@jamesmunns:matrix.org> especially with little HAL extensions, or cortex-m/whatever updates
<karlp>
because there's been an awful lto of user wtf on my behalf the last week :)
<re_irc>
<@dirbaio:matrix.org> learning curve is steep
<karlp>
between the completely wild mismatch in styles between rtic and "normal" and the sometimes overlapping pac/hal/eh/device-name terms it's been a bit of a mess.
<re_irc>
<@dirbaio:matrix.org> but when you become familiar with stuff, it's sooooo much better than C :D
<re_irc>
<@jamesmunns:matrix.org> Also, an unrelated plug, I'm gunna stream a bit in a couple hours here: https://www.youtube.com/watch?v=DxPzRtsxrXc, talking about the HW/SW stuff I've been doing for Anachro
<re_irc>
<@jamesmunns:matrix.org> (it'll be recorded, but feel free to drop by and ask related/unrelated questions :D )
<karlp>
wrt to stm32 -hal in general, is there any rule on what the <PERIPH>.constrain() should return? RCC returns Rcc, IPCC (an stm32wb periph) returns Ipcc, but FLASH returns Parts?
<karlp>
(I'm not really even sure what .constrain() is really for tbh)
<re_irc>
<@jamesmunns:matrix.org> "constrain" is sort of the "old style" of exchanging a PAC structure for a HAL structure
<re_irc>
<@jamesmunns:matrix.org> e.g. you "take ownership" of the `pac::FLASH` struct, and get back a `hal::Flash`. The former deals with registers, and get back a "high level, safe abstraction"
<re_irc>
<@jamesmunns:matrix.org> In newer HALs, we've generally shifted to just having a `new()` method, e.g. `hal::Flash::new(pac::FLASH)`
<re_irc>
<@jamesmunns:matrix.org> The names don't matter as much, but you'll get a different "thing" back for each peripheral.
<karlp>
that fits my brain a little better.
<re_irc>
<@jamesmunns:matrix.org> the name `Parts` tends to be used for things that need to be "split apart again" to be useful, like GPIO ports (where you want to "peel off" each pin)
<re_irc>
<@jamesmunns:matrix.org> but, that's a rule of thumb, not strictly always true.
<re_irc>
<@jamesmunns:matrix.org> no idea about FLASH
<re_irc>
<@jamesmunns:matrix.org> btw, which stm32 are you working on?
<karlp>
I feel like I need to clone a few other "well regarded" stm32 hals locally for reference.
<karlp>
stm32wb
<re_irc>
<@jamesmunns:matrix.org> (I ask, because some ferrous folks are working on a flash driver for the stm32f3 at the moment)
<re_irc>
<@jamesmunns:matrix.org> ah, gotcha.
<re_irc>
<@jamesmunns:matrix.org> I'm biased, but I dig the style of the nrf-rs hals as well.
<karlp>
I have maintained a c library for years, was realllllly hoping to get to _stop_ doing that, but it already looks like I'm into "why is this impl inconsistent with that impl" :)
<re_irc>
<@dirbaio:matrix.org> stm32-rs hals have a bit of "legacy" like that
<re_irc>
<@dirbaio:matrix.org> I guess simply because they've been around for longer
<re_irc>
<@dirbaio:matrix.org> so "style" is mixed
<re_irc>
<@dirbaio:matrix.org> macro use vs Instance traits, constrain vs new..
<karlp>
stm32wb is basically an stm32l4 with a radio, so this sort of thing is really sharp and annoying to me: https://bin.jvnv.net/file/CvrX8.png
<re_irc>
<@dirbaio:matrix.org> the fact that there's one hal per stm32 family doesn't help either :D
<karlp>
yeah, but as somoene who's done a _lot_ of stm32 c librarys, I get how that happens...
<karlp>
you need to support the variants within the family too.
<re_irc>
<@dirbaio:matrix.org> embassy has one hal for all stm32's
<re_irc>
<@dirbaio:matrix.org> these inconsistencies is one of the things we're trying to address with that :)
<karlp>
I saw that come up, but it seemed like twisted in python, you have to sign up to the whole embassy ecossytem...
<re_irc>
<@dirbaio:matrix.org> but it's still quite WIP
<karlp>
yeah, I want less WIP, more "freedom to use rust instead of explosions of vendor C stacks"
<re_irc>
<@dirbaio:matrix.org> the HAL part supports both blocking and async, you can still use it without async
<re_irc>
<@dirbaio:matrix.org> (but async is super nice)
<karlp>
I have a hard enough time thinking in async in python on a desktop, but thats my weakness...
<re_irc>
<@dirbaio:matrix.org> instead of `PA4<Output<OpenDrain>>` you have `Output<PA4>`
<re_irc>
<@dirbaio:matrix.org> which simplifies stuff a lot
<re_irc>
<@dirbaio:matrix.org> but no other hal has adopted it
<re_irc>
<@dirbaio:matrix.org> removing typestates is controversial :D
<karlp>
yar, IN c/c++ land, you get _many_ different styles, each with their own pros and cons, rust seems a lot more "there's one way" and things like embassy sound like "outsiders" compared to "cortex-m" and "devicename-hal" which seem so formal and core, even if it's really just "we took that name first"
<re_irc>
<@dkhayes117:matrix.org> I think macros have their place, but I'm not a fan of them for hals. Too hard read imo.
<re_irc>
<@dirbaio:matrix.org> other projects like nrf-rs, stm32-rs are just that, opensource projects
<re_irc>
<@dirbaio:matrix.org> though by being the first then yeah they have the most momentum behind
<re_irc>
<@dirbaio:matrix.org> this is a bit of my Unpopular Opinion, but: since they're very stronlgy driven by consensus, they're stuck in "local maxima"
<re_irc>
<@dirbaio:matrix.org> for example "big" changes like merging all stm32-rs hals into one, or simplifying the GPIO api are super hard to get to happen
<karlp>
yeah, I know how that goes :)
<karlp>
teh gpio apis, things like "static BUTTON: Mutex<RefCell<Option<PC13<Input<PullUp>>>>> = Mutex::new(RefCell::new(None));" are not giving me big warm smiles, ti just sounds like c++ all over again
<re_irc>
<@firefrommoonlight:matrix.org> Although it has 0 radio support, which may be a dealbreaker for WB
<re_irc>
<@dirbaio:matrix.org> no manually messing with interrupts and mutexes, but it still uses interrupts internally and still puts the core to sleep while waiting for the button press
<re_irc>
<@firefrommoonlight:matrix.org> The reason I mention it is I've made some very different design decisions re things like you bring up
<re_irc>
<@dirbaio:matrix.org> and e-h will hopefully soon have async versions of the traits, the plan is to switch to those when it's out, and drop embassy-traits
<karlp>
firefrommoonlight yours doesn't look substantially different? You've still got this style of using cortex::free(||) inside irq handlers, which I didn't understand in the "classic" hal examples either.
<karlp>
you're in the handler, who's going to interrupt you?
<re_irc>
<@dirbaio:matrix.org> another even-higher-priority handler could
<re_irc>
<@dirbaio:matrix.org> you as a programmer know you don't have such handler
<re_irc>
<@dirbaio:matrix.org> but the compiler can't know
<re_irc>
<@adamgreig:matrix.org> the compiler also doesn't know that the main thread can't interrupt the handler
<re_irc>
<@dirbaio:matrix.org> so `Mutex` requires interrupts to be disabled to access the internals
<re_irc>
<@dirbaio:matrix.org> so it's sound no matter how/where you use it
<re_irc>
<@adamgreig:matrix.org> so yea, as far as the compiler is concerned all "different" contexts need synchronising
<karlp>
so we're turning off irqs inside irq handlers instead? that doesn't really seem like, "if you aren't using it, you don't pay for it"
<re_irc>
<@adamgreig:matrix.org> I was wondering the other day if a chapter in the embedded book would be a good place to try and summarise this dirbaio ? though maybe we also want to write up other sort of "platform" stuff we assume around abis and how to "own" an interrupt and single-vs-multi core assumptions, maybe symbols exported by rt crates too, that sort of thing
<karlp>
I mean, sure sure, it's not a huge thing.
<re_irc>
<@adamgreig:matrix.org> it's a thing and definitely is being paid for as a runtime cost
<re_irc>
<@adamgreig:matrix.org> for some people it's definitely too expensive, too
<re_irc>
<@adamgreig:matrix.org> like, disabling higher prio interrupts increases the jitter and worst-case response time for those interrupts
<karlp>
and what's the option? throw unsafe{} all over the place?
<re_irc>
<@adamgreig:matrix.org> sure, that's always an option, and is what happens under the hood in Mutex too
<re_irc>
<@dirbaio:matrix.org> you can use `static mut` instead of `static Mutex<...>` (yes, unsafe)
<re_irc>
<@adamgreig:matrix.org> basically the compiler says "`unsafe` must be used for different contexts to access a shared resource"
<re_irc>
<@dirbaio:matrix.org> or you can "steal" the pin in interrupt context, so you don't need a static at all (also unasfe)
<re_irc>
<@adamgreig:matrix.org> the Mutex in cortex-m says "well, if I disable all interrupts, nothing can pre-empt this code, so it's sound to access this shared resource; therefore my callers don't need to write `unsafe` themselves"
<re_irc>
<@adamgreig:matrix.org> but that has to be a very coarse approach because it doesn't know anything about other interrupts
<karlp>
(fwiw, as a newcomer, I found that free() naming to be wildly unclear :)
<re_irc>
<@adamgreig:matrix.org> in comparison RTIC knows "well, no interrupt with a higher priority can ever try to access this resource, so it's fine to access it without locking"
<re_irc>
<@adamgreig:matrix.org> and there are other techniques too
<re_irc>
<@adamgreig:matrix.org> all of them provide some "safe" abstraction over something that's `unsafe` under-the-hood, combined with a guarantee that it's sound (e.g. because interrupts are disabled)
<re_irc>
<@dirbaio:matrix.org> I agree the "free" naming is "too creative"!! :)
<re_irc>
<@dirbaio:matrix.org> it sounds too much like C's free
<re_irc>
<@adamgreig:matrix.org> at least it's almost always used as `interrupt::free()` instead of just `free()`, heh
<re_irc>
<@dirbaio:matrix.org> it really means "run this code in an interrupt-free context", but it's very non-obvious
<re_irc>
<@adamgreig:matrix.org> unfortunately I guess C doesn't ever have an equivalent method, you just do your own "lock" and "unlock" or "disable" and "enable" etc
<re_irc>
<@adamgreig:matrix.org> calling it "critical_section" is both quite longwinded and not strictly accurate (it is _a_ critical section but not all critical sections would need to disable all interrupts, though we've had that debate before too lol)
<re_irc>
<@newam:matrix.org> adamgreig: I think it is possible do scope hacks similar to `g_autofree uint8_t* foo = g_malloc(1024);`, but only with gcc.
<re_irc>
<@adamgreig:matrix.org> does that have a commonly used name for "interrupts disabled in this section" though?
<re_irc>
<@adamgreig:matrix.org> I just meant it's unfortunate because it means there's no shared name for it
<re_irc>
<@newam:matrix.org> Ah, yeah, not having a proper name is unfortunate.
<re_irc>
<@dirbaio:matrix.org> it usually methods like begin_critical_section / end_critical_section
<re_irc>
<@dirbaio:matrix.org> or even worse, macros
<re_irc>
<@adamgreig:matrix.org> dirbaio:matrix.org: yea.. what could we rename `free` to?
<re_irc>
<@jamesmunns:matrix.org> `release`
<re_irc>
<@adamgreig:matrix.org> yikes, lol
<re_irc>
<@jamesmunns:matrix.org> :D
<re_irc>
<@adamgreig:matrix.org> confusion++
<re_irc>
<@dirbaio:matrix.org> jamesmunns:matrix.org: can't tell if joking 🤔
<re_irc>
<@jamesmunns:matrix.org> I mean... I didn't mean it as a joke
<re_irc>
<@jamesmunns:matrix.org> but maybe don't give naming rights of anything to me
<re_irc>
<@firefrommoonlight:matrix.org> karlp: I'm open to suggestions on better ways to stop race conditions in ISR. As adamgrieg mentioned, RTIC is a framework that can do it in a more clever way. RTIC code is similar in structure to the examples you were looking at, although with different syntax.
GenTooMan has quit [Ping timeout: 245 seconds]
<re_irc>
<@firefrommoonlight:matrix.org> I'm open to ideas/suggestions etc; I think we're in a bit of "open-question" territory
<re_irc>
<@dirbaio:matrix.org> we were talking about interrupt::free
<re_irc>
<@adamgreig:matrix.org> jamesmunns: `release` for the `interrupt::free()` method that executes a closure in a critical section?
<re_irc>
<@jamesmunns:matrix.org> ohhhhh
<re_irc>
<@jamesmunns:matrix.org> oops
<karlp>
I mean, as long as it's literally doing disable interrupts, perhaps disable_interruptsinstead of free :)
<re_irc>
<@jamesmunns:matrix.org> I was thinking "destruct a hal type"
<re_irc>
<@newam:matrix.org> I would keep it terse personally.
<re_irc>
<@firefrommoonlight:matrix.org> I tried to smooth over the syntax by using macros, without bringing in a framework, but there's lots of room for improvement
<re_irc>
<@dirbaio:matrix.org> exactly criticizing that it looks too much like "uart::free" or "free" as in malloc
<re_irc>
<@dirbaio:matrix.org> which is exactly what confused you :D :D
<re_irc>
<@adamgreig:matrix.org> irc_libera_karlp:psion.agg.io: it's a bit more complicated; we already have `disable()` to disable interrupts, but this takes a closure and runs it without interrupts
<re_irc>
<@jamesmunns:matrix.org> :D
<re_irc>
<@jamesmunns:matrix.org> (thanks!)
<re_irc>
<@adamgreig:matrix.org> so it ensures interrupts are disabled initially, then runs your code, then conditionally re-enables interrupts if they weren't already disabled
<re_irc>
<@dirbaio:matrix.org> in the `critical_section` crate I have `critical_section::with`
<re_irc>
<@mvirkkunen:matrix.org> Hmm, wonder what would be a cheap way to have like 2 or 4 USB devices in one device
<re_irc>
<@firefrommoonlight:matrix.org> So... You could use `static mut` and just manipulate things as you wish, but this is asking for race conditions unless you're careful, IMO. Thoughts?
<re_irc>
<@mvirkkunen:matrix.org> Thinking of a keyboard/mouse switcher that's instant insteas of unplugging/replugging devices
<re_irc>
<@jamesmunns:matrix.org> mvirkkunen:matrix.org: cheap 2-4 port hub IC?
<re_irc>
<@jamesmunns:matrix.org> oh, more like a KVM?
<re_irc>
<@mvirkkunen:matrix.org> jamesmunns I mean 4 device side ports, not host side, so the other way round
<re_irc>
<@mvirkkunen:matrix.org> yes
<re_irc>
<@jamesmunns:matrix.org> gotcha
<re_irc>
<@jamesmunns:matrix.org> a usb hub ic... backwards?
<re_irc>
<@jamesmunns:matrix.org> im not good at suggestions today
<re_irc>
<@jamesmunns:matrix.org> its friday
GenTooMan has joined #rust-embedded
<karlp>
firefrommoonlight: I've tried rtic a bit, as the initial stm32wb bluetooth examples I found were rtic based, but that led me into other wierd issues that I'm too novice to work through, which is that all the resources have different types, so I got super confused trying to follow any example code. and then intellij does _not_ handle the APP() structure well through the annotations.
<re_irc>
<@newam:matrix.org> I like `with_`, using it to denote a context manager is growing idiom in rust; and it is part of the language in python.
<re_irc>
<@adamgreig:matrix.org> `critical_section::with()` is OK, but `interrupt::with()` kinda gives the wrong impression :P
<re_irc>
<@newam:matrix.org> dirbaio:matrix.org: Honestly it is very few characters for for clear it is.
<re_irc>
<@newam:matrix.org> That aint bad.
<re_irc>
<@thalesfragoso:matrix.org> irc_libera_karlp:psion.agg.io: Use RTIC, seriously, you don't need to lock resources that aren't used by higher priority IRQs, and locks are done with primask instead of disabling all interrupts (unless you're in M0 land)
<re_irc>
<@adamgreig:matrix.org> rtic is a really elegant way of sharing resources between contexts
<re_irc>
<@firefrommoonlight:matrix.org> Btw, I'm using the IntelliJ Rust plugin too
<karlp>
thalesfragoso: I intend to go back to rtic again, but I have to get more of the basic things working first, and I was butting my head against rtic too much earlier this week.
<re_irc>
<@thalesfragoso:matrix.org> And everything checked at compile time, and without paying for the Option<RefCell> dance
<re_irc>
<@newam:matrix.org> irc_libera_karlp:psion.agg.io: You RTOS, regardless of what you choose, should be what provides you with a way to safely access resources between context.
<re_irc>
<@newam:matrix.org> If you want to explore others I maintain a list here: https://arewertosyet.com/
<karlp>
I'm putting aside the bluetooth latyer for a bit, as that's quite complex so I can just ge tthe rest of the basic rust stuff working
<re_irc>
<@dirbaio:matrix.org> IMO RTIC is still too lowlevel
<re_irc>
<@firefrommoonlight:matrix.org> thalesfragoso: You're really making me want to use RTIC for the next project. I've been using Mutex for all mutable variables used by ISRs
<re_irc>
<@thalesfragoso:matrix.org> irc_libera_karlp:psion.agg.io: Try the basics without interrupts, once you get the feel for it you can go almost right away to RTIC
<re_irc>
<@dirbaio:matrix.org> and with async you don't really need a full-blown RTOS
<re_irc>
<@thalesfragoso:matrix.org> I always use RTIC or embassy
<re_irc>
<@newam:matrix.org> RTIC is very good, but yes, also low-level.
<re_irc>
<@newam:matrix.org> If you're not opposed to the idea of nightly rust I would recommend embassy, it handles nested yielding very well (which RTIC doesn't do well at all).
<re_irc>
<@thalesfragoso:matrix.org> I don't use RTIC with embassy, because embassy usually takes care of the interrupts for me
<re_irc>
<@thalesfragoso:matrix.org> But if you have some feature that isn't in embassy yet you can use embassy with RTIC without problems
<re_irc>
<@thalesfragoso:matrix.org> If you don't want to pay for disabling all interrupts for all "mutexes" then or you will use a lot of carefully checked unsafes or end up rewriting RTIC...
<karlp>
thalesfragoso: this "try the basics" approach hass't been working very well forme. All the basics are a single main() method examples, with led blinking. I want a radio and some serial protocol handling and some ADC w/DMA getting processed and handed off, and there's not many examples of anything _solid_ to look at that I've eben finding
<karlp>
but hey like I said, I plan on goign back to rtic when I have a few basic things a bit more under control
<re_irc>
<@thalesfragoso:matrix.org> irc_libera_karlp:psion.agg.io: Hah, I guess we have some different understanding of what the "basics" are
<re_irc>
<@firefrommoonlight:matrix.org> perhaps the `basics` really is using `static mut` globals
<re_irc>
<@adamgreig:matrix.org> if you were writing this in C, would you basically give yourself a bunch of global buffers that are accessed by both main and interrupts, and just be careful to not race?
<re_irc>
<@firefrommoonlight:matrix.org> And manipulating them as you wish
<re_irc>
<@thalesfragoso:matrix.org> For that you definitely want RTIC
<re_irc>
<@adamgreig:matrix.org> the rust equivalent to that is using `unsafe` and `static mut`
<re_irc>
<@firefrommoonlight:matrix.org> Then seeing where it gets you into trouble
<re_irc>
<@firefrommoonlight:matrix.org> thalesfragoso: I agree, but it might be a good place to start for karlp
<re_irc>
<@thalesfragoso:matrix.org> Just reading a static mut in a loop in a function will already give you bad results
gsalazar_ has joined #rust-embedded
gsalazar has quit [Read error: Connection reset by peer]
<re_irc>
<@thalesfragoso:matrix.org> The compiler can assume no races happen, which means that we will assume that the static mut doesn't change if the function itself doesn't change it
<re_irc>
<@thalesfragoso:matrix.org> So it will read it only once
<re_irc>
<@dkhayes117:matrix.org> Would that `GhostCell<>` technique help with ISRs?
<re_irc>
<@firefrommoonlight:matrix.org> Yikes. TBH I haven't used them, but thought it might be conceptually simpler for the things he's having a hard time with
<re_irc>
<@thalesfragoso:matrix.org> If you gonna play with static muts be sure to bring your compile fences, even if your code doesn't race in practice
<re_irc>
<@thalesfragoso:matrix.org> Safe resource management is hard in any language, the difference is that in bare metal C people don't seem to usually do it...
<re_irc>
<@dirbaio:matrix.org> they do it just fine
<re_irc>
<@dirbaio:matrix.org> just not safely 👻
<re_irc>
<@thalesfragoso:matrix.org> Yeah, I mentioned safe in specific
<re_irc>
<@thalesfragoso:matrix.org> It's hard to see someone using a critical section or similar to do like a RMW in an interrupt
<re_irc>
<@thalesfragoso:matrix.org> But tbh I don't have much exposure to professional bare metal C, maybe they do...
<re_irc>
<@thalesfragoso:matrix.org> And to be clear, I'm not bashing C, like I said, it's hard even in rust
<re_irc>
<@thalesfragoso:matrix.org> That's why we have projects like RTIC
fabic has quit [Ping timeout: 252 seconds]
<re_irc>
<@newam:matrix.org> is there a way to get `defmt` to print hex values on assertions?
<re_irc>
<@dirbaio:matrix.org> with assert_eq!? no..
<re_irc>
<@dirbaio:matrix.org> or maybe yes, you can make a newtype and manually impl defmt::Format for it to get it to print in hex... probably not fun
<re_irc>
<@newam:matrix.org> Yeah the `assert_eq`/`assert_ne` would be very handy to have in hex for debug
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 256 seconds]
gsalazar_ has quit [Ping timeout: 240 seconds]
crabbedhaloablut has quit [Ping timeout: 276 seconds]
crabbedhaloablut has joined #rust-embedded
dcz has quit [Ping timeout: 244 seconds]
Amanieu has quit [Ping timeout: 272 seconds]
<re_irc>
<@disasm-ewg:matrix.org> mvirkkunen:matrix.org: Slide switches? Relays? USB switch IC?
<re_irc>
<@mvirkkunen:matrix.org> I wanted them all to be connected at the same time, although I think a USB switch from Amazon might work ok enough
<re_irc>
<@disasm-ewg:matrix.org> Then FE1.1S maybe?
<karlp>
that's a normal hub...
<re_irc>
<@disasm-ewg:matrix.org> Ah, ok
<re_irc>
<@disasm-ewg:matrix.org> The solution is going to be complicated in multiple ways