troth has quit [Ping timeout: 264 seconds]
troth has joined #rust-embedded
<re_irc> <@firefrommoonlight:matrix.org> Let's say you want to store a short sound clip into a program. (Represented as an i32 array etc). How would you do it, short of a mass copy+paste?
<re_irc> <@firefrommoonlight:matrix.org> Perhaps onboard flash, perhaps offboard eg if it's too big
<re_irc> <@firefrommoonlight:matrix.org> Another question: When performing multiple successive transforms on data, do you save memory by modifying a `static mut` in place, vice accepting `&[i32]`, and outputting `[i32; SIZE]` ?
<re_irc> <@firefrommoonlight:matrix.org> I'd do the latter approach for code style in other settings and languages, but wondering if I'm "copying" etc data here unecessarily
<re_irc> <@firefrommoonlight:matrix.org> So far, they both seem to work
<re_irc> <@dirbaio:matrix.org> `include_bytes!()` is nice for including binary data
<re_irc> <@firefrommoonlight:matrix.org> seet
<re_irc> <@firefrommoonlight:matrix.org> appreciate it
<re_irc> <@firefrommoonlight:matrix.org> Looks perfect
fabic_ has joined #rust-embedded
fabic_ has quit [Ping timeout: 260 seconds]
PyroPeter has quit [Ping timeout: 258 seconds]
PyroPeter has joined #rust-embedded
fabic_ has joined #rust-embedded
tokomak has joined #rust-embedded
troth has quit [Ping timeout: 260 seconds]
troth has joined #rust-embedded
<re_irc> <@ryan-summers:matrix.org> Could you theoretically use `include_bytes!()` for creating a combined bootloader + app image?
<re_irc> <@ryan-summers:matrix.org> That's a fun idea. I bet you could
fabic_ has quit [Ping timeout: 265 seconds]
fabic_ has joined #rust-embedded
fabic_ has quit [Ping timeout: 260 seconds]
starblue has quit [*.net *.split]
starblue has joined #rust-embedded
<re_irc> <@jamesmunns:beeper.com> ryan-summers:matrix.org: I've absolutely done this :D
<re_irc> <@ryan-summers:matrix.org> If I had to write a bootloader, it's what I
<re_irc> <@ryan-summers:matrix.org> Better than writing some external combiner to add two ELFs/BINS/s28s
<re_irc> <@jamesmunns:beeper.com> That's the bootloader, including two initial images, because I'm using it to test the behavior
<re_irc> <@jamesmunns:beeper.com> Is there a way to specify a linker section for `include_bytes!`?
<re_irc> <@jamesmunns:beeper.com> like, I guess I can apply a linker section to the static? I think?
<re_irc> <@ryan-summers:matrix.org> Won't you just do a #[.section] above?
<re_irc> <@ryan-summers:matrix.org> You just specify the linker section for the variable
<re_irc> <@jamesmunns:beeper.com> Yeah, fair
<re_irc> <@jamesmunns:beeper.com> I'm trying to remember how I did that for sprocket-boot again, since I think I pulled the same trick...
<re_irc> <@jamesmunns:beeper.com> hmmm, maybe not.
<re_irc> <@9names:matrix.org> ryan-summers:matrix.org: We use this method for bundling the bootloader in RP2040.
inara` has joined #rust-embedded
inara has quit [*.net *.split]
fabic_ has joined #rust-embedded
<re_irc> <@9names:matrix.org> it does have to live in user code though - i tried using using the #[link_section] directive in the HAL and that just silently fails.
<re_irc> <@9names:matrix.org> it makes sense, but I still don't like it.
hifi has quit [Remote host closed the connection]
<re_irc> <@jamesmunns:beeper.com> Don't we use it directly in cortex-m-rt?
hifi has joined #rust-embedded
<re_irc> <@ryan-summers:matrix.org> https://github.com/rust-lang/rust/issues/67209 first rustc issue popped up
<re_irc> <@9names:matrix.org> uh... now it seems to be working. not sure if it's because i was holding it wrong before or if i'm holding it wrong now.
<re_irc> <@9names:matrix.org> looks like i have another thing to look into on the weekend.
<re_irc> <@firefrommoonlight:matrix.org> RTIC q: Does anyone know how to pass a resource to a function? Getting this error with the naive approach:
<re_irc> <@firefrommoonlight:matrix.org> hearing_test::run(&[], cx.shared.dfsdm, dma, cx.shared.sai);
<re_irc> <@firefrommoonlight:matrix.org> ```rust
<re_irc> <@firefrommoonlight:matrix.org> | ^^^^^^^^^^^^^^^ expected mutable reference, found struct `shared_resources::dfsdm`
<re_irc> <@dirbaio:matrix.org> `&mut *cx.shared.dfsdm` maybe?
<re_irc> <@firefrommoonlight:matrix.org> ```error[E0614]: type `shared_resources::dfsdm<'_>` cannot be dereferenced```
<re_irc> <@firefrommoonlight:matrix.org> I'm going through [the official examples](https://github.com/rtic-rs/rtic-examples)
<re_irc> <@firefrommoonlight:matrix.org> But they seem a bit sparse
<re_irc> <@henrik_alser:matrix.org> If it’s a shared resource it’s behind a mutex (unless you declared it as lock_free?)
<re_irc> <@firefrommoonlight:matrix.org> This case actually has both
<re_irc> <@firefrommoonlight:matrix.org> ```rust
<re_irc> <@firefrommoonlight:matrix.org> cx.shared.dma.lock(|dma| {
<re_irc> <@firefrommoonlight:matrix.org> hearing_test::run(&[], &mut cx.shared.dfsdm, &mut dma, &mut cx.shared.sai);
<re_irc> <@firefrommoonlight:matrix.org> Zoomed out a bit:
<re_irc> <@firefrommoonlight:matrix.org> });
<re_irc> <@firefrommoonlight:matrix.org> Note that RTIC has been working for me, but I just threw 2 curve balls at it, re the locked resource, and passing resources as fn params
<re_irc> <@firefrommoonlight:matrix.org> There teh other 2 are lock-free
<re_irc> <@ryan-summers:matrix.org> Would recommend asking in #rtic:matrix.org
<re_irc> <@firefrommoonlight:matrix.org> Haha thanks. I tried to find it but didn't come up on the search
<re_irc> <@ryan-summers:matrix.org> But you need to modify the type that your function is accepting. RTIC wraps shared resources in custom structs, so the type somewhat changes
<re_irc> <@ryan-summers:matrix.org> But what you're trying to do is definitely possible from what I remember
<re_irc> <@firefrommoonlight:matrix.org> TBH if that's the case I'd rather not use it
<re_irc> <@henrik_alser:matrix.org> The argument of your en would have the type `impl Mutex<T = u32>` or whatever
<re_irc> <@firefrommoonlight:matrix.org> I don't want to influence downstream code with resource logic
<re_irc> <@firefrommoonlight:matrix.org> Ie the function should just accept a mutable ref and not care how it's managed
<re_irc> <@firefrommoonlight:matrix.org> This is a dealbraeker
<re_irc> <@dirbaio:matrix.org> why can't you lock dfsdm like you lock dma?
<re_irc> <@firefrommoonlight:matrix.org> Don't need to. Locking `dma` since it's used by diff tasks at diff pris
<re_irc> <@henrik_alser:matrix.org> And when you call it you wrap it in `Exclusive` newtype
<re_irc> <@dirbaio:matrix.org> if dfsdm is just used in the current task then "locking" it is a noop I think (?)
<re_irc> <@firefrommoonlight:matrix.org> Could be
<re_irc> <@dirbaio:matrix.org> like you get the lock syntax but not the overhead (?)
<re_irc> <@firefrommoonlight:matrix.org> Well, the idea is to avoid the lock syntax unless you need it
<re_irc> <@firefrommoonlight:matrix.org> And when you need it is described in the RTIC docs as when multiple resources of diff pri use it. This makes sense, and is enforced by RTIC using the compiler
<re_irc> <@firefrommoonlight:matrix.org> It's pretty clever
<re_irc> <@henrik_alser:matrix.org> dirbaio:matrix.org: Then you should define it as a local
<re_irc> <@henrik_alser:matrix.org> But Yeah i think the lock is automatically removed by the compiler, at least it used to
<re_irc> <@henrik_alser:matrix.org> Also remember you can ”multi-lock” serveral resources as a tuple
<re_irc> <@henrik_alser:matrix.org> Inside the lock closure they’re just mutable references with the original type
<re_irc> <@henrik_alser:matrix.org> Maybe i don’t understand your unsage to see the problem :)
<re_irc> <@firefrommoonlight:matrix.org> Working on the RTIC channel now
<re_irc> <@firefrommoonlight:matrix.org> I'm just learning RTIC
<re_irc> <@henrik_alser:matrix.org> See you there :)
<re_irc> <@firefrommoonlight:matrix.org> Sorted out! Appreciate it
<re_irc> <@henrik_alser:matrix.org> But i can almost guarantee you there are no hidden ”dealbreakers”
<re_irc> <@firefrommoonlight:matrix.org> The root is, you need to lock resources that are passed as params
<re_irc> <@firefrommoonlight:matrix.org> Haha yea, this was a false alarm
<re_irc> <@ryan-summers:matrix.org> I'm a big fan of RTIC from an embedded development perspective. It's everything you want from defined timing + control with none of the software overhead of an RTOS
<re_irc> <@ryan-summers:matrix.org> Or at least very little overhead
<re_irc> <@firefrommoonlight:matrix.org> I like it too! My hesitation is that from a code layout and syntax perspective, it's not much diff from cortex-m mutexes
<re_irc> <@firefrommoonlight:matrix.org> Ie, It's effectively a syntax change from the perspective of my code bases
<re_irc> <@ryan-summers:matrix.org> init function + superloop is a super common design paradigm
<re_irc> <@firefrommoonlight:matrix.org> Granted, I use macros to wrap the ugly mutex creation and unwarpping
<re_irc> <@ryan-summers:matrix.org> Just take a look at arduino
<re_irc> <@firefrommoonlight:matrix.org> No thank you!
<re_irc> <@henrik_alser:matrix.org> It removes most of the boilerplate you need for any app bigger than a blinky in a very clever way i cant imagine reinventing myself every time and lets you focus on the business logic
<re_irc> <@henrik_alser:matrix.org> While still being low level to give you full control of the hardware
<re_irc> <@firefrommoonlight:matrix.org> Sure, but you can do the same with ISRs and mutexes
<re_irc> <@firefrommoonlight:matrix.org> It sounds like RTIC's locking is faster than mutexes
<re_irc> <@firefrommoonlight:matrix.org> and Mutex syntax is ugly unless you macro it
<re_irc> <@adamgreig:matrix.org> it's not "faster" (except in the situations where it's a no-op), but it has a lower system-level impact
<re_irc> <@henrik_alser:matrix.org> Sure I can but why bother? :)
<re_irc> <@firefrommoonlight:matrix.org> From my experimenting so far, it's a push
<re_irc> <@firefrommoonlight:matrix.org> I'm using RTIC in this project to learn, and get a better perspective
<re_irc> <@henrik_alser:matrix.org> 🙌 for me there was no going back :)
<re_irc> <@firefrommoonlight:matrix.org> Maybe that'll be me in a month
<re_irc> <@henrik_alser:matrix.org> Ymmv :) But we’re here for you if you get stuck!
<re_irc> <@firefrommoonlight:matrix.org> Demonstrated
<re_irc> <@henrik_alser:matrix.org> You’ll love the timer queue and capacity etc
<re_irc> <@henrik_alser:matrix.org> Those are probably the biggest selling points for me apart from resource handling
<re_irc> <@firefrommoonlight:matrix.org> Oh haven't messed with that yet!
<re_irc> <@firefrommoonlight:matrix.org> Using timers manually can be a bit clumsy for task scheduling. Looking fwd to trying
<re_irc> <@henrik_alser:matrix.org> Also to have ”software task” handled by the hardware with priority etc is wonderful
<re_irc> <@henrik_alser:matrix.org> `</fanboy>`
<re_irc> <@andresv:matrix.org> Let's say there are couple of examples under lib examples dir. Is it possible to mark that those would be built only if using `target.thumbv7em-none-eabihf`?
<re_irc> <@andresv:matrix.org> Essentially lib and tests can run on x86, but there are specific examples that only run on `thumbv7em-none-eabihf`.
<re_irc> <@andresv:matrix.org> `cargo test` tries to build aIso all examples which only build for `thumbv7em-none-eabihf` at the moment. I think it is impossible to put `#[cfg(target="thumbv7em-none-eabihf")]` or something in those example files to disable building them.
<re_irc> <@firefrommoonlight:matrix.org> I'll tag the Stm32-HAL timers with RTIC monotimic
fabic_ has quit [Ping timeout: 260 seconds]
tokomak has quit [Ping timeout: 264 seconds]
emerent_ has joined #rust-embedded
emerent is now known as Guest3115
emerent_ is now known as emerent
Guest3115 has quit [Ping timeout: 260 seconds]