00:26 <re_irc> < (@explodingwaffle101:matrix.org)> was just catching up and thinking about provided helper methods as a solution

00:35 <re_irc> < (@762spr:matrix.org)> Is there a good SD/SPI flash crate out there? I don't need a ton of bells and whistles but will be using it for a simple HTTP server over WiFi so need to be able to provide responses to GET requests as well as reading and writing system settings files.

00:35 <re_irc> I am normally a roll your own kind of guy but this is a bit intimidating given the lack of examples out there. Everything embedded just says "uSe tHiS aRdUiNo LiBrArY" so I guess I am stuck with the same thing except rust 😅

00:36 <re_irc> < (@762spr:matrix.org)> If it matters the target is STM32 although I am playing with a pi pico/embassy currently out of convienience while setting up the WiFi module.

00:37 <re_irc> < (@dirbaio:matrix.org)> for stm32, embassy-stm32 has sdmmc support

00:37 <re_irc> < (@dirbaio:matrix.org)> using the sdmmc peripheral though, not spi

00:40 <re_irc> < (@dirbaio:matrix.org)> if you want to use spi, embedded-sdmmc has an impl using embedded-hal spi

00:40 <re_irc> < (@762spr:matrix.org)> Oh I didnt realize there was a peripheral for that! I will check and see if my chip supports it, that may greatly simplify things

00:40 <re_irc> < (@dirbaio:matrix.org)> embassy-stm32 uses an async fork of embedded-sdmmc available here https://github.com/thalesfragoso/embedded-sdmmc-rs/tree/async

00:43 <re_irc> < (@762spr:matrix.org)> I just assumed doing it over spi would be simpler but this is probably the way to go. I havent looked into it much I just got the server running and serving a baked in hallo world HTML page last night. After the initial excitement and high fiveing myself I realized the next step would be a little more complicated haha

00:43 <re_irc> < (@dirbaio:matrix.org)> the spi impl in that fork is not updated though (it predates embedded-hal-async)

00:44 <re_irc> < (@762spr:matrix.org)> If I can find an unused nucleo board I will probably do the stm32 peripheral approach. I was just running the Pi because I had a couple handy and wanted to do a shakedown of my "pi oven" programmer

00:44 <re_irc> < (@dirbaio:matrix.org)> there's an example of stm32 sdmmc here https://github.com/embassy-rs/embassy/blob/master/examples/stm32f4/src/bin/sdmmc.rs

00:44 <re_irc> though it just initializes the card, doesn't actually do any fat32 things

00:46 <re_irc> < (@762spr:matrix.org)> Well that is a great starting point anyway. I do need to do some reading into the file structures and how everything works under the hood. I saw one series on YouTube on it and it seemed a bit complicated so I figured I would ask here

00:47 <re_irc> < (@762spr:matrix.org)> I tend to find myself in over my head a lot with this stuff but after much struggle and many dumb questions I usually find my way to the surface 😂

04:17 <re_irc> <henrik_alser> : I have an async SPI version here, a bit outdated though but should be an easy update https://github.com/kalkyl/sdmmc-embassy

04:25 <re_irc> < (@762spr:matrix.org)> henrik_alser: thanks I will check it out!

04:26 <re_irc> <James Zow> I want to ask about PWM. I see https://github.com/rust-embedded/embedded-hal/pull/430 Is there an upper limit for the maximum power ratio setting because each device is different

04:27 <re_irc> <henrik_alser> : Ping me if you have questions :)

04:28 <re_irc> < (@762spr:matrix.org)> Thanks I appreciate it!

04:32 <re_irc> < (@grantm11235:matrix.org)> James Zow: from the PR:

04:32 <re_irc> > "duty" is the duty cycle. Valid values span the entire "u16" range:

04:32 <re_irc> > - "duty = 0" is considered 0% duty, which makes the pin permanently low.

04:32 <re_irc> > - "duty = u16::MAX" is considered 100% duty, which makes the pin permanently high.

04:32 <re_irc> > Implementations must scale the duty value linearly to the range required by the hardware.

04:32 <re_irc> < (@mvirkkunen:matrix.org)> James Zow: It's a ratio so the maximum limit would be 1 (or 65535)

04:33 <re_irc> < (@mvirkkunen:matrix.org)> * 100%

04:34 <re_irc> <James Zow> 65535, Thanks

05:26 <re_irc> < (@burrbull:matrix.org)> : Could you form it as alternate PR?

06:06 <re_irc> < (@thalesfragoso:matrix.org)> : Heh, does it ? I only hacked that code to test my SD implementation on the H7 (or was it on the F4?)

07:50 <re_irc> < (@grantm11235:matrix.org)> The main thing that I don't like about my PWM proposal is that in order to support a max duty cycle value of 2^16, the values need to be u32, which means that "set_fraction" needs to do 64 bit math

10:37 <re_irc> < (@chrysn:matrix.org)> As I've just been on another step of the eternal "CBOR serializers all have their Write trait and none implements what I need to write into" whack-a-mole: Is embedded-io something we could converge on to make the whack-a-mole O(n+m) rather than O(n*m)?

