08:16 <FlixtheNewbie[m]> Oh, I just discovered that when I reject() an USB control, the host cuts contact with the device

08:16 <FlixtheNewbie[m]> I thought it was a way to say "Not Implemented"

11:35 <thejpster[m]> Got stopped by a guy at Eurorust - "hey you're from the embedded working group right? It's so good, you did great stuff!

11:35 <thejpster[m]> * great stuff!"

12:07 <ryan-summers[m]> Hmm... Becoming extremely suspicious. I have a USB device that's failing enumeration on Windows, so I'm injecting debug logging into usb-device, and after adding enough logging, suddenly enumeration passed

12:29 <JamesMunns[m]> <ryan-summers[m]> "Hmm... Becoming extremely..." <- What would embedded development be without a little "oops timing related bugs"?

12:41 <ryan-summers[m]> I just loathe debugging USB interfaces.... None of the tools work that well :(

13:36 <ryan-summers[m]> Huh, got it. There's a bug in usb-device where it basically forgets that it just sent an EP0-IN packet, so when it gets the EP0-IN complete status, it throws an internal error. Surprised this hasn't hit more people (I think it probably has, but eh)

13:53 <ryan-summers[m]> For anyone interested: https://github.com/rust-embedded-community/usb-device/pull/129

14:00 <TomB[m]> <ryan-summers[m]> "Hmm... Becoming extremely..." <- I think mciantyre hit that with the teensy or something like it a bit back

14:01 <ryan-summers[m]> Yeah I think a lot of devices hit it quite often, but operating systems have retry mechanisms to work around it

14:01 <ryan-summers[m]> At least I saw booster hitting it with the exact same code, but managed to get through the second or third time around

14:04 <ryan-summers[m]> As an aside, I should probably re-release usb-device since there's some breaking changes there. It's been a while and might take some time to flow through the ecosystem (i.e. synopsys-usb-otg, various HALs, etc.)

14:04 <ryan-summers[m]> Could also just patch this into a v0.2.10 release, but don't want to abandon the hard work by others on the other changes

14:22 <dav1d> Any idea why the wifi doesnt work on my esp-32-s3 devkit when I am connected via the USB port (cargo run ...) but it does work when I am connected via the UART?

14:24 <dav1d> Hangs in WifiController#start

14:53 <ryan-summers[m]> Does WFI/WFE affect RTT logging?

14:56 <ryan-summers[m]> I'm seeing logging/processing within usb-device get a little weird when WFE/WFI is used, and not entirely certain why that would be the case

14:58 <ryan-summers[m]> Ah indeed, there is a restriction on the H7 chips where you shouldn't use the sleep state if USB isn't in suspend

15:00 <dav1d> Seems to be related to the phy-enable-usb feature, RTFM helps

15:03 <ryan-summers[m]> Yeah that fixed it. Kind of a strange requirement on WFI, but I get it

15:03 <ryan-summers[m]> The synopsys USB peripheral feels really.... Kind of shoved onto the stm32 silicon. It doesn't quite behave like everything else

15:29 <adamgreig[m]> It really does. The memory interface especially is odd

15:58 <TomB[m]> <ryan-summers[m]> "The synopsys USB peripheral..." <- synopsys blocks are like that

16:12 <korken89[m]> Does anyone know of a tool to create these kind of diagrams that's not manually using inkscape? :)

16:12 <korken89[m]> https://intronetworks.cs.luc.edu/1/html/_images/tcp_ladder_plain.png

16:12 <ryan-summers[m]> Github Markdown mermaid supports sequence diagrams and it's pretty nice

16:12 <ryan-summers[m]> https://mermaid.js.org/syntax/sequenceDiagram.html

16:13 <dav1d> mermaid, draw.io

16:13 <dav1d> plantuml

16:14 <korken89[m]> Nice! Thanks for the tips!

16:14 <ryan-summers[m]> Being able to draw that stuff in markdown is a game changer for me personally. Can keep it all version controlled nicely

16:16 <korken89[m]> Yeah, that's the main point I was thinking about as well :)

17:44 <d3zd3z[m]> Any tips on using #[test] in my embedded project? I was wondering if I need to move major functionality into its own crate so that cargo test will build and test it on my host, where I have std and test available.

17:48 <TomB[m]> d3zd3z[m]: https://ferrous-systems.com/blog/cargo-test-with-panic-probe/

17:49 <TomB[m]> not sure if still relevant, but do remember reading this nice post awhile ago

17:50 <d3zd3z[m]> So that is useful for on-target testing, but I'd actually like to do some testing just on the host. So, perhaps a separate crate for it would be good.

17:52 <TomB[m]> Ah yeah sorry misread

17:53 <TomB[m]> You might be able to simply set the target for cargo test? perhaps could be done with an alias

17:54 <TomB[m]> https://stackoverflow.com/questions/52802835/how-can-i-specify-a-different-default-target-for-building-and-testing-in-the-car

17:54 <TomB[m]> cargo test_host could be an alias then

17:56 <TomB[m]> but right if you want to run some set of tests on a host, and some other set (perhaps overlapping) on the target that would probably require some additional filtering setup

17:58 <TomB[m]> could probably be done with features, #[cfg(feature=target_test)] and enabling the feature by default for cargo test, disabling it for cargo test_host or something

17:58 <TomB[m]> I'm sure some fun things could be done

17:59 <TomB[m]> would make a nice write up if you figure it out I'm sure

18:00 <dngrsspookyvisio> you can make a workspace

18:01 <dngrsspookyvisio> might be worth looking at how defmt does it, there's a decent amount of tests ran on qemu for example

18:08 <TomB[m]> * <del>could probably be done with features, #\[cfg(feature=target\_test)\] and enabling the feature by default for cargo test, disabling it for cargo test\_host or something</del>

18:10 <TomB[m]> * <del>could probably be done with features, #\[cfg(feature=target\_test)\] and enabling the feature by default for cargo test, disabling it for cargo test\_host or something</del> probably better ways than a feature, e.g. test filters, target_feature/instruction_set attributes, etc

18:21 <gauteh[m]> I tend to do it like this: #![cfg_attr(not(test), no_std)] (https://github.com/gauteh/sfy/blob/main/sfy-buoy/src/lib.rs#L7)

18:21 <gauteh[m]> Even easier if you keep the host testable code in a lib crate. Otherwise you have to feature gate your main fn and entry point usually

21:29 <d3zd3z[m]> I ended up splitting stuff off into separate crate(s). I'm not using a workspace, because now I can have a .cargo/config.toml for the build project for the target, and then the rest are easy to cargo test on the host.