IsaacClayton[m] has quit [Quit: Bridge terminating on SIGTERM]
XMPPwocky has quit [Quit: Bridge terminating on SIGTERM]
IsaacClayton[m] has joined #rust-embedded
XMPPwocky has joined #rust-embedded
fooker has joined #rust-embedded
<re_irc>
<monacoprinsen> James Munns: It's a full time position, good point!
<re_irc>
Sounds great, Thanks!
<re_irc>
Will put together something and add the tag.
Darius has quit [Quit: Bye]
Darius has joined #rust-embedded
starblue has quit [Ping timeout: 272 seconds]
starblue has joined #rust-embedded
<re_irc>
<Etienne> therealprof: thanks a lot for your reply. we will based on your recommendations start to contribute and be part of the community.
XMPPwocky has quit [Quit: User was banned]
IsaacClayton[m] has quit [Quit: User was banned]
<re_irc>
<timbod7> marmrt: I'm actually already using rtic, but it seems a bit heavyweight to have drivers become dependendent on rtic for very short timing delays.
<re_irc>
<dirbaio> timbod7: embassy has a Delay impl (blocking and async) that allows getting infinite instances out of a single hardware timer.
<re_irc>
<dirbaio> if you're writing a driver, the idiomatic way is to take a "T: Delay" and let the user choose which impl though
<re_irc>
<dirbaio> not depend on rtic/embassy
<re_irc>
<dirbaio> embassy has a Delay impl (blocking and async) that allows getting infinite instances out of a single hardware timer. And it's zero-sized too!
<re_irc>
<firefrommoonlight> That looks interesting. Seems to be the best developed rust RTOS, from the articles
<re_irc>
<firefrommoonlight> * furthest along
<re_irc>
<firefrommoonlight> I haven't been doing things complicated enough to warrant one, but keeping this in mind
<re_irc>
<firefrommoonlight> *You could argue the flight controller I'm working on could benefit from an RTOS or sophisticated scheduler, but so far things are in hand with RTIC ISRs
<re_irc>
<firefrommoonlight> Maybe the use case is more for if you have non-cooperative processes?
<re_irc>
<firefrommoonlight> (Like a smartphone or PC where users can install arbitrary software)
<re_irc>
<GrantM11235> The MPU stuff is an interesting alternative to peripheral singletons
<re_irc>
<dirbaio> yeah... the only reason you'd want to use memory protection is if you want to allow loading arbitrary apps and sandbox them... like in smartwatches
<re_irc>
<dirbaio> or to protect some components from exploits in other components, but that doesn't really apply to Rust 😎
<re_irc>
<dirbaio> otherwise it's quite a big overhead
<re_irc>
<firefrommoonlight> The overhead is why my mindset is default to no-OS
<re_irc>
<dirbaio> doing an IPC call for each SPI write... yikes :D
<re_irc>
<firefrommoonlight> I know a lot of embedded devs in C default to RTOS, even on simple projects
<re_irc>
<dirbaio> yeah, but not with memory protection
<re_irc>
<firefrommoonlight> I haven't even read those RM sections
<re_irc>
<firefrommoonlight> Although that might come in handy for dual-core MCUs too
<re_irc>
<dirbaio> C devs love RTOSs because it gives them tasks and mutexes and mailboxes and stuff
<re_irc>
<dirbaio> but in Rust you get that with async, no need for a fat RTOS :D
<re_irc>
<firefrommoonlight> I am trying to love Hyper
<re_irc>
<firefrommoonlight> The 'async fn' calls are diffusing throughout the codebase
<re_irc>
<firefrommoonlight> I have lost control
<re_irc>
<firefrommoonlight> I tried to make a recursive function once
<re_irc>
<firefrommoonlight> It didnt end well
<re_irc>
<dirbaio> embrace async
<re_irc>
<dirbaio> live async :D
<re_irc>
<firefrommoonlight> I learned about new and exciting varieties and combinations of smart pointers etc, then slowly backed away
<re_irc>
<dirbaio> yeah to make recursive fns you have to box the recursive future, otherwise you get infinite futures
<re_irc>
<dirbaio> * infinite-size
<re_irc>
<dirbaio> on the flip side this "future size is calculated at compile time" is exactly what makes Rust async possible in no-std, no-alloc
<re_irc>
<firefrommoonlight> It's interesting how Rust provides Async syntax, then lets you drop in am executor like Tokio or Embassy
<re_irc>
<firefrommoonlight> Makes sense from a flexibility perspective. And eg letting you do it no-std
<re_irc>
<dirbaio> I do think rust async for web/http stuff is not quite there yet
<re_irc>
<dirbaio> hyper is very low-level, most people go for a higher-level framework but I haven't found any that I like...
<re_irc>
<firefrommoonlight> Reqwest is fine if you're used to Python 's requests etc
<re_irc>
<firefrommoonlight> Easy api
<re_irc>
<GrantM11235> I've heard good things about axum
<re_irc>
<dirbaio> oh yeah I meant for writing servers
<re_irc>
<dirbaio> for clients it's OK-ish..(?)
<re_irc>
<dirbaio> it doesn't help either that tokio/hyper/etc insist on ALL futures to be Send because the executor is multithreaded
<re_irc>
<pwychowaniec> hmm, Tokio provides ".spawn_local()", no?
<re_irc>
<dirbaio> yeah, I always end up using the singlethreaded one with that 😂
<re_irc>
<dirbaio> but you have to jump through hoops to get hyper running with it, the default is always the multithreaded one...
<re_irc>
<firefrommoonlight> The Hyper docs describe it as low-level, and recommend using reqwest for simple requests etc, but I don't find the APIs much different
<re_irc>
<firefrommoonlight> Hyper doesn't do any hardware level stuff, and isn't too verbose
<re_irc>
<firefrommoonlight> I'm making a video game/browser/crawler/Gibson/Stephenson tribute/cybersecurity tool/hacking tool
<re_irc>
<firefrommoonlight> Hyper seems about right for that
<re_irc>
<firefrommoonlight> (servo is quite nice too)
explore has quit [Quit: Connection closed for inactivity]
<re_irc>
<Chris [pwnOrbitals]> Guys I have a question: as my target is quite memory-constrainted, anyone know if I can strip the debugging symbols (and compile with size-optimized+lto+panic=abort+etc.) and re-associate debugging symbols in the gdb session (going over openocd) ? I'm not really fluent in my architecture's assembly so it's kind of a pain to debug
<re_irc>
<Chris [pwnOrbitals]> +currently
<re_irc>
<dirbaio> debugging symbols don't get actually flashed, stripping them won't save space
<re_irc>
<Chris [pwnOrbitals]> hmmmmmmmmmmmmmmm I need to get a deeper understanding of how they work then, I'll look it up, thanks :p
<re_irc>
<dirbaio> ELF files have 'sections' with metadata whether they need to be flashed or not
<re_irc>
<dirbaio> LOAD entries in the program header
<re_irc>
<dirbaio> you can view it with "objdump -x"
<re_irc>
<dirbaio> you can also view the actual flash size of the ELF (only the flashed stuff) with "size"
<re_irc>
<Chris [pwnOrbitals]> alright, and each section goes to a different memory space as indicated in linker script and I imagine that must also be in the header ?
<re_irc>
<dirbaio> yeah
<re_irc>
<Chris [pwnOrbitals]> makes sense
<re_irc>
<dirbaio> if you want to diagnose bloated binaries, "cargo bloat" is great
explore has joined #rust-embedded
<re_irc>
<timbod7> firefrommoonlight: Sounds cool. I originally started out with the idea of building a simple rust flight controller, until I realised that I had too much to learn on embedded rust. Been working on simpler projects to get up to speed.
<re_irc>
<firefrommoonlight> The radio RX and sensor fusion needs a lot of work
<re_irc>
<firefrommoonlight> albeit could delay the sensor fusion, since all you _need_ is gyro rates
<re_irc>
<firefrommoonlight> (You obviously need an attitude platform and GPS etc for automated flight)
<re_irc>
<firefrommoonlight> I'm getting a FC board in about a week; hoping to get the IMU readings and DSHOT motor control tested and working shortly after
<re_irc>
<firefrommoonlight> Then gradually work through the Rx
<re_irc>
<firefrommoonlight> It uses ELRS, which is a very nice, open-source protocol, (Uses LoRa), but there's no official spec; just a rapidly-changing C codebase
<re_irc>
<firefrommoonlight> So I'm going with a straight-translation vice idiomatic Rust for that
<re_irc>
<dirbaio> rustcopter
<re_irc>
<dirbaio> quadruster
<re_irc>
<timbod7> firefrommoonlight: ELRS is awesome, but doesn't it communicate with the FC via the crossfire protocol, which is stable and well documented?
<re_irc>
<firefrommoonlight> That's one way to to it
<re_irc>
<firefrommoonlight> And is the most common in practice
<re_irc>
<firefrommoonlight> I'm interfacing the LoRa chip directly to the MCU via SPI
<re_irc>
<firefrommoonlight> And skipping the middleman MCU that is normally used to convert it to CRSF over UART
<re_irc>
<firefrommoonlight> Should be simpler, cheaper, and with lower latency
<re_irc>
<firefrommoonlight> Although uses FC MCU cycles
<re_irc>
<timbod7> OK - so the FC you have ordered has the LORA chip onboard.
<re_irc>
<firefrommoonlight> And requires the FC firmware to be kept up to date with the transmitters, which is a bigger ask than updating a standalone Rx
<re_irc>
<firefrommoonlight> Correct
<re_irc>
<firefrommoonlight> I think the big win for the user is one fewer PCB to attach, mount etc
<re_irc>
<firefrommoonlight> * connect and mount
explore has quit [Quit: Connection closed for inactivity]