00:02 <Andy[m]1> Would #nrf-rs:matrix.org be a better place to ask?

08:46 <RobinMueller[m]> Andy: What do you mean exactly with "weird reading"?

09:00 <M9names[m]> This problem was solved in nrf rust

09:00 <M9names[m]> s/nrf/nRF/, s/rust/Rust /

14:50 <TomB[m]> I keep wondering what part to use... I don't know if I have a part in mind that does everything I want for a little tinker project I have going on, I'd like to support usb audio class 2, wifi, ble, and have a reasonable way of connecting to an fpga with maybe good support from rust? I guess I could cobble this together... imxrt/stm h7 + a wifi/ble nxp part or something... but was hoping for an all in one

14:50 <TomB[m]> imxrt is nice as it as the potential to memory map spi or sram which I could use with an fpga

14:51 <diondokter[m]> Hey so, anybody got an idea for what a good solution is here?... (full message at <https://catircservices.org/_irc/v1/media/download/Ab_qr03gb6NPht7ri-6GCq7Y9FedjSp1_PAkRwIdfes4nU3GYFACKlcnNot9QYangxutwGEtIqKAJ87MN-9fEcS_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9xSFZRQnlWeWVCVERQd3NvdG1KQnVkTHI>)

14:51 <TomB[m]> but yeah, the lack of wifi/ble is kind of a bummer

14:51 <diondokter[m]> TomB[m]: Sounds like ESP32 could work

14:51 <TomB[m]> does it do usb hs?

14:51 <JamesMunns[m]> I think maybe the new P4 might?

14:51 <TomB[m]> I was thinking esp32, but usb audio class 2

14:51 <JamesMunns[m]> current ones definitely don't

14:52 <diondokter[m]> Yeah, but P4 doesn

14:52 <diondokter[m]> * P4 doesn't have wifi

14:52 <TomB[m]> I'm concerned too about how performant the riscv core is on there

14:52 <JamesMunns[m]> Yeah, you're probably going to want "big powerful pc with external esp32" probably

14:52 <JamesMunns[m]> embassy has a library for the esp32 "radio over a SPI port" drivers

14:53 <JamesMunns[m]> s/pc/mcu/

14:53 <TomB[m]> well I like the imxrt because its basically a PC without the mmu baggage

14:53 <TomB[m]> * mmu baggage, which is why I was initially going that route, but yeah then I'm left going where do I get wifi/ble from

14:54 <TomB[m]> so maybe my initial plan wasn't bad then? imxrt and a ble/wifi chip, could be esp32 or a dedicated nxp part I guess

14:54 <JamesMunns[m]> Also, you could maybe do QSPI for FPGA interface as well, which might be easier to find chips that support that over parallel SRAM

14:55 <TomB[m]> that is very true, though I'm concerned about my ability to hack up some rtl for qspi peripheral :-D sram looked "easy"-ish

14:55 <TomB[m]> maybe not as bad as I'm thinking...

14:55 <TomB[m]> shift in, decode into address + r/w flag and... go?

14:56 <TomB[m]> the sram route had downsides... so many pins... so many

14:56 <JomerDev[m]> TomB[m]: I've recently found an qspi slave example in verilog that might help there :D

14:56 <TomB[m]> I started doing a board and I got into one of those stare at the screen moments before walking away

14:57 <TomB[m]> JomerDev[m]: that sounds interesting, would love a link

14:58 <diondokter[m]> <diondokter[m]> "Hey so, anybody got an idea..." <- Oh idea!

14:58 <diondokter[m]> The driver could take a type where you can do a `<PoweredOff, PoweredOn: From<&mut PoweredOff> + embedded_io::Read>`

14:58 <diondokter[m]> That's kinda elegant I think

14:59 <JamesMunns[m]> In cases I've needed this, I've had a task that owns the peripheral and parts and stuff, and an async function that runs for as long as it needs to, then returns and drops the HAL object

15:00 <diondokter[m]> JamesMunns[m]: Yeah that's great when you're working with the HAL directly. But this needs to be more abstracted and go through traits

15:00 <JomerDev[m]> TomB[m]: I've forked it to be here: https://github.com/JomerDev/qspis I have a project where I (want to) use an fpga as interface for a parallel bus where the fpga connects to a rp2350's second qspi interface. I want to rewrite it in rhdl (a rust hardware description language) as soon as that is usable

15:01 <TomB[m]> hah, figures someone would make a hdl to look like rust, though vhdl is already fairly rust-y in an ada kind of way I think?

15:01 <JamesMunns[m]> diondokter[m]: yeah, that's fair. I'm not sure if it gets much better than a top level trait that creates the hal instance, but that might get weird with associated traits

15:02 <JomerDev[m]> I haven't used neither vhdl nor verilog so I'm kind of hoping that rhdl is usable soonish so I don't have to fully learn one of them 😅

15:02 <JamesMunns[m]> JamesMunns[m]: ```rust... (full message at <https://catircservices.org/_irc/v1/media/download/ASRF0uq6ohHjUXV9j5_juIpkLDSWbbJzhEhe9IwLjCMeUzCqnEvwJy-PPI6CdP5JFhN_Fg5sZcpI5BZn2ChtAB2_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9TTEJaSVNyR3hodVV6em5MUHJadGFxYmc>)

15:04 <TomB[m]> JomerDev[m]: my experience learning vhdl I wonder if it really matters what language you use, the oddities of describing hardware already are a bit of a mind bender, definitely have to think differently...

15:04 <TomB[m]> * think differently... like a lot of books/tutorials show both verilog and vhdl side by side

15:05 <JomerDev[m]> Fair enough. I've already looked at amaranth, the python hdl, but my python isn't great either and I'd rather learn one thing at a time than two at the same time

15:05 <TomB[m]> creating test though I could see being a thing, maybe some langauges are easier to write those in than others

15:05 <TomB[m]> I'm far from experienced enough to really say!

15:06 <TomB[m]> I like types too much to commit to a python answer to this, my middle aged gray matter can't track all those typeless variables long enough

15:06 <diondokter[m]> JamesMunns[m]: Yeah with a trait things become easy again, but for reasons I'm trying to not have that.

15:06 <diondokter[m]> Thanks for thinking along!

15:11 <TomB[m]> Thanks everyone!

15:12 <JomerDev[m]> <TomB[m]> "I like types too much to..." <- Yeah, thats why I'm hoping to use rust as well, so I get some error checking when compiling

15:56 <realroot[m]1> when addin alarm to watchful should i store it to flash? how?

20:08 <KenMatsui[m]> Hi Rust Embedded WG,... (full message at <https://catircservices.org/_irc/v1/media/download/AR-BO0gt95KsyutuTOrGjL_YZomf8zH06F3Rbm_j09qAW20FgXuvnFiBqEY2c9eBLZL67z5KBUKu1XGPQja-b4W_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9BRWN0Y1dMREZiVExLcWNTRk5jbUpvSHI>)

20:09 <KenMatsui[m]> s/our/my/, s/no_std/no\_std/

20:09 <KenMatsui[m]> s/our/my/, s/no_std/no\_std/, s/our/my/

20:21 <KenMatsui[m]> Hmm, I cannot see my original post, but is this for everyone?

20:43 <realroot[m]1> <KenMatsui[m]> "Hmm, I cannot see my original..." <- i see your previous message

20:44 <KenMatsui[m]> realroot[m]1: Oh then just my problem, thank you.

20:45 <realroot[m]1> you can use /clear-timeline on nheko

20:53 <KenMatsui[m]> Hmm, I'm currently using Element so maybe I cannot?

20:55 <realroot[m]1> maybe there is some setting i do not know

21:00 <GuineaWheek[m]> is there a way to use embassy-stm32 alongside stm32h7xx-hal? i mostly just want to use the async i2c implementation

21:11 <diondokter[m]> <GuineaWheek[m]> "is there a way to use embassy-..." <- There could exist a way to massage everything enough to make it work, but it'd be a mess of hacks. I don't recommend it.

21:11 <diondokter[m]> Either move your firmware to embassy fully, or try to extract the async I2C driver from embassy and use that in you project

21:12 <zeenix[m]> James Munns: Hey, I think I've bumped into a roadblock with varlink and thought maybe you've some ideas. Tl'dr is that subscriptions (a method with multiple replies in varlink) are expected to completely take over a connection until they end. The reason is that it's designed to work mainly over UDS and UDS connections are super cheap so clients are expected to create many connections to the same service. I'm having difficulty

21:12 <zeenix[m]> figuring out how that can work over USB (through embassy-usb) since you've a 1-1 connection there AFAICT (I'm a USB noob so I might be missing something here). I guess I'll have to add another layer (some headers) to make it work. 🤔

21:16 <JamesMunns[m]> Postcard-rpc's host client handles multiplexing using keys, but yeah it seems like you'd want to have multiplexed sessions?

21:17 <JamesMunns[m]> I actually cheat a lot to do smart things on the host side so the MCU side can be very dumb

21:19 <zeenix[m]> Thanks, yeah that makes sense

21:21 <JamesMunns[m]> On the host side (and maybe the client side, it's nostd too), you might enjoy https://docs.rs/maitake-sync/latest/maitake_sync/struct.WaitMap.html, which was exactly for async multiplexing/mailboxing

21:22 <zeenix[m]> Man, I bumped into so many issues with supporting no_std and no_alloc that I'm very close to giving up on that goal 😆

21:22 <JamesMunns[m]> s/client/target/

21:23 <zeenix[m]> JamesMunns[m]: Nice! I've seen this crate before but I forgot about it completely.

21:23 <zeenix[m]> now that I think of it, you mentioned that crate in our last f2f meeting 😆

22:08 <thejpster[m]> <KenMatsui[m]> "Hi Rust Embedded WG,..." <- > <@kenmatsui1:matrix.org> Hi Rust Embedded WG,... (full message at <https://catircservices.org/_irc/v1/media/download/AcZ_baIMUYp-x-UeOz6MAg2fUA-eUfm_TwkaT-o4sK0qoxp6VbiSLqRyB2eyosoDiSk4fV4CvZVBjuDwGg2W9Km_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9nUHJPcWZua3JjdFBIU0JoeVNxc21vUm0>)

22:57 <Ralph[m]> this is an interesting read on security: https://www.cs.auckland.ac.nz/~pgut001/pubs/bollocks.pdf

22:57 <Ralph[m]> it's not embedded specific, but slide 29 contains a nice shout-out to embedded engineers 🙂