rardiol has quit [Ping timeout: 260 seconds]
<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> <@jacobrosenthal:matrix.org> alex:matrix.sempto.net: Have you seen https://docs.rust-embedded.org/book/concurrency/#sharing-peripherals
<re_irc> <@alex:matrix.sempto.net> jacobrosenthal:matrix.org: I somehow missed that chapter. Thanks!
PyroPeter has quit [Ping timeout: 252 seconds]
PyroPeter has joined #rust-embedded
<re_irc> <@fragadaleta:matrix.org> what's the most straight forward to go bare metal between beagleboard and raspberry-pi?
<re_irc> <@k900:0upti.me> Sell both on eBay and buy an STM32
<re_irc> <@k900:0upti.me> Like, almost 100% serious
<re_irc> <@k900:0upti.me> Bare metal on SoCs that large is never fun
<re_irc> <@fragadaleta:matrix.org> k900:0upti.me: lol i have an F3
<re_irc> <@k900:0upti.me> Then why not just use that?
<re_irc> <@fragadaleta:matrix.org> i do. thing is that i need more power
<re_irc> <@fragadaleta:matrix.org> and run more complex computations
<re_irc> <@k900:0upti.me> Then you probably want to get a bigger board, run Linux on it, and connect it to a small MCU for real time stuff
<re_irc> <@fragadaleta:matrix.org> in which case i guess an rpi4 would do the trick then
<re_irc> <@k900:0upti.me> If you even need hard real time guarantees
<re_irc> <@k900:0upti.me> If you don't, you can do the whole thing on the Pi
<re_irc> <@k900:0upti.me> It has lots of IO
<re_irc> <@fragadaleta:matrix.org> and what MCU would i connect (and how would i connect first) for audio/video?
<re_irc> <@fragadaleta:matrix.org> a jetson?
<re_irc> <@k900:0upti.me> Audio/video what exactly?
<re_irc> <@fragadaleta:matrix.org> segmentation mainly
<re_irc> <@k900:0upti.me> Then probably just a USB camera
<re_irc> <@fragadaleta:matrix.org> audio is quite a lot of FFT
<re_irc> <@k900:0upti.me> And a USB sound card
<re_irc> <@k900:0upti.me> If you're doing that sort of thing, you really want to be as far away from "bare metal" as possible
<re_irc> <@k900:0upti.me> There's a reason the drivers for that stuff in the kernel are thousands of lines of code
<re_irc> <@fragadaleta:matrix.org> thing is that the audio/video must stay in sync with sensor data for which i might need hard real time
<re_irc> <@fragadaleta:matrix.org> (for the sensors i mean)
<re_irc> <@k900:0upti.me> You don't
<re_irc> <@k900:0upti.me> Hard real time means milliseconds
<re_irc> <@k900:0upti.me> If not microseconds
<re_irc> <@9names:matrix.org> wat
<re_irc> <@k900:0upti.me> You'll never get it to sync up that precisely anyway
<re_irc> <@k900:0upti.me> 9names: I know it's not _really_ what that means
<re_irc> <@fragadaleta:matrix.org> decisions are taken at the millisec level. So i don't really understand what you mean
<re_irc> <@k900:0upti.me> There's absolutely no way for your video pipeline to give you, like, less than 10-20ms of delay
<re_irc> <@k900:0upti.me> Just for getting the video from the camera to the devicen
<re_irc> <@k900:0upti.me> Never mind processing
<re_irc> <@k900:0upti.me> That's going to be way slower than any sort of timing issues you'll have from the Pi not being hard RT
<re_irc> <@9names:matrix.org> what exactly are you doing, anyway?
<re_irc> <@fragadaleta:matrix.org> Ok i haven't explained the requirements.
<re_irc> <@fragadaleta:matrix.org> sure.
<re_irc> <@fragadaleta:matrix.org> video/audio footage is part of the input when available (and in sync with sensor data).
<re_irc> <@fragadaleta:matrix.org> Sensor data are first-class citizen and must be always available at the millisec level
<re_irc> <@9names:matrix.org> what sort of sensors? what is the output?
<re_irc> <@fragadaleta:matrix.org> output is messages over xbee mesh and actuators
<re_irc> <@fragadaleta:matrix.org> if i go rpi what OS should i be looking at?
<re_irc> <@k900:0upti.me> Linux
<re_irc> <@k900:0upti.me> Any Linux really
<re_irc> <@k900:0upti.me> Raspbian is probably the easiest
<re_irc> <@k900:0upti.me> Since that's what they officially support
<re_irc> <@fragadaleta:matrix.org> ok
<re_irc> <@k900:0upti.me> Also, the actuators part scares me here
<re_irc> <@k900:0upti.me> What exactly are you actuating?
<re_irc> <@fragadaleta:matrix.org> servos and dc motors
<re_irc> <@fragadaleta:matrix.org> i dont have specs yet
<re_irc> <@k900:0upti.me> To do what?
<re_irc> <@k900:0upti.me> Mostly I'm just trying to make sure you're not running that on like a garage door
<re_irc> <@fragadaleta:matrix.org> turning stuff lol
<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> <@fragadaleta:matrix.org> alright... maybe i should be starting playing with this https://github.com/rust-embedded/rust-raspberrypi-OS-tutorials
<re_irc> <@fragadaleta:matrix.org> 😛
<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> <@fragadaleta:matrix.org> right
<re_irc> <@fragadaleta:matrix.org> LOL look what i found https://words.thiago.me/raspberry-pi-bare-metal-programming-with-rust/
<re_irc> <@fragadaleta:matrix.org> (a.k.a. how to shoot myself in the...feet)
<re_irc> <@k900:0upti.me> Note that that's for the original Pi
<re_irc> <@k900:0upti.me> Something like a Pi4 will have a much more finicky boot process
<re_irc> <@fragadaleta:matrix.org> yeah noted
<re_irc> <@fragadaleta:matrix.org> does anybody know the difference between nRF52840-MDK and nRF52840-DK ?
<re_irc> <@fragadaleta:matrix.org> ok stupid question...
rardiol has joined #rust-embedded
<re_irc> <@k900:0upti.me> Probably
<re_irc> <@k900:0upti.me> But you're going to need to power them somehow
<re_irc> <@fragadaleta:matrix.org> of course
<re_irc> <@fragadaleta:matrix.org> K900: how can i power this one if i don't have usb?
<re_irc> <@k900:0upti.me> There's a power connector
<re_irc> <@fragadaleta:matrix.org> so just a 3.7v battery? what connector do i need?
<re_irc> <@k900:0upti.me> Check the datasheet
<re_irc> <@luojia65:matrix.org> New LLVM target is in progress. Seems like we'd have another family of Rust targets to be supported :)
rardiol has quit [Ping timeout: 240 seconds]
<re_irc> <@dngrs:matrix.org> this thing clearly needs to be a Rust target https://www.youtube.com/watch?v=FDiapbD0Xfg
<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> <@korken89:matrix.org> ```console
<re_irc> <@korken89:matrix.org> 0.0% 0.3% 6B cortex_m __basepri_w
<re_irc> <@korken89:matrix.org> 0.0% 0.3% 6B cortex_m __primask_r
<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
Foxyloxy has quit [Quit: Textual IRC Client: www.textualapp.com]
<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> <@dirbaio:matrix.org> at compile time you can check $TARGET in build.rs https://github.com/rust-embedded/cortex-m/blob/master/build.rs#L47
<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> <@dirbaio:matrix.org> or try to enable it in CPACR and read back CPACR to check if it's actually enabled, if it's not present it seems you'll read back 0? https://stackoverflow.com/questions/57929824/how-to-detect-fpu-in-cortex-m
<re_irc> <@dirbaio:matrix.org> seems very cursed though
<re_irc> <@dirbaio:matrix.org> and not sure what you'd do with it, you'd need to compile your code for both fpu and no-fpu and pick at runtime
<re_irc> <@dirbaio:matrix.org> so you need to know at compiletime
<re_irc> <@dirbaio:matrix.org> maybe you can check at runtime and warn/fail if the user got the compiletime setting wrong
<re_irc> <@dirbaio:matrix.org> but yeah running non-fpu code in an fpu mcu is totally fine, you'd be sabotaging that (the reverse isn't)
<re_irc> <@tholmie:matrix.org> ```rust
<re_irc> <@tholmie:matrix.org> `cortex-m` does the following in `build.rs`:
<re_irc> <@tholmie:matrix.org> let target = env::var("TARGET").unwrap();
<re_irc> <@tholmie:matrix.org> // (...)
<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> <@alex:matrix.sempto.net> #[avr_device::interrupt(atmega328p)]
<re_irc> <@alex:matrix.sempto.net> fn TIMER0_OVF() {
<re_irc> <@alex:matrix.sempto.net> static mut sine_iter : Cycle<Iter<u8>>= SINE.iter().cycle();
<re_irc> <@dirbaio:matrix.org> `static mut sine_iter: MaybeUninit<Cycle<Iter<u8>>> = MaybeUninit::uninit()`
<re_irc> <@dirbaio:matrix.org> then init it in main
<re_irc> <@dirbaio:matrix.org> then `sine_iter.assume_init_ref()` afterwards
<re_irc> <@dirbaio:matrix.org> or if you want to make it safer: `static mut sine_iter: Option<Cycle<Iter<u8>>>`
<re_irc> <@dirbaio:matrix.org> or fully safe: `static sine_iter: Mutex<RefCell<Option<Cycle<Iter<u8>>>>>`
<re_irc> <@alex:matrix.sempto.net> Thank you!
<re_irc> <@dirbaio:matrix.org> though using an index is probably much easier...static sine_i
<re_irc> <@dirbaio:matrix.org> `static sine_index: AtomicUsize = AtomicUsize::new(0);`
<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
<re_irc> <@dirbaio:matrix.org> not sure though
<re_irc> <@9names:matrix.org> yeah, probably