ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
emerent has quit [Ping timeout: 260 seconds]
emerent has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
DanielakaCyReVol has quit [Quit: Idle timeout reached: 172800s]
luojia65[m] has quit [Quit: Idle timeout reached: 172800s]
WSalmon has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
WSalmon has joined #rust-embedded
notgull has joined #rust-embedded
notgull has quit [Ping timeout: 264 seconds]
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 :)
<JamesMunns[m]> This is an example for a USB-UART on embassy for the F4: https://github.com/embassy-rs/embassy/blob/main/examples/stm32f4/src/bin/usb_serial.rs
<JamesMunns[m]> Looking for a usb-device example that's equivalent...
<JamesMunns[m]> As close to apples to apples as I can get :)
<FreeKill[m]> Indeed! But again that's comparing main to main
<FreeKill[m]> s/again//
<FreeKill[m]> And I expect a lot of my time is gonna be digging in to the guts :D
<JamesMunns[m]> Sure! You could dig into either set of:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/gIwgUMdRjlTlatYYSwWPxBfs>)
<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?
<FreeKill[m]> I feel like I should have just the one.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/HOixXaGZLElbMIIZwmGFArji>)
<vollbrecht[m]> this is rtt-target crate right?
<FreeKill[m]> correct
<FreeKill[m]> with probe rs, used from vscode
<JamesMunns[m]> probably --log-format something?
<vollbrecht[m]> you could cross check with rtthost tool though i think it uses the same bases here
<vollbrecht[m]> * <del>you could, * bases here </del>
<JamesMunns[m]> JamesMunns[m]: ah, nope: https://github.com/probe-rs/probe-rs/pull/1788
<vollbrecht[m]> log-format is when using defmt
<vollbrecht[m]> standalone rtt does not have that
<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
<JamesMunns[m]> in launch.json?
<JamesMunns[m]> it's mentioned here: https://github.com/probe-rs/probe-rs/issues/1497
<FreeKill[m]> :c
<vollbrecht[m]> if you see the way rtt-target inits the section is a bit differnt as defmt-rtt does it. look [here](https://github.com/probe-rs/rtt-target/blob/master/rtt-target/src/rtt.rs#L28) and [here](https://github.com/knurling-rs/defmt/blob/main/firmware/defmt-rtt/src/lib.rs#L124) for comparsion
<FreeKill[m]> Okay got it!
<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]
SzczepanCielik[m has joined #rust-embedded
<SzczepanCielik[m> Hey, how to avoid dependencies checks? This, the newest version... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/PdoInegJOODHzyVQibzrKxJw>)
<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?
<JamesMunns[m]> Also, here's a full (a little old) Cargo toml using embassy: https://github.com/jamesmunns/robert/blob/main/Cargo.toml
<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.
notgull has joined #rust-embedded
Ralph[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]> isn't that just a sealed trait?
<SzczepanCielik[m> Ok, last existential newbie question for today... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/aZZDtWsqdUyuxRTbpYoaKfFg>)
<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?
<JamesMunns[m]> SzczepanCielik[m: > <@beregond:matrix.org> Ok, last existential newbie question for today... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/SIppoemGEEELIooKceyJLQWk>)
<diondokter[m]> JamesMunns[m]: Yeah, those functions shouldn't be touched by the user
<diondokter[m]> It could really break things :P
<diondokter[m]> So yeah, I need a public trait with private internals.
<diondokter[m]> A sealed trait is public with public internals but not publicly implementable
notgull has quit [Ping timeout: 260 seconds]
Mathias[m] has joined #rust-embedded
<Mathias[m]> d3zd3zand ithinuel gave a shout-out to the Embedded Rust community: https://www.youtube.com/watch?v=MIO9FbfPxkI
<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 have a little project which successfully runs a USB Serial device on a STM32F103 from last march, using these dependencies:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/MqhNOEcAYdUZaCXpRycNMjIW>)
<FreeKill[m]> Yeah that doesn't seem out of date! What call is it in the hal crate that actually provides the device implementation?
<barnabyw[m]> honestly I’m not entirely sure as I was mostly just copying from examples, and ended up using embassy now anyway. but here’s the example which was definitely working last March https://gist.github.com/barnabywalters/85b65744eb6fc397021baa81e8e0c93d
<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…)
<FreeKill[m]> Okay! After that hiccup getting an HID device showing up was fine
<FreeKill[m]> <3 barnabyw
<JamesMunns[m]> <barnabyw[m]> "what are your preferred tools..." <- https://crates.io/crates/cargo-show-asm
<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]> you should be able to work off https://github.com/probe-rs/probe-rs/pull/1744 to update stm32u5 targets
<adamgreig[m]> huh, but it does already support it
<adamgreig[m]> STM32U545RETxQ is in the chip list
<adamgreig[m]> and you can just write probe-rs run --chip STM32U545RET6Q if you want, it detects the x as a wildcard and lets 6 go there
<adamgreig[m]> it's on the website too, https://probe.rs/targets/master/STM32U545RETxQ
<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
<sjm42[m]> Used that as a basis and just added a simplified version of my rust irc bot
<sjm42[m]> The firmware was 1.8MB and why? I just wanted to try something that is not dead simple and trivial.
<vollbrecht[m]> good that most modules have 4MB minimum :D
<vollbrecht[m]> * 4MB minimum available :D
<sjm42[m]> Yeah, my ESP32-WROOM modules have 4MB but my el cheapo ESP32-C3 has only 2MB but it worked just fine, tho :D
hannes4761[m] has quit [Quit: Idle timeout reached: 172800s]
gauteh[m] has quit [Quit: Idle timeout reached: 172800s]
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 268 seconds]
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded