<re_irc>
<kelleyk> Hello everyone! I'm curious if anyone has pointers to any open-source embedded Rust applications. I'm mostly interested in the crate selection; I'm new to the embedded Rust world and so I don't have an off-the-shelf way to do normal things.
<re_irc>
<kelleyk> For example, I've gotten the latest versions of Rust/RTIC/smoltcp working together on my dev board of choice (with an outline based on knurling-rs/app-template, so: defmt, probe-run, flip-link, etc.)
<re_irc>
<kelleyk> But now I'm shopping around for a way to serve simple RPCs over the network connection, and trying to cobble together a no_std-friendly bunch of libraries. Figured it might be quicker to ask ;)
<re_irc>
<kelleyk> I suppose that my question is more about the network side of things; I haven't worked on an embedded project with a TCP stack before. If this were a non-embedded project, I'd probably go grab a simple HTTP sever or gRPC or something of that nature, but those don't seem like they're necessarily good fits for this side of things.
<re_irc>
<newam> Drouge IoT has some fun things along those lines: https://www.drogue.io/
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
Amadiro_ has joined #rust-embedded
Amadiro has quit [Ping timeout: 272 seconds]
<Lumpio->
Man having to spell all your enormously long types out when you migrate from "just everything in main()" to RTIC or a "struct App" or whatever is such a drag
<re_irc>
<Mehmet Ali> Hi all!
<re_irc>
<Mehmet Ali> My Cargo fails to find my main.rs
<re_irc>
<Mehmet Ali> cargo run --profile release
<re_irc>
error: `cargo run` could not determine which binary to run. Use the `--bin` option to specify a binary, or the `default-run` manifest key.
<re_irc>
available binaries: bart-nrf-devenv, bitfield, format, hello, levels, overflow, panic
<re_irc>
<caspinol> so perhaps you need ro run as rtthe cargo suggest
<re_irc>
<caspinol> cargo run --bin <yourbinary>
<re_irc>
<Mehmet Ali> actually they are remnants of knurling template
<re_irc>
<Mehmet Ali> I could actually remove the bin dir
<re_irc>
<Mehmet Ali> wonder what will it say then?
<re_irc>
<Mehmet Ali> Oh!
<re_irc>
<Mehmet Ali> nice, progress.
<re_irc>
<Mehmet Ali> Different errors mean I am off the hook for now.
<re_irc>
<Mehmet Ali> This folder structure was what it was for a while now.
<re_irc>
<Mehmet Ali> I think somehow a cargo update changed how it is interpreted.
<re_irc>
<Mehmet Ali> Thanks, caspinol
<re_irc>
<Mehmet Ali> You have made my cogs run
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
<re_irc>
<MathiasKoch> What is the idiomatic way to remove large string messages from "assert!" ending up in rodata? In this case it is a bootloader, where i will probably never be able to see the message anyways. The asserts are from 3rd party crates like HAL's
<re_irc>
<dirbaio> use defmt::assert! if you're using defmt
<re_irc>
<MathiasKoch> Yeah, i do that in my crates, but i can't really control all crates :p
<re_irc>
<dirbaio> otherwise, get rid of panic messages
<re_irc>
<dirbaio> make sure your panic handler crate isn't printing them (for example disbale feature "print-defmt" in "panic-probe")
<re_irc>
<dirbaio> that removes most but not all bloat
<re_irc>
<dirbaio> to fully get rid of it build with "-Zbuild-std=core -Zbuild-std-features=panic_immediate_abort"
<re_irc>
<MathiasKoch> 👍️
<re_irc>
<dirbaio> the downside is now panics compile to a single "udf" instruction, all you get is a PC value and have to manually check where it comes from
<re_irc>
<dirbaio> this makes panics compile to a single "udf" instruction, zero bloat!
<re_irc>
the downside is now all you get is a PC value and have to manually check where it comes from
<re_irc>
<MathiasKoch> Alright. No such thing as a free lunch ;)
<re_irc>
<dirbaio> (only for non-defmt panics, you still get defmt panic messages)
<re_irc>
<9names (@9names:matrix.org)> i wish we could use that on stable, it's so good
<re_irc>
<dirbaio> yeah :'(
<re_irc>
<dirbaio> in theory having your panic handler be "asm!("udf")" would be enough
<re_irc>
<dirbaio> but last I checked the compiler wasn't inlining it, which prevented it from removing strings etc
<re_irc>
<dirbaio> I think "panic_immediate_abort" is kinda a workaround for that, that's probably why it isn't stable
<re_irc>
<andodeki> hello guys
<re_irc>
I need a tracking device for motorcycle and which implement geofencing and limits the speed and also can shut down the engineif the device is tampered with. which device can work like this on the market if not can it be implemented in a space of 1 week??
<re_irc>
we have a project initiated by the a government that needs this solution for approximately 2m device to monitor and control motocycles
<re_irc>
<Noah> ?
<re_irc>
<James Munns> That's like, a lot of work for a week.
<re_irc>
<James Munns> You might be able to make a prototype that fast, but not anything production
<re_irc>
<James Munns> And also: for the government?
<re_irc>
<James Munns> Otherwise I'm sure there are LoJack style immobilizers on the market already?
<re_irc>
<Noah> I doubt a prototype is doable in a week. You'd need quite some custom stuff for all of this I think. Also not sure but how good is stuff like LoRa etc supported yet?
<re_irc>
<dirbaio> seems like it's more for one of these pay-per-minute motosharing apps
<re_irc>
<Noah> maybe LTE-M with the nrf91
<re_irc>
<James Munns> It'll take a week for the hardware to arrive :p
<re_irc>
<K900> At that scale, it'll probably take a week for your order to be cleared
<re_irc>
<adamgreig> so long as the motorcyles don't have the speed limits installed yet, I bet you could deliver in faster than a week :P
<re_irc>
<barafael> Strictly speaking, no LoRa or cellular network was requested. So only sensor would be GPS. And some connection to the engine, CAN maybe?
<re_irc>
For the government, oh well...
<re_irc>
<dirbaio> yeah these are usually GNSS+cellular
<re_irc>
<Noah> barafael: that's true. only reverseengineering the engine controls will take >week
<re_irc>
<Noah> government surely can spend more than a week lol
<re_irc>
<dirbaio> I've seen them using simcoms and ubloxs, but nrf91 could work as well if you hace CAT-M/NB-IoT coverage
<re_irc>
<dirbaio> if you're buying 2M motorcycles you can probably get the manufacturer to give you any docs you want
<re_irc>
<dirbaio> probably not in a week tho 😂
<re_irc>
<barafael> Maybe with a servo that clenches the fuel line and starves the engine? Hey, simple is good right
<re_irc>
<kelleyk> newam: Thanks for the link, I'll check that out!
<re_irc>
<dngrs (spookyvision@github)> is there already a crate for decoding ADC'd light pulses as data?
<re_irc>
<adamgreig> hi room, it's meeting time again! agenda is https://hackmd.io/wCo4VOogSNqIkbhwTbLbHA, please add anything you'd like to announce or discuss and we'll start in 5 min :)
<re_irc>
<adamgreig> ok, let's start! one quick announcement, svd2rust 0.22 is now out (both 0.22.0 and 0.22.1 😅) including new array access for register and cluster arrays
<re_irc>
<adamgreig> anyone have anything else to mention?
<re_irc>
<thejpster> Did the Espressif training come up yet? I haven’t been paying attention here
<re_irc>
<adamgreig> please feel free to re-mention it, I don't think so though!
<re_irc>
<thejpster> Uh, Espressif asked Ferrous to write “Intro to Rust on the ESP32-C3”. It covers their libstd port mainly but also low level I2C type fun.
<re_irc>
<adamgreig> e-h been a bit quiet recently, I think there's "move i2c to the same concept as the new spi" and a couple of smaller things left?
<re_irc>
<mabez> thejpster: Just to piggy back this, the post mentions a the custom esp board for the training, but we're also working with https://wokwi.com/ to run the training on a simulated esp32 in the browser, no hardware required! Hopefully I'll have more to share about this in the next meeting :)
<re_irc>
<adamgreig> ooh, cool!
<re_irc>
<thejpster> And to be clear the ESP32-C3 is the RISC-V core. You still need nightly to compile libstd but at least it’s upstream nightly, unlike the Xtensa based parts. But it’s good to see more non Arm things!
<re_irc>
<adamgreig> on the embedded-hal point, dirbaio did you have any plans for new i2c in the style of new spi?
<re_irc>
<adamgreig> the list of blockers left on the e-h 1.0 issue is getting pretty small, heh
<re_irc>
<dirbaio> yup, haven't found time
<re_irc>
<dirbaio> but still want to
<re_irc>
<adamgreig> that about sums up the things i was working on, heh
<re_irc>
<dirbaio> :)
<re_irc>
<dirbaio> what about embedded-hal-async? it'd be cool to get some -alpha out
<re_irc>
<dirbaio> so users don't have to use git deps
<re_irc>
<adamgreig> oh, yea, is it about ready for such a thing? wonder what major/minor version to use, heh
<re_irc>
<adamgreig> first release 1.0.0-alpha.0, very brave
<re_irc>
<dirbaio> 0.1.0 probably
<re_irc>
<dirbaio> then 0.2, 0.3... then merge into EH1.0 when "done" instead of doing 1.0
<re_irc>
<adamgreig> makes sense
<re_irc>
<therealprof> SGTM
<re_irc>
<dirbaio> only missing thing from me is async Serial
<re_irc>
<dirbaio> but I'll write my thoughts on the PR, since it's a bit .. complex :S
<cr1901>
I actually didn't know about embedded-hal-async. I just thought it was "impl traits in a crate under Embassy and call it a day"
<re_irc>
<dirbaio> the tracking issue (https://github.com/rust-embedded/embedded-hal/issues/356) also lists ADC and CAN. I have no interest in CAN personally, and IMO ADC doesn't really need async, because taking a single sample is usually fast enough
<re_irc>
<dirbaio> maybe if you're using an spi/i2c ADC
<re_irc>
<dirbaio> but I wouldn't block 0.1.0-alpha.0 on that maybe?
<re_irc>
<adamgreig> sure seems like it could come later, yea
<re_irc>
<adamgreig> async CAN probably does make sense eventually but it can always be added later, same as blocking CAN
<re_irc>
<adamgreig> cr1901, a bunch of embassy's async traits basically moved to embedded-hal-async, with the goal being to merge them into embedded-hal itself when they can work on stable
<re_irc>
<dirbaio> yeah, embassy-traits is gone now :D
<cr1901>
ahhhh
* cr1901
nods/is up to date now :)
<re_irc>
<GrantM11235> Speaking of ADC, does anyone actually use the adc traits? I'm not even sure how you would use them in a generic way
<re_irc>
<dirbaio> GrantM11235: uh and it's "nb"-only
<re_irc>
<adamgreig> should it... 🚮 before 1.0?
<re_irc>
<dirbaio> and I've always found it quite complicated, with the "ADC", "Channel" and "Pin" stuff
<re_irc>
<dirbaio> i've never used it
<re_irc>
<dirbaio> embassy doesn't impl it and nobody has asked for it
<re_irc>
<adamgreig> a few stm32 hals do impl it, I don't know how widely used it is by drivers
<re_irc>
<GrantM11235> I think the PWM traits used that channel and pin stuff too, but those are also 🚮 now
<re_irc>
<dirbaio> and most (all?) HALs impl it blocking even though it uses "nb"
<re_irc>
<therealprof> I'd say it is somewhat widely used, especially from people coming from Arduino.
<re_irc>
<therealprof> * by
<re_irc>
<dirbaio> that's by end users isn't it? so it'd be equally (or more?) usable if the HALs had inherent methods for everything
<re_irc>
<therealprof> Yes, I don't think I've seen any drivers using the traits.
<re_irc>
<newam> The ADC traits are kind of in a weird spot where they're not as easy to use as Arduino, yet the complexity doesn't lend itself to being useful for DSP applications.
<re_irc>
<adamgreig> I could imagine some applications that want to be generic across a multi-channel ADC and using it
<re_irc>
<adamgreig> but I don't know if any exist
<re_irc>
<adamgreig> and second maybe cast an eye at https://github.com/rust-embedded/cortex-m/issues/265 which is a pretty longstanding request to somehow permit assembling constant argument forms of swi/svc, I think we need const_asm to land in stable for that though so it's probably a little way away
<re_irc>
<adamgreig> finally I'm still interested in a c-m-rt or c-m (alpha?) release soon, but haven't had time to put anything together still, if anyone wants to have a go feel free, otherwise I will hopefully get to it eventually
<re_irc>
<adamgreig> hmm, that's all I had, anyone want to discuss anything else?
<re_irc>
<Clark Kozak> Today this beginner learn
<re_irc>
wokwi.com -> this will be helpful making a Rust calculator with a pico
<re_irc>
<eldruin> that driver is _fairly_ popular with 18k downloads
<re_irc>
<eldruin> but no idea how much comes just from CIs
<re_irc>
<therealprof> I think the question was more about drivers consuming an ADC trait.
<re_irc>
<eldruin> re. ADC being fast enough, it depends on your integration time for example
<re_irc>
<eldruin> ah, sorry I mistunderstood, thanks!
<re_irc>
<eldruin> (haha mistunderstood. a nice word for all german speakers here)
<re_irc>
<therealprof> My older son would say: Dad joke now. 😄
<re_irc>
<dngrs (spookyvision@github)> I'm just a soul whose indentations are good…
<re_irc>
<therealprof> * say "Dad joke"
<re_irc>
<eldruin> It's appropriate for me then
<re_irc>
<eldruin> re. e-h-async alpha release SGTM anytime, also without serial for now
<re_irc>
<eldruin> re. async CAN no idea I'm not a user, but adding traits in a future release is never a problem. we can just postpone it
<re_irc>
<dirbaio> gotta wait until someone writes an async CAN stack
<re_irc>
<eldruin> well there is a lot of interest in embedded Rust in automotive so maybe sometime in the future
<re_irc>
<adamgreig> does it really need much of a stack?
<re_irc>
<matoushybl> It’d be nice to have a stack using which different protocols like canopen can be implemented.
<re_irc>
<adamgreig> ooh yea, a canopen implementation on top of the embedded-hal can traits could be nice
<re_irc>
<dirbaio> no, gotta wait until TWO people write two async CAN stacks
<re_irc>
<dirbaio> so that you need a trait to write code generic over both :P
<re_irc>
<heksa> I've been exploring RISC-V interrupts on Renode virtual prototypes. It's fun. There was a little bit of a pain point in that the RISC-V vectored interrupts need the stack store/restore written in assembly. GCC and LLVM seem to have the 'interrupt' attribute to do that automatically. There's a pre-RFC on interrupt calling conventions though, so that's great:...
<re_irc>
<eldruin> +i.e. it uses the "OneShot" trait
<re_irc>
<GrantM11235> That doesn't seem very generic since it is hardcoded to use "ads1x1x". The OneShot trait could just as easily be replaced with an inherent method.
<re_irc>
<eldruin> yep, it seems like the author intended to exchange the ADC somewhat more easily but not really
<re_irc>
<GrantM11235> They probably just found the OneShot trait before they found an inherent read method
<re_irc>
<GrantM11235> It looks like you have an inherent "read" method in continuous mode, but not in oneshot mode
<re_irc>
<eldruin> no, in my driver I just implemented the trait
<re_irc>
<eldruin> then infallible pin would not solve it either because flush is also always done
<re_irc>
<dirbaio> not sure what the benefit of requiring infallible CS is? the code behaves the same whether or not you require it, if your CS is infallible
<re_irc>
<GrantM11235> BTW, whatever the solution is, I think that it should live outside of the main "embedded-hal" crate
<re_irc>
<GrantM11235> If you allow a fallible CS, you need to know what to do if it fails, which can be really complicated
<re_irc>
<eldruin> yeah we discussed putting it somewhere separate along with RefCell/Mutex versions
<re_irc>
<eldruin> (same happens with flush, which definitely is fallible)
<re_irc>
<dirbaio> GrantM11235: probably just panic/exit heh
<re_irc>
<dirbaio> but IMO I'd leave the choice to the user, vs panicking in EH (or not allowing fallible at all)
<re_irc>
<eldruin> my question at the time I think it was how would such a thing fit together with shared-bus
<re_irc>
<eldruin> also, we would need a proposal on which implementations to include
<re_irc>
<GrantM11235> IMO, shared-bus is a hack that was required because of the way the old traits worked
<re_irc>
<eldruin> yeah but I mean shared-bus could be reworked
<re_irc>
<eldruin> the name is pretty neat
<re_irc>
<eldruin> we could always have e-h-shared
<re_irc>
<eldruin> that does not sound too bad
<re_irc>
<GrantM11235> I was thinking maybe "embedded-hal-utils"
<re_irc>
<eldruin> uhh utils...
<re_irc>
<GrantM11235> It could also include an adapter that impls traits with "Error = Infallible" which panics on errors
<re_irc>
<eldruin> anyway I would favor putting that outside of e-h itself as well
<re_irc>
<dirbaio> so you can write a driver using async, and then if your HAL doesn't have async you can give it a blocking impl
<re_irc>
<dirbaio> cc lulf
<re_irc>
<dirbaio> it's quite handy to break the async/blocking divide
<re_irc>
<dirbaio> I was hoping to propose it upstreaming somewhere
<re_irc>
<dirbaio> in that "utils" crate? 😂
<re_irc>
<eldruin> haha nice
<re_irc>
<dirbaio> sometime
<re_irc>
<dirbaio> embedded-hal-kitchen-sink
<re_irc>
<eldruin> all code is async if you never need to yield :P
<re_irc>
<GrantM11235> Since adapters like that should only be used by the end user, not buried in a dependency tree, there is no reason not to make breaking changes whenever needed
<re_irc>
<dirbaio> yeah, separate crate seems a good idea 👍️