YashwanthSingh[m has quit [Quit: Idle timeout reached: 172800s]
diondokter[m] has quit [Server closed connection]
diondokter[m] has joined #rust-embedded
sroemer has quit [Ping timeout: 265 seconds]
sroemer has joined #rust-embedded
sroemer has quit [Changing host]
sroemer has joined #rust-embedded
Foxyloxy has quit [Server closed connection]
Foxyloxy has joined #rust-embedded
<FrreJacques[m]>
Okay, I think the answer to two is no. If I exort a struct that has that generic the generic types are blank in doc. But in the trait where the generics are specified I get a correct linkage to the ehal docs. It's a bit opaque to play around with that in my stm examples as the type seems to be Infallible.
<FrreJacques[m]>
For three I didn't found an answer yet.
jiande2020 has quit [Quit: Ping timeout (120 seconds)]
jiande2020 has joined #rust-embedded
Socke has quit [Ping timeout: 248 seconds]
Socker has joined #rust-embedded
Socker has quit [Ping timeout: 265 seconds]
Socke has joined #rust-embedded
<SEGFAULT[m]>
how do you use embassy-embedded-hal::spi::SpiDevice?!
<SEGFAULT[m]>
I have been arguing with the type system for 2 hours now
<SEGFAULT[m]>
it seems to be cobbled together from about 3 different traits all called SpiDevice, and I can't work out how to move the thing into a task and call .transfer
<SEGFAULT[m]>
its getting fustrating
<JamesMunns[m]>
Do you want an async one or a blocking one
<diondokter[m]>
diondokter[m]: Oh, embassy usb. Derp didn't read that well
<kline>
diondokter[m], a device with multiple independent functions, for example a device that presents a USB audio interface as well as a CDC serial interface
<diondokter[m]>
kline: I've not seen it in examples either, but I've not used it a whole lot...
<dngrs[m]>
There was a discussion about this recently in the embassy room. Should be able to find it by search for composite
<kline>
dngrs[m], i dont have matrix, unfortunately
<kline>
dngrs[m], is there an online archive anywhere?
<SEGFAULT[m]>
that's the example I have been trying to build off
<JamesMunns[m]>
kline: not of the embassy room afaik
<dngrs[m]>
kline: I don't think so
<kline>
:(
<JamesMunns[m]>
SEGFAULT[m]: can you push a repo or something? I can pull it and figure out what is wrong
<SEGFAULT[m]>
wait no I was using the display one I think
<SEGFAULT[m]>
let me have a read of this one
<SEGFAULT[m]>
OK that fixed it, I was missing the static cell. I was trying to pass the raw Spi device in
<SEGFAULT[m]>
I don't get why I need it, when only one device is using the bus
<JamesMunns[m]>
you can probably also pass the peripheral by ownership, and do the whole setup in the task, not shared, and that will likely also work
<JamesMunns[m]>
otherwise passing things by reference won't have the static lifetime if you don't put it in a static cell - main is allowed to return and drop things that are owned there.
davidmpye[m] has joined #rust-embedded
<davidmpye[m]>
SEGFAULT[m]: The static cell is guaranteeing the static lifespan, but isn't doing any locking
<davidmpye[m]>
Unless you've wrapped it in a mutex, and then put that into the staticcell
<SEGFAULT[m]>
I guess that's 0 cost
<JamesMunns[m]>
yeah, it's one byte to mark whether things have been taken, and one extra boolean check when you take/init the data
<JamesMunns[m]>
(you only pay at setup time, not every time you use it, once you have a reference, it's yours)
<SEGFAULT[m]>
The other thing I wanted to ask was about measuring CPU usage, I found a link in the FAQ about an idle task but it was written for RTFM, and didn't seem directly transferable
<JamesMunns[m]>
there's not an off the shelf thing. mostly because measuring interferes with the "ideal path" of always sleeping while idle
<JamesMunns[m]>
if you do want to set it up, it's not terrible, just a bit of boilerplate. I'm not sure if I've done it with modern embassy, but I've done it with really old versions of mnemos. could probably help if you get to that point.
<SEGFAULT[m]>
I am not many steps from "implement an audio engine" in my project, and monitoring if I am running out of DSP cycles is kinda important in that application
<FrreJacques[m]>
Are my questions a bit too generic and low level for this room or phrased too vaguely?
<JamesMunns[m]>
tbh Frère Jacques, there's probably not one "right" answer to your questions, they are pretty high level, and my first gut reaction is "it depends". I'd probably suggest checking how existing crates to it, or just pick one, try it, and see how it goes
<JamesMunns[m]>
some crates have very limited error support, some bubble a lot of data up, some do something in the middle
<JamesMunns[m]>
it's sort of a tradeoff of flexibility vs simplicity of the API: if you want to keep all the original types, you have to carry those generics everywhere
<JamesMunns[m]>
vs if you just smash out all the errors, it might be hard to tell exactly what went wrong.
<JamesMunns[m]>
So, there's probably not anyone to authoritatively answer you, since it's sorta preference/vibes/still being felt out
<FrreJacques[m]>
I see thanks for the feedback!
<davidmpye[m]>
Sounds like postcard-rpc flatten error impl might be of some use?
<JamesMunns[m]>
davidmpye[m]: not sure what you mean!
<davidmpye[m]>
So you can flatten crate-specific errors into something less specific for propagation?
<JamesMunns[m]>
postcard actually probably squishes errors down too much
<JamesMunns[m]>
can't remember where postcard-rpc ended up :D
<JamesMunns[m]>
I think I ended up somewhere near embedded-hal's "can be turned into a common ErrorKind" trait?
<davidmpye[m]>
Can lose the generic nested error types that way too?
<FrreJacques[m]>
I am just looking for some orientation to follow common idiomatic design decisions. But of course that kind of questions end up to have no clear answer.
<JamesMunns[m]>
Ah yeah, it has an associated "as WireTxErrorKind"
<JamesMunns[m]>
so you can always "into" the error, while still bubbling the error up
<JamesMunns[m]>
FrreJacques[m]: yeah, it's also a volunteer room, folks aren't always excited to sit down and write out theory/opinion, esp if they aren't super comfortable :)
<JamesMunns[m]>
most of the time, you just want `Result<Success, Failure>`, not `Result<Result<Result<EndpointSuccess, EndpointFailure>, ServerFailure>, ConnectionFailure>`
<FrreJacques[m]>
I understand that. Also I assume many people here are doing this in a more professional background and supporting a hobbyist is not top prio. Which is fine.
<FrreJacques[m]>
I think in case of that ehal Results it actually might be a rwasonable choice to just drop the errors and map them as they are probably often Infallible and providing the info something went wrong on that pin, might be sufficiently precise.
<JamesMunns[m]>
yeah, you CAN just return the ErrorKind enum itself
<JamesMunns[m]>
and not any more specific detail
<JamesMunns[m]>
(if you are implementing a hal driver)
<dngrs[m]>
Both thiserror and derive_more support no_std these days and should generate you a from(inner_error) so you can (almost) transparently wrap things
<JamesMunns[m]>
dngrs[m]: and fwiw: I've never really needed or wanted to do this on embedded, I'm not sure I've ever understood the value of that)
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
JamesMunns[m]: also the "room number" often gives a false impression. At any given time you maybe are talking to a "class room" size of people. In person you probably also wouldn't get a good answer :D
<dngrs[m]>
JamesMunns[m]: It automates the nested result thing
<dngrs[m]>
Or rather:
<dngrs[m]>
It automates the flattening of the nested result thing
<JamesMunns[m]>
that said, I'm also a person who tends to write all my own errors, so take my opinions in that context:D
<JamesMunns[m]>
* that context :D
<JamesMunns[m]>
I only ever really use thiserror when clients are already using it
<JamesMunns[m]>
(and anyhow in a top level app as a "better unwrap")
<FrreJacques[m]>
Keeping the generics made a lot a bit more complicated and cause some challenges:
<FrreJacques[m]>
I also got the Feeling that the impl of Debug and Display I did are probably quite useless. Because for defmt I would need to impl defm::Format. I thought about using format!, but this is std.
<FrreJacques[m]>
Will need to have a look at optional deps. Thanks!
starblue has joined #rust-embedded
<FrreJacques[m]>
Reworking the error made statements shorter and caused 800 deletions 😱
<thejpster[m]>
uuuuuuuugh, I've spent hours today trying to work out why making a syscall trashes some local variables
<thejpster[m]>
and Arm's build of arm-none-eabi-gdb for Windows sucks. It's failing to load symbols from my ELF, and it doesn't have TUI mode so you can't layout split
<thejpster[m]>
ok, so the xpack build of GDB actually works
<thejpster[m]>
and the bug was that if you call SVC whilst in supervisor mode, LR gets trashed. This is A Known Issue, and you are supposed to push and pop LR (and SPSR) before you do the SVC call.
starblue has quit [Ping timeout: 244 seconds]
starblue has joined #rust-embedded
<thejpster[m]>
ok, well more stuff is working now, but for some reason on Armv8-R when I do a SVC at EL1 I end up in SVC mode but my stack pointer is zero. This doesn't happen in Armv7-R. I wonder if I'm getting back into EL2 somehow.
<thejpster[m]>
cortex-r programming involves quite a lot of assembly, and not having the C pre-processor available inside core::arch::global_asm! makes it quite tedious.
rmsyn[m] has joined #rust-embedded
<rmsyn[m]>
do we have a way to host CI runners that run on actual hardware?
<rmsyn[m]>
I'd be willing to buy hardware (especially RISC-V dev boards), and ship it to whoever wants to physically host it for the working group
<JamesMunns[m]>
embassy has an entire test rack
<rmsyn[m]>
nice, if I donated some hardware, could we extend the rack, and dedicate part of it to the rust-embedded crates?
<rmsyn[m]>
maybe restrict the on-hardware workflows to manually approved, so they don't get spammed
<JamesMunns[m]>
that's probably dirbaio's call
<JamesMunns[m]>
teleprobe is open source, I think it requires his home-rolled github runner
<JamesMunns[m]>
* teleprobe is open source, I think doing the "whole thing" requires his home-rolled github runner
<diondokter[m]>
I had these questions too, so I tried it out in this repo
<JamesMunns[m]>
does that handle the "build in github, transfer elfs to teleprobe" bit?
<diondokter[m]>
Yep!
<JamesMunns[m]>
cool! I know running the actual build on your machine is a very bad idea, because there's no sandboxing
<JamesMunns[m]>
but I guess if you can expose the teleprobe server public-ish, that makes things pretty easy?
<diondokter[m]>
Yeah, you just run the teleprobe server and unless you can do some exploit through either teleprobe or probe-rs I don't really see what could go wrong
<diondokter[m]>
Well, unless you've got an mcu hooked up to your Ethernet... 😅
<rmsyn[m]>
diondokter[m]: yeah, this was another concern I had, too. requiring manual review would help mitigate the threat, but having multiple layers of defense always good
<rmsyn[m]>
something like having the runners on an isolated net, very restricted API, plus all the manual + machine checks for code safety
<rmsyn[m]>
at least for the rust-embedded/riscv crate the manual checks would be pretty easy. like network calls would be very suspicious
<diondokter[m]>
Well the build is still done on the CI server, so no problems there. Then the elf is sent over via teleprobe to your own PC/server