<NiaLinaLunaStorm>
any idea how to figure out what's wrong/how to fix it?
AlexStephanus[m] has joined #rust-embedded
<AlexStephanus[m]>
<NiaLinaLunaStorm> "any idea how to figure out what..." <- In my experience, `WouldBlock` is an "error" case that gets returned if an operation is started but not instantaneous. That way the program yields execution back to you in case you want to do something else in the meantime rather than fully blocking until the (potentially long-running) operation is fully completed. I'd try adding an appropriate delay and polling it
<AlexStephanus[m]>
again
<NiaLinaLunaStorm>
AlexStephanus[m]: it's in the main loop which calls this every 1ms
rtzoeller has joined #rust-embedded
nadja has quit [Ping timeout: 252 seconds]
nadja has joined #rust-embedded
emerent has quit [Ping timeout: 252 seconds]
emerent has joined #rust-embedded
sroemer has quit [Ping timeout: 248 seconds]
bitts[m] has joined #rust-embedded
<bitts[m]>
<NiaLinaLunaStorm> "it's in the main loop which..." <- WouldBlock basically means that there is no data available yet. You can try to add block! around your read_report just to see what happens then.
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
dinkelhacker_ has joined #rust-embedded
thejpster[m] has quit [Quit: Idle timeout reached: 172800s]
ryan-summers[m] has joined #rust-embedded
<ryan-summers[m]>
<NiaLinaLunaStorm> "I keep getting UsbHidError::..." <- This is basically saying that your USB HID interface is trying to read a report from the host on an EP-OUT, but the host hasn't sent anything yet. The driver is sending `WouldBlock` because there's no report available. USB is entirely host-driven, so the device side can't force the data to be available, the host has to send the report. What I suspect is happening is that
<ryan-summers[m]>
your host-side (PC) isn't sending the report that you're expecting
<ryan-summers[m]>
<GeorgesP[m]> "What's wrong with it ? (I am..." <- There was a lengthy discussion around this and there's an associated blog post that I can't find right now. But the fundamental issue is that cargo features are additive, so having a feature that makes something "async/non-async" fundamentally doesn't make sense because of how cargo does feature unification IIRC. Basically, having a switch via cargo features is generally a way
<ryan-summers[m]>
to have a bad time in complex systems from what I recall
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
or something about the usb stack is broken and the device can't receive anything :P
<ryan-summers[m]>
^ Also very valid about the USB stack being broken, but that would require a deeper dive first. I added tracing support to the USB device stack for non-embassy stuff to help diagnose those kind of issues
<dirbaio[m]>
I don't mean necessarily a bug in the crate. could be wrong RCC config, wrong pins...
<dirbaio[m]>
* in the usb crate. could
sourcebox[m] has quit [Quit: Idle timeout reached: 172800s]
<bitts[m]>
I am playing around with a HAL for a TI chip. I've produced a PAC using tixml2svd and svd2rust - unfortunately, all registers that are similar and "should" have had a common trait are instead given separate names, making it painful writing generic code (hello macros). Is there a "standard" way of wrapping these registers into traits? An existing hal I could draw inspiration from maybe?
<GeorgesP[m]>
<ryan-summers[m]> "This is the blog post I was..." <- So the only "good" way is code duplication ?
<ryan-summers[m]>
The synopsis so far is that there isn't a "good" way to do it unfortunately. maybe-async is probably a "not-bad", but it's an open discussion topic
blocboyy[m]1 has left #rust-embedded [#rust-embedded]
<NiaLinaLunaStorm>
<ryan-summers[m]> "This is basically saying that..." <- thanks for explaining, then I will use wireguard to see if it sends the expected data
sroemer has joined #rust-embedded
<NiaLinaLunaStorm>
thanks, that was the needed hint, it wasn't a firmware issue but one in the application, it indeed didn't send the proper report. (cause apparently it does things a little bit different between the two devices)
<NiaLinaLunaStorm>
now I know for the future as well what it means and how to try to find the issue, thank you
<ryan-summers[m]>
Glad you got it working :) In general, I wouldn't be afraid to do a dive into the source code to see why it might return certain errors. It's a bit easier in Rust than something like C/C++ in my experience. That being said, we're often happy to help here too :)
dinkelhacker_ has quit [Ping timeout: 256 seconds]
DarkoYovanoski[m has quit [Quit: Idle timeout reached: 172800s]
diondokter[m] has joined #rust-embedded
<diondokter[m]>
Thinking of creating a `device-driver-browser` where you can run a device driver on-device, but manipulate/inspect it on your PC for easy hacking. It really helped for my S2 radio driver that ST built something like that (except that it also sucked)
<diondokter[m]>
James Munns: poststation has a UI, right? What did you end up using? Ratatui?
<JamesMunns[m]>
Yeah, the UI I've demo'd so far is based on ratatui
<diondokter[m]>
Ok, cool, thanks!
<JamesMunns[m]>
If you want to use poststation, let me know, I can send you a build :)
<diondokter[m]>
Might at least try out postcard-rpc for it. Not quite sure what poststation would add. I think I've read something about it at some point, but it's been a while. Do you have a link with a description to refresh my memory?
<JamesMunns[m]>
onevariable.com/poststation - the biggest thing is that you'd have a CLI out of the box, and soon a REST app, and maybe some time soon a graphical UI for doing the poking.
<JamesMunns[m]>
But if you make it work with postcard-rpc, it'll Just Work for poststation later too :)
<JamesMunns[m]>
s/app/interface/
<diondokter[m]>
Thanks!
<JamesMunns[m]>
btw, the goal once the GUI ships is that people don't *have* to make bespoke GUI tools, if you're just watching values/logs, or making "human time scale" poking/commands
thejpster[m] has joined #rust-embedded
<thejpster[m]>
What does the word target mean to you?
<thejpster[m]>
because it also means [lib] or [[bin]] in a Cargo.toml package file
<thejpster[m]>
🙃
<JamesMunns[m]>
lol
<diondokter[m]>
Yeah, I used to be confused about the `--all-targets` flag. I mean, why would I want to build for thumbvxxx, riscv, wasm, linux, windows and more?
<JamesMunns[m]>
Hoping to have results by the end of the year, bartmassey has offered to help, would be happy to have any other folks to help sift through the results, but probably limited somewhat to wg members (responses aren't super secret, but we want to do a filter pass, as some folks included contact info, etc. there)
<JamesMunns[m]>
It probably makes sense to just keep using https://github.com/rust-embedded/wg/issues/782 as a tracking issue, so feel free to sound off there if you have interest in crunching data :)
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
We could just feed the responses to an AI and ask it to look for PII… 😀
<JamesMunns[m]>
(also some good notes from Jordens on what we could do better next year!)
newam[m] has joined #rust-embedded
<newam[m]>
I would just get an LLM to summarize sentiments from textual input fields and skip releasing data because mistakes happen.
<newam[m]>
* skip releasing raw data because
<JamesMunns[m]>
I'm not personally very pro LLM/AI, but I don't think we need to debate that topic now :)
<newam[m]>
Fair enough.
<bartmassey[m]>
(The Embassy changes look great BTW.)
<adamgreig[m]>
it's exciting to finally see various std types land in core and then become somewhat usable, like core::net for IpAddr and core::error
<adamgreig[m]>
years in the making for sure
<newam[m]>
core::net is so useful for unit testing. No more frivolous type conversions.
rmsyn[m] has joined #rust-embedded
<rmsyn[m]>
core::error is probably the most exciting for me, unlocks so many other implementations (core::io specifically)
<therealprof[m]>
Next station: True custom allocator support for all std types. 😉
<adamgreig[m]>
I think the question really is "should we update e-h docs to recommend that HAL authors also impl core::error for their error types"
<dirbaio[m]>
> Adding the core::error::Error recommendation to the e-h trait docstrings
<dirbaio[m]>
SGTM. sad we can't enforce it due to backwards compat, but recommending it sounds good.
<adamgreig[m]>
yea, we can save enforcement for a hypothetical v2 if ever, and in the meantime I guess the hope is enough HALs do it that drivers can also rely on it
<adamgreig[m]>
that's a bigger change than docs update
<therealprof[m]>
SGTM
<dirbaio[m]>
what i'm not sure about is
<dirbaio[m]>
it seems to me it's an utility, providing *one particular way* to impl `core::error::Error`. IMO it should be left to the HALs to decide how they implement it?
<dirbaio[m]>
> Moving embedded-hal-error into embedded-hal (just into the repo or even into the crate)
<adamgreig[m]>
yea, it's one particular way that happens to have core Error already impl'd, so I think it's only useful as a quick utility for HAL authors
<dirbaio[m]>
but from looking at the example, the HAL doesn't use it, the driver does
<dirbaio[m]>
so it seems the intent is to "paper over" HALs not implementing Error instead?
<adamgreig[m]>
oh, huh, yea you're right, the example HAL has its own distinct error type
<therealprof[m]>
Uh oh, do I sense another Error discussion coming up? 😅
<adamgreig[m]>
I guess for drivers it makes it easier for them to write methods returning Error with the relevant conversion traits available so that ? and such works oob
<adamgreig[m]>
s/oob/ootb/
<adamgreig[m]>
I would have thought HALs could use it as a convenient struct that impls error, but they'd still need their own inner E type anyway so not much gained
<dirbaio[m]>
drivers can still impl Error for their errors though, even if the HAL doesn't
<dirbaio[m]>
the downside is they won't be able to return the HAL error in cause
<dirbaio[m]>
does thiserror autoimpl cause so it requires the inner things in the enum to impl Error?
<rmsyn[m]>
the HAL error type can always be wrapped in a driver-local type, so the driver can impl core::error::Error on the wrapper
<rmsyn[m]>
then, the wrapper type is added to the driver-local Error type (enum or struct)
<dirbaio[m]>
hm the e-h-error repo uses a thiserror fork branch that no longer exists :D
<adamgreig[m]>
it's just for the tests, right?
<dirbaio[m]>
yeah
<adamgreig[m]>
rmsyn[m]: right. this embedded-hal-error proposal just provides such a wrapper for you to save the driver writing it out agani
<dirbaio[m]>
but still, I wanted to play with the code to answer my questions 🤷
<dirbaio[m]>
- user can do `.source()` to get the wrapped hal error
<dirbaio[m]>
- user can do `.source()` again to get the ErrorKind
<adamgreig[m]>
I wasn't sure. I don't think it automatiaclly does cause, you can ask for from and source but the source() impl is manual
<rmsyn[m]>
adamgreig[m]: yeah, just suggesting that for HALs that decide not to use it / implement `core::error::Error` on their `Error` type, there is another workaround
<rmsyn[m]>
e-h-error could also provide some helpers to do this in drivers (macros or regular functions)
<dirbaio[m]>
dirbaio[m]: so maybe the driver can impl `.source()` to return the ErrorKind directiy? a downside would be the user wouldn't be able to inspect the HAL error, only the kind.
<dirbaio[m]>
anyway
<dirbaio[m]>
my guess is people aren't going to use .source() much to inspect errors due to the dyn bloat it brings
<dirbaio[m]>
and because it's less readable imo (the example in that test would be much more readable if you just do a match...)
<dirbaio[m]>
s//`/, s/.../`... while using Error requires downcasting and return-type-polymorphism./
<dirbaio[m]>
so personally i'd just wait
<dirbaio[m]>
wait for HALs to implement Error
<dirbaio[m]>
* wait for HALs and drivers to implement Error
<dirbaio[m]>
wait for users to want to use it
<dirbaio[m]>
and then do something only if this proves to be a pain point (my hunch is it won't be)
<adamgreig[m]>
yea. in the meantime e-h-error already exists and is published so it's not like people can't use it
<dirbaio[m]>
the situations where using dyn + .source() + .downcast() is better than match seem quite limited to me
<adamgreig[m]>
cool, that seems like a good conclusion for now then (ping Robert Jördens to look later)
<dirbaio[m]>
that's my opinion though! if people have input on examples where they want to use .source() or where the HAL not impling Error is a pain point I'd love to hear it :D
<adamgreig[m]>
second point is I think more of a heads-up at this point that James Munns has opened a tracking issue at https://github.com/rust-lang/leadership-council/issues/127 to (re)start discussions about where the wg fits into the rust project
<adamgreig[m]>
that's all I had, any other points from anyone?
<JamesMunns[m]>
I hope everyone had/has a good week :D
<adamgreig[m]>
ok, let's finish there then, thanks everyone!
<adamgreig[m]>
time to go feed my cat who's been very politely asking for food for the last ten minutes...
<JamesMunns[m]>
Thank you adamgreig !
<JamesMunns[m]>
adamgreig[m]: > very politely asking
<JamesMunns[m]>
did the polite asks hit "rocket launch" decibels yet? :D
igiona[m] has quit [Quit: Idle timeout reached: 172800s]
M9names[m] has quit [Quit: Idle timeout reached: 172800s]
embassy-learner[ has quit [Quit: Idle timeout reached: 172800s]
<RockBoynton[m]>
I asked in the RTIC channel too, but I wanted to get more eyes on it:
<RockBoynton[m]>
I assumed the blinky task should be at a higher priority level than the long_fn task but when I do that, the blinky task only allows it to run for a short time before it takes over and prevents long_fn task from continuing executing. I thought the await points in both tasks would allow them to both run, but am I misunderstanding something?
<RockBoynton[m]>
In RTIC, how do I keep a blinky task working while a long-running software task (async fn long_fn) is cooking?
cinemaSundays has joined #rust-embedded
Makarov has quit [Ping timeout: 256 seconds]
<dirbaio[m]>
as long as both tasks yield regularly, it should work. even if you have both at the same priority
<RockBoynton[m]>
that long_fn has (blocking) spi writes in it and I think that might be the problem, maybe when the rtic executor pre-empts long_fn in favor of blinky, it was in the middle of a spi write and it doesn't like that, and that task hangs there
<RockBoynton[m]>
when I comment out the spi writes they both run as expected
<dirbaio[m]>
that sounds strange. blocking spi should tolerate getting preempted. what HAL is it?
<RockBoynton[m]>
stm32h7xx-hal
<RockBoynton[m]>
also, running them at the same priority level allows the long_fn to run even with the spi writes, but not blinky
<RockBoynton[m]>
as in, not at the same time...blinky still runs like normal after long_fn finishes
<dirbaio[m]>
yeah that's expected if you have a big block of blocking operations with no yielding in the middle
<dirbaio[m]>
you can fix it by making it execute yield_now().await regularly
<dirbaio[m]>
putting the blinky task at a higher prio should work though. what does the code for the blinky task looks like? it's doing an async sleep, right?
<dirbaio[m]>
* prio should always work though, * work though (even with no yields). what
<dirbaio[m]>
not sure if rtic has an equivalent somewhere. if it doesn't, embassy's works on rtic just fine
<RockBoynton[m]>
so yield_now() in the loop iterations didn't work, however adding a critical section around the spi writes did work!
<RockBoynton[m]>
well actually, yield_now makes blinky also run if the tasks are at the same priority!
<RockBoynton[m]>
dope, thank you dirbaio for your support
<dirbaio[m]>
RockBoynton[m]: hmm that feels like a smoking gun pointing to a bug in stm32h7xx-hal where spi doesn't like getting preempted...
<RockBoynton[m]>
yes, indeed
<dirbaio[m]>
weird
<RockBoynton[m]>
dirbaio: did you get so comfortable with async by writing your own executor, using async a lot, some education materials or a combination? I am trying to understand it deeper so I can find those gotchas like "you need `yield_now()` for long running tasks if you want cooperative multi-tasking to work", but I'm not sure where to start
<dirbaio[m]>
and embedded async rust is pretty much the same as non-embedded, so a lot of content is still applicable even if it's not specifically about embedded