<re_irc>
<@alex:matrix.sempto.net> I'm trying to write Rust on AVR bare metal without RTIC and I'm a bit stumped with regards to sharing peripherals between interrupts.
<re_irc>
<@alex:matrix.sempto.net> How do I get references to peripheral registers to the interrupt handlers? I have read about singletons: https://docs.rust-embedded.org/book/peripherals/singletons.html but it is probably not the right approach since the peripheral will get dropped after the interrupt finishes.
<re_irc>
<@adamgreig:matrix.org> you can put the peripheral back into the singleton at the end of the interrupt, or only borrow it from the singleton without taking itout
<re_irc>
<@alex:matrix.sempto.net> makes sense. Basically I make some kind of "take" and "give back" functions for the singleton, right?
<re_irc>
<@adamgreig:matrix.org> or you may be able to just use it in-place if you don't need to own the peripheral object and can get away with an &mut reference
<re_irc>
<@fragadaleta:matrix.org> ahah no it's not a garage door
<re_irc>
<@fragadaleta:matrix.org> ahah
<re_irc>
<@k900:0upti.me> Because believe me, getting hit by a garage door is not an enjoyable experience
<re_irc>
<@fragadaleta:matrix.org> ahahah
<re_irc>
<@fragadaleta:matrix.org> real time is definitely needed there
<re_irc>
<@k900:0upti.me> And it's definitely going to happen when you're attempting a project that complex as your first big embedded thingn
<re_irc>
<@fragadaleta:matrix.org> got it 😀
<re_irc>
<@k900:0upti.me> So I guess what I'm really asking is "what is the worst thing that can happen when your thing breaks"
<re_irc>
<@k900:0upti.me> And I want to make sure it's something like "your cat doesn't get fed for a few hours" and not "someone gets a garage door to the face"
<re_irc>
<@fragadaleta:matrix.org> if you are too late actuating, it might break if there are particular weather conditions
<re_irc>
<@fragadaleta:matrix.org> probably in less than a second
<re_irc>
<@k900:0upti.me> Is it a drone
<re_irc>
<@fragadaleta:matrix.org> but definitely more than tens of millisecs
<re_irc>
<@k900:0upti.me> Please tell me it's not a drone
<re_irc>
<@fragadaleta:matrix.org> it's not
<re_irc>
<@k900:0upti.me> The thing with drones is, most people think that the worst case scenario is the drone crashes, when in reality the worst case scenario is the drone crashes _into your face_
<re_irc>
<@fragadaleta:matrix.org> 😀
<re_irc>
<@9names:matrix.org> tbh if i was picking a platform for machine vision stuff I'd be using a jetson nano over a raspberry pi
<re_irc>
<@k900:0upti.me> I mean if you can afford one
<re_irc>
<@fragadaleta:matrix.org> yeah i heard of the combo rpi + jetson and was attracted too
<re_irc>
<@k900:0upti.me> You don't need a combo for that thing
<re_irc>
<@9names:matrix.org> but also, since building physical stuff + camera + lenses is expensive I'd also probably not even stop there and just throw an intel + gpu at it
<re_irc>
<@k900:0upti.me> It's got its own CPU
<re_irc>
<@k900:0upti.me> That should be around Pi4 levels of performance already
<re_irc>
<@fragadaleta:matrix.org> and rockpro64?
<re_irc>
<@k900:0upti.me> Actually probably somewhere between Pi3 and Pi4
<re_irc>
<@fragadaleta:matrix.org> ah forgot to mention, all has to be Rust based
<re_irc>
<@fragadaleta:matrix.org> 😕
<re_irc>
<@k900:0upti.me> But still more than good enough since the inference will run on the GPU
<re_irc>
<@k900:0upti.me> fragadaleta:matrix.org: Basically same thing as the Pi
<re_irc>
<@k900:0upti.me> Most of those small Linux boards are basically in the same class
<re_irc>
<@k900:0upti.me> The Jetson stands out because it has a big GPU with good vendor support
<re_irc>
<@fragadaleta:matrix.org> how do they communicate?
<re_irc>
<@k900:0upti.me> Who's they?
<re_irc>
<@fragadaleta:matrix.org> rpi + jetson
<re_irc>
<@k900:0upti.me> However you want
<re_irc>
<@k900:0upti.me> Probably I2C or something
<re_irc>
<@k900:0upti.me> But again, you should be fine just using the Jetson, if you're getting one anyway
<re_irc>
<@k900:0upti.me> It's also just a Linux system and it also has a bunch of I/O
<re_irc>
<@fragadaleta:matrix.org> ah ok so you would do all in the jetson indeed
<re_irc>
<@fragadaleta:matrix.org> and even actuate directly from there
<re_irc>
<@fragadaleta:matrix.org> (i guess)
<re_irc>
<@k900:0upti.me> If you need something faster than that, you'll just have to stick an STM32 on there
<re_irc>
<@k900:0upti.me> And have the big board feed it inputs over I2C or serial or whatever
<re_irc>
<@k900:0upti.me> You won't see a real difference in response times between the Pi and the Jetson, so I don't see a reason to have both, unless you really need lots of extra IO
<re_irc>
<@fragadaleta:matrix.org> yeah i don't think i need that
<re_irc>
<@k900:0upti.me> I'm not sure how that fits into what you're describing
<re_irc>
<@k900:0upti.me> If the goal is literally to make everything Rust code and nothing else, then the Jetson is definitely out
<re_irc>
<@fragadaleta:matrix.org> it doesn't. It's just to get familiar with the rpi
<re_irc>
<@k900:0upti.me> Because 1) Linux and 2) CUDA
<re_irc>
<@9names:matrix.org> if you've already got the hardware you might as well just try?
<re_irc>
<@9names:matrix.org> at least you'll find out the limits of the hardware, and maybe for your case it's perfectly fine
<re_irc>
<@k900:0upti.me> I mean, it's a cool learning project, but it's not really going to have much of anything in common with how you'll want to run this in production
<re_irc>
<@fragadaleta:matrix.org> if i have sensor data processed by e.g. nrf52xxx board (and Rust code), I am thinking how would i bring it in the mix with an Rpi...
<re_irc>
<@k900:0upti.me> I2C probably
<re_irc>
<@k900:0upti.me> If you don't need a lot of it
<re_irc>
<@k900:0upti.me> Or serial, if you do
<re_irc>
<@fragadaleta:matrix.org> right. So i would simply have another Rust program reading/writing to I2C from the rpi?
<re_irc>
<@k900:0upti.me> Yes
<re_irc>
<@fragadaleta:matrix.org> like a linux daemon thing?
<re_irc>
<@k900:0upti.me> Basically
<re_irc>
<@fragadaleta:matrix.org> gotcha
<re_irc>
<@fragadaleta:matrix.org> yeah i guess that would speed up my dev effort and test things out
<re_irc>
<@fragadaleta:matrix.org> then if i need more dedicated things i might consider them driven by benchmarks
<re_irc>
<@k900:0upti.me> You can just keep shoving data from the Pi into the I2C link
<re_irc>
<@k900:0upti.me> And you'll get interrupts on your MCU when new data comes in
<re_irc>
<@k900:0upti.me> So you can do whatever it is you need
<re_irc>
<@k900:0upti.me> And the Pi can just go as fast as it can without caring about synchronization
<re_irc>
<@fragadaleta:matrix.org> right. Pi will read from I2C only when new data is available? Like in a pub/sub channel?
<re_irc>
<@k900:0upti.me> It depends
<re_irc>
<@k900:0upti.me> You can set it up however you want really
<re_irc>
<@k900:0upti.me> Both sides can be async if you need them to
<re_irc>
<@k900:0upti.me> But if the Pi is just looking at a camera and providing inputs, you shouldn't need to read anything from the MCU at all?
<re_irc>
<@fragadaleta:matrix.org> no MCU has highest priority. So i should be reading that all the time.
<re_irc>
<@fragadaleta:matrix.org> If camera is not available, that's "fine"
<re_irc>
<@9names:matrix.org> i would not use i2c for this. set up some simple data encoding over uart, and push timestamped data to your MCU board
<re_irc>
<@k900:0upti.me> The MCU should be the thing controlling your outputs in this setup
<re_irc>
<@9names:matrix.org> if the data is too old by the time it gets to the MCU, you just ignore it. if the linux app stops sending data, who cares.
<re_irc>
<@k900:0upti.me> Ideally if you're OK with the camera falling off, you should be able to just turn it off entirelyn
<re_irc>
<@k900:0upti.me> Cut the power, throw it out the window, the MCU still works
<re_irc>
<@fragadaleta:matrix.org> 9names: it's the MCU that sends data to the Pi
<re_irc>
<@fragadaleta:matrix.org> and it does so as soon as fresh data is available
<re_irc>
<@k900:0upti.me> Yeah we're saying you should do the opposite of that
<re_irc>
<@sepotvin:matrix.org> I'm trying to build a rust PAC from an svd file for a riscv cpu with svd2rust. Anybody knows why svd2rust always generate cortex_m references in the generated output? I've specified that the target is riscv on the command line: "svd2rust --target=riscv -i vexriscv.svd"
<re_irc>
<@nihal.pasham:matrix.org> Hey, I'm working on a driver port for raspberry-pi 4 and I happen to run into this. So, am hoping someone here might have more insight into rpi's and their inner workings; if yes, would appreciate it if you could provide some pointers on what I might be missing here.
<re_irc>
<@burrbull:matrix.org> sepotvin:matrix.org: possibly regression. Could you create issue and check different versions?
<re_irc>
<@sepotvin:matrix.org> Thanks, just wanted to double check I hadn't done anything stupid. I will try other versions and bisect when it started.
<re_irc>
<@korken89:matrix.org> Does anyone know in `linker-plugin-lto` feature in `cortex-m` has stopped working? I'm now getting asm methods in my binaries when using RTIC and they are not inlineing anymore. Example from `cargo bloat`:
<re_irc>
<@sepotvin:matrix.org> sepotvin:matrix.org: It seems fixed in the master branch of rust2svd. Thanks for your help
<re_irc>
<@jordens:matrix.org> korken89: is that nightly?
<re_irc>
<@korken89:matrix.org> No, on stable
<re_irc>
<@jamesmunns:beeper.com> If anyone here is a serde wizard, and has ideas on how I can achieve this, I am all ears! I want to enable some (much more usable, but still silly zero copy) use cases for postcard + byte-slab: https://gist.github.com/jamesmunns/408b2cd532fa8f1b26784e3cc2b5cb56
<re_irc>
<@adamgreig:matrix.org> korken89: hmm, I feel like I heard another report of that problem last week
<re_irc>
<@adamgreig:matrix.org> no idea on what would cause it though, we haven't changed anything in c-m afaik
<re_irc>
<@adamgreig:matrix.org> asm macro hits stable rust so soon, ugh
<re_irc>
<@thejpster:matrix.org> adamgreig: do I need to open a PR for This Year in Embedded Rust, or will *hand waving* things happen
<re_irc>
<@adamgreig:matrix.org> let's chat about the hackmd in the meeting and get some updates to it from more people, and then open a PR to the blog afterwards with the contents?
<re_irc>
<@thejpster:matrix.org> Sounds good to me.
rardiol has joined #rust-embedded
<re_irc>
<@diondokter:matrix.org> Quick question, what would be the best way to detect a cortex-m fpu at runtime or compile time? It's important for something, and I want to avoid that the users have to select it themselves
<re_irc>
<@diondokter:matrix.org> Hmmm, not as great as I'd have liked, but doable
<re_irc>
<@diondokter:matrix.org> Thanks!
<re_irc>
<@dirbaio:matrix.org> at runtime you can check cpuid maybe?
<re_irc>
<@firefrommoonlight:matrix.org> As I think dirbaio pointed out a while back to me, you can disable the FPU by setting a non-FPU target to save a bit of power, if you don't plan to use floats
<re_irc>
<@diondokter:matrix.org> Yeah, so I'm emitting some fpu instructions using the asm! macro, so I need to be able to selectively turn that off. It's working now :)
<re_irc>
<@dirbaio:matrix.org> :D
<re_irc>
<@tholmie:matrix.org> Lol I didn’t scroll far enough back. Sorry for redundant info 😛
smach has joined #rust-embedded
Foxyloxy has joined #rust-embedded
smach has quit [Remote host closed the connection]
chrisb has joined #rust-embedded
<re_irc>
<@dngrs:matrix.org> wasn't there some strange distinction between `hf` and actual float support, like... `eabihf` just specifies to use registers for floats? Maybe not super relevant in practice but I found it interesting
<re_irc>
<@9names:matrix.org> yeah, you can just pass floats via int registers or on the stack - saves a few cycles during context switches so you have lower latency
<re_irc>
<@9names:matrix.org> another strategy is enable eabihf, but only ever do floating point math in a single context so even though you don't save/load the float registers on context switch they never get clobbered.
<re_irc>
<@9names:matrix.org> this is definitely a niche embedded thing, good to know if you need it, but most folks just turn off floats in these circumstances.
<re_irc>
<@9names:matrix.org> hmm, maybe I am wrong about the first part, it's been so long since I touched cortex-m ASM and I never did any FP in it :(
<re_irc>
<@dirbaio:matrix.org> is there any way to get `ptr, len` from `*const [u8]` in stable?
<re_irc>
<@dirbaio:matrix.org> (*not* casting to `&[u8]` because it'd violate aliasing)
<re_irc>
<@dirbaio:matrix.org> transmute to (usize, usize), but that feels dangerous
<re_irc>
<@alex:matrix.sempto.net> I'm trying to save an Iterator state in the interrupt vector. The interrupt looks like this:
<re_irc>
<@9names:matrix.org> we're talking about a thing that is only ever invoked from an interrupt, and is initialised before interrupts are enabled - do we really need to recommend a Mutex here?
<re_irc>
<@dirbaio:matrix.org> you can't initialize the iterator in const
<re_irc>
<@dirbaio:matrix.org> if you're *very very* careful then you can use `static mut sine_iter: MaybeUninit<..>` correctly without mutexes yaeh
<re_irc>
<@dirbaio:matrix.org> like: init it, enable irq, then use *only* from IRQ
<re_irc>
<@dirbaio:matrix.org> but it's quite dangerous
<re_irc>
<@dirbaio:matrix.org> it's nice to prefer safe code
<re_irc>
<@dirbaio:matrix.org> and also maybe you need a compiler_fence
<re_irc>
<@dirbaio:matrix.org> init it, compiler fence, enable irq, then use only from IRQ