11:43 <jedugsem[m]> are there common problems with async embassy spi device. Using the Spi from embassy in async works but when transfered though a spi device it hangs

11:44 <jedugsem[m]> Trying to communicate with a w25q nor flash on stm411 blackpill

11:48 <cbjamo[m]> Were you pulling cs low, then doing a bunch of ops, then raising cs?

11:50 <cbjamo[m]> Because to do that with a SpiDevice you need to collect them up into one transaction. Otherwise your cs won't be held low for the whole command.

13:58 <jedugsem[m]> Yes im doing transfer in place and in the implementation cs gets pulled low before and high after transaction

16:13 <diondokter[m]> https://blog.rust-lang.org/2024/09/05/Rust-1.81.0.html

16:13 <diondokter[m]> It's happening!

16:28 <swedishhat[m]> Hey folks. I'm building a fairly simple PCB based on the rp2040 and I was interested in programming it with Rust. would it make sense to start with something like Embassy, or should I stay framework-free until the project gets more sophisticated?

16:34 <JamesMunns[m]> I'd highly suggest using either embassy-rp or rp-hal, definitely embassy-rp if you think you'll be interested in trying out async. By using an existing hal it just means that you won't need to write your own drivers from scratch :)

16:37 <JamesMunns[m]> Both embassy or something like rtic will help a ton with things like interrupts, scheduling, and concurrency. It's possible to do yourself, just generally not pleasant until you're comfortable enough with embedded Rust to write something that better matches what you want (and often not necessary at all!)

16:46 <Ralph[m]> <diondokter[m]> "image.png" <- nice!

16:46 <Ralph[m]> are there any plans to implement & make use of `core::error::Error` in `embedded-hal` & the wider embedded rust ecosystem?

16:52 <dirbaio[m]> it's a trait, not a type.

16:52 <dirbaio[m]> HALs are free to implement that trait for their error types with no changes in embedded-hal

16:54 <dirbaio[m]> We can't make embedded-hal require errors to implement the trait (like it requires Debug today), that'd be a breaking change

16:54 <Ralph[m]> it could e.g. be required here:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/yBTtTLGWePayFctPUEGNPjlc>)

16:55 <dirbaio[m]> also i'm not sure what that'd gain us. we'd get access to source() but I imagine that's not going to be popular for embedded anyway due to the bloat of dyn

16:56 <Ralph[m]> and i'm not sure if it'd make sense to implement `core:error:Error` for things which currently implement the custom `Error` from e-h, e.g. here:

16:56 <Ralph[m]> https://github.com/rust-embedded/embedded-hal/blob/master/embedded-hal/src/digital.rs#L32-L42

16:56 <Ralph[m]> that'd allow usage with `dyn core::error::Error` in consumer code (that's the main/only benefit i currently see)

18:14 <nerwalt[m]> is it possible to make embedded-hal-bus::i2c async friendly. at present, it requires embedded-hal compatible devices, so blocking devices

18:16 <JamesMunns[m]> You can check out embassy-embedded-hal, that's the shared bus I usually use in async: https://docs.rs/embassy-embedded-hal/latest/embassy_embedded_hal/shared_bus/asynch/index.html

19:42 <JamesMunns[m]> Survey got plugged in Interrupt's newsletter: https://interrupt.memfault.com/blog/august-roundup

19:50 <dirbaio[m]> awww you're their friend :D

20:25 <JamesMunns[m]> I've known them since before they started interrupt, we met up to talk about "how not to do firmware bad" and talked a lot about doing more embedded teaching stuff

20:26 <JamesMunns[m]> Them: some of the founders and some early engineering folks

20:32 <PhilMarkgraf[m]> Is there an existing library function for converting a byte array into a hexadecimal heapless::String? Something like std::fmt::LowerHex...

20:32 <PhilMarkgraf[m]> Yes, this is easy enough to implement, so no worries if not.

20:42 <JamesMunns[m]> Heapless string implements core::fmt::Write, which is usually what I do.

20:52 <danielb[m]> heapless also implements ufmt-write which might be a bit slimmer

20:52 <danielb[m]> though admittedly I'm not sure if that changed in this decade 😅

21:07 <JamesMunns[m]> yeah, that's a good call

21:08 <JamesMunns[m]> I spend too much time on the rp2040 and not near the limits :p

21:23 <i509vcb[m]> I am currently playing with the mspm0 stuff in Rust and that stuff is definitely near the limits

21:23 <i509vcb[m]> The lowest end part is 1k RAM closely followed by 4k

21:25 <JamesMunns[m]> yeah, it works pretty good (with some care) on stm32g0, 8k ram + 16-64k flash

21:25 <JamesMunns[m]> 4k would be fine ish depending what you're doing, 1k would be impressive :D

21:26 <i509vcb[m]> I will probably be using the higher RAM parts but the 1k part I am definitely interested in seeing if I can get embassy running on it when I get further along

21:27 <i509vcb[m]> These are dirt cheap at least even at distributors

21:27 <vollbrecht[m]> atmega328pb also only has 2k sram / 32kflash, and a simple executor driven by a timer is definitely possible :D

21:29 <JamesMunns[m]> > Optimized low-power modes... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/uZRLzxEVFtaRGyvFBXdHDYmK>)

21:29 <JamesMunns[m]> yeah I guess that makes sense :D

21:30 <i509vcb[m]> Also the mspm0 is slowly approaching the st 1000+ model thing

21:30 <i509vcb[m]> I think it's sub 100 currently

21:31 <i509vcb[m]> But I am taking inspiration from stm32-metapac somewhat

21:31 <JamesMunns[m]> i509vcb[m]: how low for the low end ones? You can get stm32g0s for like sub-50 cents each in singles at LCSC/JLC

21:32 <JamesMunns[m]> not sure they're quite as low power tho

21:32 <i509vcb[m]> Uhh I think the tiny 8 pin ones are sub 50 cent or around there

22:24 <i509vcb[m]> <JamesMunns[m]> "how low for the low end ones..." <- I had time to check, they claim 20c/1ku

22:26 <i509vcb[m]> 73c/1ku on the big 80-pin one with CAN