10:38 <re_irc> < (@chrysn:matrix.org)> (And if so, why doesn't it implement Write for heapless::Vec? ;-) )

11:17 <re_irc> < (@dirbaio:matrix.org)> : well, you PR'd it... so it's still there :D

14:08 <re_irc> < (@thalesfragoso:matrix.org)> : Fair enough

14:08 <re_irc> < (@dirbaio:matrix.org)> would be cool to have something upstream

14:09 <re_irc> < (@dirbaio:matrix.org)> +async

14:09 <re_irc> < (@dirbaio:matrix.org)> perhaps rust-fatfs instead, the implementation seems more mature

14:09 <re_irc> < (@thalesfragoso:matrix.org)> : Agreed, but not sure how to tackle that. There's an issue for splitting the FAT code from IO, that would help

14:10 <re_irc> < (@mabez:matrix.org)> : I can vouch for rust-fatfs

14:20 <wes_> Lumpio- sorry to bother you again, but i'm already stuck once more. i have a device up and running. control in/out is working well. i've implemented the usbd_serial::CdcAcmClass within my TestClass, and that's working well. i feel like i'm stuck on the easy part...

14:21 <wes_> i can't quite figure out bulk in and out. i see how TestClass::poll() handles bulk out - puts the data in TestClass::bulk_buf and sets TestClass::len - but i don't see an obvious way to access this data.

14:23 <wes_> i've manually pulled data from my_test_class.bulk_buf, but i don't see how i could maintain my_test_class.len correctly, and ensure the bulk_buf doesn't get mangled... anyways, like i said, feels like i'm stuck on the easy part (because i don't see TestClass::get_bulk_in() or something obvious)

14:24 <wes_> any hint or help you could share to get me back on track would be greatly appreciated

14:26 <wes_> i also dug through the tests you wrote in usb-device-0.2.9/tests/test_class_host/ . really good stuff! i'm going to ditch my host-side python scripts and try to implement a host in rust based on what you've done there.

14:27 <wes_> (i'm only blasting the entire channel with my rambling questions on the small chance it helps someone else)

14:32 <re_irc> <FredrikLL> Are there any guides on how to create an Hal (embedded-hal) for a new device? I see that there is a reference implementation but would love some more material if anyone knows of anything!

14:40 <re_irc> < (@k900:0upti.me)> FredrikLL: What sort of hardware?

14:41 <re_irc> < (@k900:0upti.me)> If it's an architecture that Rust/LLVM already support, feed it to svd2rust and then write the HAL on top

14:44 <re_irc> <henrik_alser> FredrikLL: I believe made some youtube video of the process a couple years ago, i’d imagine most of it would still apply

14:45 <re_irc> <FredrikLL> It’s a cortex-m33. I have gotten the svd files and used them with svd2rust which worked reasonably well. But the files are incomplete so I am working on parsing and generating a complete version. Next up is writing the Hal.

14:46 <re_irc> < (@marmrt:matrix.org)> The most important part, imo, is the clock and pin configuration as those will be used by pretty much everyone and by pretty much every other peripheral

14:56 <re_irc> <FredrikLL> henrik_alser: Do you have a link or the name of the video? James has a fair few videos on yt

15:01 <re_irc> < (@jamesmunns:beeper.com)> https://youtube.com/watch?v=pj2Rk-ftcWA

15:18 <re_irc> < (@mvirkkunen:matrix.org)> wes_: That's, in the end, up to your application. usb-device provides you with packets, it's up to you what you do with them. The SerialPort class for example stuff them in a FIFO buffer and reads data from there later. Or you could handle and parse every packet as they come in without storing them - depends on what your application wants to do with USB!

15:23 <re_irc> < (@mvirkkunen:matrix.org)> * stuffs them in a FIFO buffer and lets the user read

15:46 <wes_> ah! so i alter my_test_class::poll() to handle all data (bulk, interrupt) as needed? okay. got it.

15:46 <wes_> Lumpio-: as always, thanks!

15:47 <re_irc> < (@mvirkkunen:matrix.org)> It's also ok not to have a "poll" function on your class itself at all. There are built-in callbacks such as endpoint_out/endpoint_in_complete you can use to handle more specific events.

15:47 <re_irc> < (@mvirkkunen:matrix.org)> But that's up to your implementation!

15:48 <re_irc> < (@mvirkkunen:matrix.org)> Do remember to read the docs for them though

16:49 <re_irc> < (@henrikssn:matrix.org)> Is there a recommended way for running performance benchmarks on embedded devices?

16:49 <re_irc> < (@henrikssn:matrix.org)> I would be fine with simulator too

16:50 <re_irc> < (@dirbaio:matrix.org)> DWT cyccnt probably

16:52 <re_irc> < (@henrikssn:matrix.org)> Well that's low level :p

16:53 <re_irc> < (@henrikssn:matrix.org)> I was hoping for something similar to "cargo bench"

17:01 <re_irc> < (@dirbaio:matrix.org)> ah...!

17:01 <re_irc> I don't recall seeing something like that for embedded. Maybe defmt-test, and do the CYCCNT thing within a test and print the result...

17:25 <re_irc> <FredrikLL> I have a device that has ‘duplicate’ registers for set, clear and toggle. These are not included in the svd file, I tried adding them and setting them as derived from the standard register. Now when I try to compile it gives me “error[E0659]: x is ambiguous” anyone been in that situation before or have any advice to give?

17:33 <re_irc> <FredrikLL> If I make them derived peripherals instead it seems to work. But that is a bit confusing. It seems that svd2rust adds a list of ‘pub use as’ at the end of the files which causes the issue. Eg ‘pub use cfg as cfg_set’

17:48 <re_irc> <FredrikLL> I also tried adding all registers. This duplicated everything and the svd file ballooned to over 0.5M lines and the Pac took forever to compile!