<sajattack[m]1>
shouldn't u64 impl into From<u32>?
<sajattack[m]1>
and shouldn't also NanosDurationU32 impl From<MicrosDurationU32>?
<sajattack[m]1>
s/into//, s/</\</
<rmsyn[m]>
@thejpster:matrix.org thanks for the help, that solved the "Illegal instruction" error. really should have read the `riscv-rt` docs better... now I'm getting a `Store/AMO access` error, but it feels like it's going in the right direction
ian_rees[m] has joined #rust-embedded
<ian_rees[m]>
<sajattack[m]1> "and shouldn't also NanosDuration..." <- just going off the name, I wouldn't think so because one is 1000x bigger in duration, so like 7 more bits required
<ian_rees[m]>
> <@sajattack:matrix.sajattack.xyz> and shouldn't also NanosDurationU32 impl From<MicrosDurationU32>?
<ian_rees[m]>
* just going off the name, I wouldn't think so because one is 1000x bigger in duration per bit, so you'd need like `NanosDurationU39`
<sajattack[m]1>
mmh yeah
<rmsyn[m]>
woot! got it working, just had to only define the RAM section since I'm just loading into RAM from u-boot. now the test program thinks that's all there is.
<rmsyn[m]>
many thanks
emerent_ has joined #rust-embedded
emerent has quit [Killed (erbium.libera.chat (Nickname regained by services))]
emerent_ is now known as emerent
notgull has quit [Ping timeout: 268 seconds]
notgull has joined #rust-embedded
eldruin[m] has joined #rust-embedded
<eldruin[m]>
<dirbaio[m]> "my proposal is December 28, when..." <- That sounds good to me as well if no further concerns are raised :)
crabbedhaloablut has joined #rust-embedded
<sajattack[m]1>
<ian_rees[m]> "just going off the name, I..." <- other direction then
Guest7221 has joined #rust-embedded
Guest7221 has quit [Quit: Gateway shutdown]
Guest7221 has joined #rust-embedded
sigmaris has quit [Server closed connection]
sigmaris has joined #rust-embedded
<ryan-summers[m]>
Is it possible to size a buffer based on an associated constant of a trait object?
<diondokter[m]>
Sadly not yet
<diondokter[m]>
It gives a weird error that not all values are valid. Pretty weird for when you give it a usize
<ryan-summers[m]>
Meh okay, unsupported behavior, will avoid then
<ryan-summers[m]>
Kinda lame, but it is what it is. I'll probably just wait on Dion's updates ;)
<JamesMunns[m]>
btw, I mentioned `postcard-rpc` yesterday, I pushed a v0.1.1 with better docs, and wrote up an [overview doc](https://github.com/jamesmunns/postcard-rpc/blob/main/docs/overview.md) that explains the big picture "why" and "how", for anyone interested in poking around with it :)
sourcebox[m] has joined #rust-embedded
<sourcebox[m]>
Is there some common practice/traits/whatever how to deal with USB descriptors?
<JamesMunns[m]>
but usually, if you are not using async, you'd implement the UsbClass trait for the usb-device crate, if you're using async embassy-usb does something slightly different
<sourcebox[m]>
Async is something I will probably do later.
<JamesMunns[m]>
Fair! They both abstract over the same concepts, so I think if you figure out the class stuff for one, it should be pretty easy to port to the other ;)
<JamesMunns[m]>
s/;/:/
<sourcebox[m]>
For most of the projects in the past, I manually crafted the descriptors, but I think there's a better solution possible to have them composable and also dynamic.
<sourcebox[m]>
E.g. the UTF-16 string descriptors. There seem to be some functions in core, don't know if they're useful.
limpkin has quit [Quit: No Ping reply in 180 seconds.]
<barafael[m]>
I'm glad to see there is some support for workspaces with packages which have different targets. However, I can't quite get it to work and I suspect it's a cargo issue (as I did have to enable a cargo feature for this):
<barafael[m]>
anybody has more success with this or got it to work?
<JamesMunns[m]>
I think that's the best way today, mnemos has quite a complex set of features + config to get multi target workspaces working
<JamesMunns[m]>
my personal opinon though is "don't", you'll run into too many problems around features and targets. I'd suggest instead not using workspaces, or use one for the host PC and one for the MCU target.
<JamesMunns[m]>
you may also need profile-rustflags
<barafael[m]>
I have shared crates :cry: which define nicely the protocol
<JamesMunns[m]>
yeah... it seems a little wasteful, but I'd just say "don't use a workspace"
<dirbaio[m]>
I don't think per-package-target prevents merging Cargo features across targets
<dirbaio[m]>
it'll break if the std side enables some feature in a dep that doesn't work on nostd
crabbedhaloablut has joined #rust-embedded
<dirbaio[m]>
my recommendation is
cr1901 has quit [Ping timeout: 245 seconds]
<dirbaio[m]>
make one repo with multiple crates. the std-only and the nostd-only can depend on shared crates by path
<dirbaio[m]>
then make two `.code-workspace` files
<dirbaio[m]>
- one for std code, with `rust-analyzer.linkedProjects` pointing to the top-level std crate (NOT shared deps)
<dirbaio[m]>
- one for no-std code, with `rust-analyzer.linkedProjects` pointing to the top-level no-std crate (NOT shared deps)
<dirbaio[m]>
if you open the std.code-workspace file, rust-analyzer will become active in the std crate, but also the shared crates automatically (because they're deps). same for nostd
<dirbaio[m]>
if you want to edit both you'll have to open 2 vscode windows
<dirbaio[m]>
* shared deps),, * and `rust-analyzer.cargo.target` set to the nostd target.
<dirbaio[m]>
you can also try making a single code workspace with both top-level crates in rust-analyzer.linkedProjects. but IME this caused rust-analyzer to become confused in the "shared" crates because they're present "twice". also you can't set different targets per linked project, so it'll probably cause incorrect errors from rust-analyzer
<AlexandervanSaas>
Hi, I've been using a Raspberry Pi Pico with Embassy with a second Pico as a debug probe and probe-rs and defmt for logging. I now want to try using a ESP32 but I'm a bit lost trying to find out what I need to get a similar debugging and logging setup. Can someone point me in the right direction?
<AlexandervanSaas>
<AlexandervanSaas> "Hi, I've been using a Raspberry..." <- I have a dev board with a `ESP-WROOM-32`. Is it correct I need a ESP prog to debug this chip?
<dirbaio[m]>
<AlexandervanSaas> "I have a dev board with a `ESP-..." <- if you want just flashing and logging, the builtin usb-to-uart works
<dirbaio[m]>
dirbaio[m]: assuming your board has it
<dirbaio[m]>
dirbaio[m]: you need the ESP-PROG for JTAG, to do actual debugging (inspect values of variables, single-stepping, etc)
<dirbaio[m]>
dirbaio[m]: not sure how good the support for that is for Rust tooling
<dirbaio[m]>
dirbaio[m]: people in #esp-rs:matrix.org will probably have better answers
<barafael[m]>
dirbaio: the no cargo ws, dual vscode ws solution is nice. Only minor downsides to workspace approach. I like that I can set profiles and patch.crates-io per-crate again
<AlexandervanSaas>
<dirbaio[m]> "if you want just flashing and..." <- Does this work with probe-rs?
<barafael[m]>
downsides are that CI doesn't know what to run (I have to make it a manual list there now) and there is no central place for the 7 binaries I produce (I just have to collect them from all over the place, fine)
<dirbaio[m]>
AlexandervanSaas: no, you'd use `espflash` or `esptool.py`
<dirbaio[m]>
7 std binaries?
<dirbaio[m]>
you can make one cargo workspace for the std part, put the 7 std binary crates in it, then put that in the linkedProjects for the std vscode workspace
<barafael[m]>
yep. There are several binaries for host and for mcu. Perhaps also time to rethink that
<barafael[m]>
dirbaio[m]: that's what I got
<dirbaio[m]>
if the bins share deps+target+features it might be easier to make them separate bins within a single crate
<barafael[m]>
yes... some of them do. Trying that, it makes sense for at least 2 of them
<BenoitLIETAER[m]>
Guys, can the `probe-rs` support the ATMEL-ICE probe ?
<BenoitLIETAER[m]>
(or maybe I am asking the wrong question here... just want to have this device in the loop for flashing at the trigger of `cargo run`)
<dirbaio[m]>
if it supports the cmsisdap protocol, yes
<dirbaio[m]>
googling "Atmel-ICE cmsis-dap" shows some hits, so maybe yes
<spinfast[m]>
yeah would be nice, I have one of those
<BenoitLIETAER[m]>
Yes, it definitely does (in ARM mode of course, not AVR), as it came with the SAM V71 (Cortex M7)
<BenoitLIETAER[m]>
I believe it is now a matter of writting the right runner
<dirbaio[m]>
cmsisdap is the usb protocol, not SWD
<dirbaio[m]>
there's many SWD probes that are not CMSISDAP and use some proprietary usb protocol instead
<BenoitLIETAER[m]>
ah!
<AlexandervanSaas>
s/./?/
<barafael[m]>
I have ended up with a cargo workspace for the non-shared host programs which has also a vscode workspace file, and a vscode workspace file for the non-shared firmware crates
xnor has quit [Server closed connection]
xnor has joined #rust-embedded
ilpalazzo-ojiis4 has joined #rust-embedded
<ilpalazzo-ojiis4>
thejpster: I see that the EuroRust videos have been uploaded. Do I recall correctly, that you'd made a speech on `async` w/r/t embedded Rust? If so, is it a separate video (which I can't seem to find) or is it part of the 40' “Inside Rust” speech?\
<andresovela[m]>
Speaking of that, does anybody know if RustConf videos are going to be uploaded this year? It’s been a while already, I think in previous years they were uploaded ~2 months after the fact?
<thejpster[m]>
My video was incorrectly edited so it’s been yanked and will be back later. They got two talks stuck together.
<thejpster[m]>
And it wasn’t about async, it was about my silly project and how it took me four years
<chrysn[m]>
Well that happens with async when there isn't an executor direly .awaiting it *scnr*
<diondokter[m]>
Ok, so the github issue is still open
<JamesMunns[m]>
Yeah, if I remember correctly there is some case where that feature isn't set, though maybe it's just that there's no way to add a dep just for doctests or something
<diondokter[m]>
Weird how you can't use it, but it is in the rust book
<thejpster[m]>
I merged ryan-summers 's changes and tidied up a bit. So let's do a release!
<jannic[m]>
LGTM but that doesn't help :-)
crabbedhaloablut has quit []
<thejpster[m]>
would you like to join the rust-embedded-community?
<thejpster[m]>
<AlexandervanSaas> "`espflash board-info` works so I..." <- the #esp-rs:matrix.org room has a bunch of people who work at Espressif and get paid to do Rust support for the chips :)
<M9names[m]>
<thejpster[m]> "the #esp-rs:matrix.org room..." <- There are also a lot of people in that room who don't work for espessif but are very familiar with the chips/environment that are very helpful, too.
<jannic[m]>
I don't know how much I'll contribute, but if it helps to do an occasional code review: Sure!