eldruin[m] has quit [Quit: Idle timeout reached: 172800s]
jake_001[m] has quit [Quit: Idle timeout reached: 172800s]
Mathy[m] has quit [Quit: Idle timeout reached: 172800s]
chrysn[m] has joined #rust-embedded
<chrysn[m]>
Updating the coap-{handler,message} etc crates to fallible message creation, I'm finding to my great joy that Concise Problem Details (RFC9290) work really well here: It's just a map_err and an extra 5 bytes in the response to a failed request to tell the client where they messed up (eg. when sending binary data where UTF-8 is expected).
<chrysn[m]>
Granted, other embedded devices will not make use of that, but this should make embedded CoAP servers much nicer to work with.
IlPalazzo-ojiisa has joined #rust-embedded
FreeKill[m] has joined #rust-embedded
<FreeKill[m]>
Okay it's go time - f072 disco board in hand, let's see what this embedded rust USB ecosystem is all about
<JamesMunns[m]>
usb-device and embassy-usb are both really nice on the stm32f0
<FreeKill[m]>
Think im gonna skip embassy for now
<FreeKill[m]>
That feels like an extra layer to get to grips with after the rest really clicks
<JamesMunns[m]>
I dunno why people say that, it seems like a really common misconception
<JamesMunns[m]>
it's not more or less, just different.
<JamesMunns[m]>
but, like I said, both are good!
<FreeKill[m]>
Well okay maybe that's a good place to start, because I definitely hold that misconception.
<FreeKill[m]>
My assumption was that embassy-usb would be setting up a bunch of async wakers in and around the USB IRQs, and providing an async api - and that that would be pretty complex
<FreeKill[m]>
Whereas the usb device impl on the f072 was driven forwards by being polled, so it's not doing much more than reading status registers and acting on it?
<JamesMunns[m]>
lemme see if I can find a recent project, you don't have to do much of any of that
<FreeKill[m]>
I appreciate I don't have to do it myself
<FreeKill[m]>
My goal isn't to achieve the end product - it's to understand the stack :)
<FreeKill[m]>
okay! Well maybe ill end up doing both :)
<JamesMunns[m]>
FreeKill[m]: Any reason why you expect that? They honestly both work pretty well, and I've basically never NEEDED to do that, in the 3 years or so of using one then the other :D
<FreeKill[m]>
Because i want to
<JamesMunns[m]>
like, you CAN! The source is available! But you certainly don't have to.
<FreeKill[m]>
My 2024 resolution is to engage with embedded rust, and hopefully help contribute
<FreeKill[m]>
And for me that means understanding how it all works
<a2800276>
welcome to the club :)
<JamesMunns[m]>
Just throwing it out there: "understanding a usb stack" is a lot like "implementing a linked list".
<JamesMunns[m]>
It's a good goal! But I personally think it's a bad FIRST goal. I've spent a lot of time teaching Rust + Embedded + Embedded Rust. But you 100% know you better than I do.
<JamesMunns[m]>
Anyway, good luck, no more preaching from me (other than maybe continuing to dispel the notion that embassy is "more" or "more complex" than other options)
<FreeKill[m]>
Well I have experience developing for this USB hardware, in the ST C ecosystem. And I've done a non-zero amount of Rust (embedded and not). So I'm hoping I don't have too much knowledge to bridge.
<FreeKill[m]>
For me it's not so much about understanding exactly how - say- the USB stack does everything. But more the various crates, the traits that join them and the general approaches they take. Because that is something I feel very "vibes only" about having come from embedded C.
<JamesMunns[m]>
Gotcha! I don't think either path will stop you!
<JamesMunns[m]>
(and always happy to answer questions) :)
<FreeKill[m]>
Appreciated, this has always seemed like a very sound and helpful community 👍️ But I'll struggle a bit first ;P
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
if you want more fun, you can just skip all those crates and implement usb from scratch with register access
<adamgreig[m]>
certainly you'll learn a bit about usb that way
<adamgreig[m]>
the f0 usb peripheral isn't too bad, except for some weirdness around accessing its dedicated sram
<FreeKill[m]>
I've had enough intimate contact with the USB hardware working in ST-land, so I think I'm sated in that respect for now ;P
<FreeKill[m]>
QQ: How do I get probe rs to show RTT content?
<vollbrecht[m]>
can you clarify what you mean by show content? By default it searches for RTT output streams and should display them. do you only have one output stream or multiple?
<JamesMunns[m]>
I know cargo embed has Embed.toml settings for all of that, I dunno how to make probe-rs run do it
<vollbrecht[m]>
you could try though using the defmt_rtt crate and drop the rtt-target crate for testing. The defmt_rtt macro init the segger_magic a bit different from memory
<JamesMunns[m]>
(it seems like it always should/does go looking for RTT headers?)
ryan-summers[m] has quit [Quit: Idle timeout reached: 172800s]
<FreeKill[m]>
The mapfile shows that _SEGGER_RTT is a symbol @ the origin of RAM
<FreeKill[m]>
so I think it's linked in correctly
<vollbrecht[m]>
its not about the symbol but the context that is supposed to be there
<JamesMunns[m]>
looks like there's a rttEnabled: true setting in vscode?
<JamesMunns[m]>
it's not in the docs, I'm looking for it lol
<FreeKill[m]>
it /is/ rttEnabled, but you have to put it in the coreConfigs subsection
<JamesMunns[m]>
FreeKill btw, is there a reason you picked `rtt-target` over `defmt`/`defmt-rtt`?
<FreeKill[m]>
Which is not done by default and doesn't appear in the autocomplete, so I guess it's missing from a schema somewhere
<JamesMunns[m]>
(just wondering how you ended up at that decision, I feel like defmt gets discussed way more here, so I was wondering if there was some guide or something you were following)
<FreeKill[m]>
Nope. But straightforward RTT is familiar from C-land so I picked it as the easiest sign of life I could quickly (hah) get going
<FreeKill[m]>
Anyway it now lives, it's saying Hello! over and over which is lovely to see
<FreeKill[m]>
Took me a minute to realise I had to provide my own memory.x but that's okay
AdamHott[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
basically though: you'll need to patch ALL embassy crates, and they all need to use the same path or git rev
<JamesMunns[m]>
(tho this should hopefully be much less common as everything is publishing to crates-io now-ish)
<barnabyw[m]>
there’s a more detailed step-by-step example in the “starting a new project” page if the FAQ isn’t clear enough. but are you using path dependencies locally in your project, or was that example from embassy itself?
<SzczepanCielik[m>
ah I get it - thanks! Will dig through those materials :)
<JamesMunns[m]>
note that you probably want to use version = ... in the [dependencies] section, and specify your git/path overrides in the patch section.
<JamesMunns[m]>
Usually you do it "reverse", so `Cache` would have all the methods, and you'd have a sealed `SealedCache` or something with no methods to prevent other impls. diondokter right now if the user can't import the trait, they can't use any of the methods, was that your intent?
<SzczepanCielik[m>
JamesMunns[m]: Ok, will try this 👍️
d3zd3z[m] has joined #rust-embedded
<d3zd3z[m]>
SzczepanCielik[m: Even just `let () = Ws2812::new();` will work. `()` is not just a type and a value, but a pattern as well.
<JamesMunns[m]>
Yeah, it's treating the compiler like the internet: the fastest way to get a right answer is not to ask, but to say the wrong answer and wait to be corrected.
<SzczepanCielik[m>
ok, cool - it worked, still wonder about passing variables but I'm done for today 😅
<barnabyw[m]>
what are your preferred tools for inspecting compiled assembly for embedded rust projects? i.e. something like godbolt but ideally offline/integrated with vs code
<barnabyw[m]>
it would also be really neat to have a vscode viewer for elf files, which displays something like the output from readelf, but I can‘t find anything like that which actually works
<FreeKill[m]>
puncover is pretty fantastic
<FreeKill[m]>
(I use it for C, but I assume it works just the same for Rust)
<barnabyw[m]>
oh neat, that does look handy
<FreeKill[m]>
im thrashing a bit trying to set up this USB device on the F072. I understand I have the stm32-usbd crate which is supposed to provide an implementation of UsbDevice
<FreeKill[m]>
But it, itself, requires a peripheral which implements UsbPeripheral, and... I can't find that? In the HAL or device crate. And the examples in stm32-usbd are out of date
<FreeKill[m]>
Anyone done this before and can point me the right way?
<barnabyw[m]>
I don’t see UsbPeripheral anywhere, just stm32f1xx_hal::usb::Peripheral
<FreeKill[m]>
omg yes
<FreeKill[m]>
Yeah that is the struct that implements UsbPeripheral
<FreeKill[m]>
It is not like that in the 072 example
<FreeKill[m]>
Am I doing something stupid wrt discoverability? I knew there must be a struct in this crate that implemented UsbPeripheral and that's what I needed, but I couldn't find it because you can't search by implemented Traits?
<barnabyw[m]>
rust-analyzer didn‘t find anything, but cargo doc --open, searching for UsbPeripheral and then looking under Implementors gets me to stm32f1xx_hal::usb::Peripheral
<barnabyw[m]>
(which also showed up in the search results, if you don’t consider that cheating ;))
<FreeKill[m]>
never used cargo doc --open. That's just docs for all the crates you've pulled in?
<FreeKill[m]>
(and the one youre in ofc)
<barnabyw[m]>
offline docs for everything in your current project, yep!
<FreeKill[m]>
that's waaaaaaaay nicer
<FreeKill[m]>
awesome
<barnabyw[m]>
(I just need to figure out how to persuade my linux machine to --open docs in firefox rather than in some random OCR program which somehow claimed rights to all HTML files…)
<barnabyw[m]>
nice, now I just need to re-learn how to read assembly. last time I used it was for programming PICs 🙄
<FreeKill[m]>
I think i've found my first contribution, which is bring the stm32f072 example up to date with what i've just done :P
therealprof[m] has quit [Quit: Idle timeout reached: 172800s]
fuse117[m] has joined #rust-embedded
<fuse117[m]>
I am working with a new device that has an STM32U545RET6Q, which probe-run doesn't seem to support. I don't have a lot of experience working with STM chips, so I am not sure how best to proceed with this device. Can someone offer some advice on how?
<fuse117[m]>
* on how to work on such a chip?
<FreeKill[m]>
You can use the old school debuggers! Deploy with stm32programmer, debug with gdb
<firefrommoonligh>
Maybe see what patching probe-rs would take? Does anyone know?
<adamgreig[m]>
what gave you the impression it wasn't supported? is it missing from a list somewhere?
<adamgreig[m]>
aah, sorry, I think I see what's up. if you're using probe-run it's been deprecated by the authors and so hasn't updated to the newest version of the probe-rs library it uses which contains the updated chips; you should swap to using probe-rs run instead of probe-run
<adamgreig[m]>
should be able to cargo install probe-rs --features cli (or use the binary installer on the probe.rs website to avoid having to build it all from source)
IlPalazzo-ojiisa has quit [Quit: Leaving.]
sjm42[m] has joined #rust-embedded
<sjm42[m]>
Ooof, I was able to successfully build and run an IRC bot on ESP32 and ESP32-C3 hardware :D