00:00 <re_irc> <harcrow> Hi Everyone. I'm a hardware person trying to keep up with the embedded FW world. I've been trying to work with and understand the stm32f4xx_hal, and am struggling to understand how some of the type alias syntax is derived. In an example setting up I2C w/ DMA -- ```pub type I2c1Handle = I2CMasterDma<

00:00 <re_irc> I2C1, // Instance of I2C

00:00 <re_irc> (PB8<AF4<OpenDrain>>, PB9<AF4<OpenDrain>>), // Pins

00:00 <re_irc> ...

00:00 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/X6iPUzpN4XyfVKbTJa1TwyDuomIdofc1 (11 lines)

00:02 <re_irc> <harcrow> Hi Everyone. I'm a hardware person trying to keep up with the embedded FW world. I've been trying to work with and understand the stm32f4xx_hal, and am struggling to understand how some of the type alias syntax is derived. In an example setting up I2C w/ DMA --

00:02 <re_irc> pub type I2c1Handle = I2CMasterDma<

00:02 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/dFnzd2ig0CXHySdayUtgeVnt4Q5i5hlC (12 lines)

00:02 <re_irc> (PB8<AF4<OpenDrain>>, PB9<AF4<OpenDrain>>), // Pins

00:02 <re_irc> I2C1, // Instance of I2C

00:59 <re_irc> < (@dkhayes117:matrix.org)> I want to have a "&'a str" in a struct with the "#[derive(Deserialize)]". For example

00:59 <re_irc> struct TempSensor<'a> {

00:59 <re_irc> #[derive(Format, Serialize, Deserialize)]

00:59 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/wO6gNUGjCxJZxcL0qSWV1cpFd7U9zOB9 (17 lines)

00:59 <re_irc> temp: f32,

00:59 <re_irc> < (@dkhayes117:matrix.org)> * there

01:22 <re_irc> < (@jamesmunns:beeper.com)> serde.rs has a good overview of the lifetimes here

01:23 <re_irc> < (@jamesmunns:beeper.com)> In general, it means your deserializer library either doesn't support borrowed data, or doesnt have the right lifetime signature

01:24 <re_irc> < (@jamesmunns:beeper.com)> Specifically https://serde.rs/lifetimes.html ^

01:28 <re_irc> < (@jamesmunns:beeper.com)> If you have a public repo that reproduces it, I can take a quick look

01:28 <re_irc> < (@jamesmunns:beeper.com)> Or if you can link me to the deserializer

01:29 <re_irc> < (@dkhayes117:matrix.org)> I read through that some and understand it on a high level, but not enough to solve my problem.

01:29 <re_irc> I know that deserialize implements the `<'de>` lifetime and it has ensure that <'de> lives longer than <'a>.

01:29 <re_irc> That's all I know so far :).

01:29 <re_irc> https://github.com/dkhayes117/golioth-rs

01:30 <re_irc> < (@jamesmunns:beeper.com)> cloning...

01:31 <re_irc> < (@dkhayes117:matrix.org)> Specific function is `lightdb_state_read` in lib.rs

01:32 <re_irc> < (@jamesmunns:beeper.com)> rust-analyzer loading...

01:32 <re_irc> < (@dkhayes117:matrix.org)> * `lightdb_read_state`

01:34 <re_irc> < (@jamesmunns:beeper.com)> Ah shoot, c libs aren't building

01:35 <re_irc> < (@jamesmunns:beeper.com)> Okay, stubbed that out, it builds for me on main, do you have a commit that fails?

01:36 <re_irc> < (@dkhayes117:matrix.org)> Oh sorry, remove this line from /bin/main.rs

01:36 <re_irc> https://github.com/dkhayes117/golioth-rs/blob/main/src/bin/main.rs#L19

01:37 <re_irc> < (@jamesmunns:beeper.com)> oh

01:37 <re_irc> < (@jamesmunns:beeper.com)> yeah, you are trying to borrow from a packet that gets dropped at the end of that function

01:38 <re_irc> < (@jamesmunns:beeper.com)> so... you can't do that.

01:38 <re_irc> < (@dkhayes117:matrix.org)> Oh, I see what you are saying.

01:38 <re_irc> < (@jamesmunns:beeper.com)> You could used an owned type, like an "alloc::String" or "heapless::String", but you can't return data that borrows from a temporary that is dropped.

01:40 <re_irc> < (@dkhayes117:matrix.org)> I had it stuck in my head that it was the struct I created in main is what was being deserialized, but that's totally wrong.

01:41 <re_irc> < (@jamesmunns:beeper.com)> it's more immediately complaining that your type bound is "<T: DeserializeOwned>", which doesn't support borrowed data

01:41 <re_irc> < (@jamesmunns:beeper.com)> (the serde docs talk about "Deserialize<'de>" vs "DeserializeOwned", which is basically "Deserialize<'static>"

01:42 <re_irc> < (@jamesmunns:beeper.com)> you could loosen the bound, which would allow you to used the borrowed deser'd data inside of that function, but not longer than "response" lives.

01:43 <re_irc> < (@jamesmunns:beeper.com)> (so no returning the "T")

01:43 <re_irc> < (@dkhayes117:matrix.org)> Okay, I understand what's going on now. Thanks for the knowledge!

01:48 <re_irc> < (@jamesmunns:beeper.com)> IF you received the data outside that function, your signature could look something like:

01:48 <re_irc> pub async fn lightdb_read_state<'de, T: Deserialize<'de>>(

01:48 <re_irc> path: &str,

01:48 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/972DJu3XUJC2EZeOlcE5x5etW5eAAzIR (7 lines)

01:48 <re_irc> &mut self,

03:01 <re_irc> < (@halfbit:matrix.org)> This is like the coolest part of rust to me, in C++/C this would a horror show

03:02 <re_irc> < (@halfbit:matrix.org)> * one of

03:02 <re_irc> < (@halfbit:matrix.org)> * parts

03:02 <re_irc> < (@halfbit:matrix.org)> Perfectly plausible to do, but with so many footguns

05:59 <re_irc> < (@firefrommoonlight:matrix.org)> harcrow: It's a quirk of that and some other libs. Intent is to use type checker to enforce pin configs. Results in APis with nested traits.

05:59 <re_irc> < (@firefrommoonlight:matrix.org)> * APIs

05:59 <re_irc> < (@firefrommoonlight:matrix.org)> Tangent: How did you come across that lib?

12:29 <re_irc> < (@drtobbe:matrix.org)> Hi, while implementing a device driver for an external flash, we have seen that there are no traits for QSPI (quad spi) peripherals in embedded-hal. Is there any specific reason that those are missing? Some MCUs support QSPI, some HALs implement it, so it seems natural to also support it in embedded-hal, right?

12:32 <re_irc> < (@ryan-summers:matrix.org)> Embedded-hal traits are only needed when something needs to be cross-compatible (i.e. driver crates agnostic of the HAL). Are QSPI flashes generally agnostic? I'm not so sure

12:45 <re_irc> < (@drtobbe:matrix.org)> I guess they (the flash hardware) should be agnostic of the MCU in use, so the flash driver should be agnostic, too.

12:47 <re_irc> < (@dirbaio:matrix.org)> as an example:

12:48 <re_irc> < (@dirbaio:matrix.org)> the nrf52/nrf53 QSPI peripheral is hardcoded for QSPI flash chips, It can only do the fixed set of standard SPI/QSPI flash read/write/etc commands

12:52 <re_irc> < (@ryan-summers:matrix.org)> Seems like maybe that use of QSPI would go in "embedded-storage"? or similar?

12:52 <re_irc> < (@dirbaio:matrix.org)> but the stm32 QSPI is more like "raw SPI by with 4 lanes", it can tx/rx any arbitrary byte

12:52 <re_irc> < (@ryan-summers:matrix.org)> There's a lot of other QSPI uses - Stabilizer users it as a raw SPI with 4 lanes to talk to a DDS chip

12:53 <re_irc> < (@dirbaio:matrix.org)> so if we did an embedded-hal trait for QSPI which is "raw SPI but with 4 lanes" then the nrf wouldn't be able to implement it

12:53 <re_irc> < (@dirbaio:matrix.org)> and yes, what the nrf qspi can impl is the embedded-storage traits. "embassy-nrf" already does.

13:12 <re_irc> < (@drtobbe:matrix.org)> so there is too little agreement on what qspi controllers do so it would be too arbitrary to declare qspi traits in embedded-hal?

13:12 <re_irc> is there enough agreement on that qspi flash chip interface? then it would actually make sense to just impl the embedded-storage traits on the qspi controllers themselves (in the specific hals). It would just not work if no flash chip is attached then.

13:23 <re_irc> < (@ryan-summers:matrix.org)> In general, there's no real way to know if something is connected to SPI outside of reading a known-non-zero value from the device

13:23 <re_irc> < (@ryan-summers:matrix.org)> I don't think that's in the realm of embedded-rust to take care of

14:00 <re_irc> < (@drtobbe:matrix.org)> sure, i am just wondering how we can write our driver code in a device-independent way. normally, using embedded-hal traits has been the way to go but in this case it seems to be different.

14:00 <re_irc> < (@ryan-summers:matrix.org)> In this case, wouldn't you just use the "embedded-storage" traits instead?

14:02 <re_irc> < (@dirbaio:matrix.org)> I think what is referring is:

14:02 <re_irc> hal impls qspi trait -> hal-agnostic qspi flash driver, impls embedded-storage trait -> user code uses embedded-storage trait

14:17 <re_irc> < (@ryan-summers:matrix.org)> Ah, I see that now. Didn't realize embedded-storage didn't have actual traits to handle the interface to the chip itself

15:58 <re_irc> < (@firefrommoonlight:matrix.org)> For the most common use of memory-mapped, faster-than-SPI flash, I think this belongs on HALs for the host MCU

16:00 <re_irc> < (@firefrommoonlight:matrix.org)> Likely with an initialization function, then the user memory-maps as required using "read_volatile" and "write_volatile" etc. And probably "read", "write", and "erase" functions for supporting non-memory mapped modes

17:22 <re_irc> <Colin Leftwich> HI, I have a friend who made a rust library for a 3642bs 7 segment display. This is his first library and really wanted some feedback. Would anyone be willing to look it over?

17:24 <re_irc> <Colin Leftwich> +he

17:58 <re_irc> < (@jamesmunns:beeper.com)> cr1901: it looks like you could remove all the consts in the infomem crate and just do "static $var_name: [u8; include_bytes!($pim).len()] = *include_bytes!($pim);", which is hilarious to me.

18:01 <re_irc> < (@jamesmunns:beeper.com)> I don't think this actually matters, it's all const whatever, so I won't open a PR unless you want me to, but learning more about "include_bytes!()"'s capabilities is fun.

18:51 <cr1901> uuuuuugh...

18:59 <re_irc> < (@adamgreig:matrix.org)> (will be a couple mins late today, sorry!)

19:06 <re_irc> < (@adamgreig:matrix.org)> ok room , meeting time again! agenda is https://hackmd.io/3v7LPLeFQYK4FyKGS7rZZg, please add anything you'd like to announce or discuss, we'll start in a minute :)

19:10 <re_irc> < (@adamgreig:matrix.org)> let's start! couple of quick release announcements for probe-rs 0.17 and smoltcp 0.9 🎉

19:11 <re_irc> < (@dirbaio:matrix.org)> smoltcp 0.9.0 adds support for DNS and fragmentation, includes a cleaner API and many fixes. Changelog -> https://github.com/smoltcp-rs/smoltcp/blob/master/CHANGELOG.md

19:11 <re_irc> < (@dirbaio:matrix.org)> smoltcp 0.9.0 adds support for DNS and fragmentation, includes a cleaner API and many fixes. Changelog -> https://github.com/smoltcp-rs/smoltcp/blob/master/CHANGELOG.md

19:11 <re_irc> < (@adamgreig:matrix.org)> and fewer managed slices, yay

19:12 <re_irc> < (@adamgreig:matrix.org)> i have been doing but work for the last week 💀 so I don't have a ton of other topics here... still looking for anyone interested in helping maintain the aarch64-cpu crate, please message me if so

19:12 <re_irc> < (@adamgreig:matrix.org)> I think we wrapped up the discussion about Delay taking shared refs nicely last week

19:13 <re_irc> < (@adamgreig:matrix.org)> i have been doing nothing but work for the last week 💀 so I don't have a ton of other topics here... still looking for anyone interested in helping maintain the aarch64-cpu crate, please message me if so

19:13 <re_irc> < (@adamgreig:matrix.org)> does anyone else have anything they'd like to discuss?

19:15 <cr1901> I'm trying to get a new embedded-rust crate released. Does that count :P?

19:15 <re_irc> < (@dirbaio:matrix.org)> nothing from me :o

19:15 <cr1901> (and am looking for ppl to break it/comment/complain)

19:16 <re_irc> < (@therealprof:matrix.org)> Busy with other stuff, too. I've seen some activity on various WG crates and of course the dreaded e-h 1.0 release is still waiting to happen. ;)

19:17 <re_irc> <Slushee> cr1901: Share the repo!

19:19 <cr1901> https://github.com/cr1901/postcard-infomem By using this workspace of crates, you can automate embeddeding metadata about your project, rust compiler, and user-defined data into your binary. The data is serialized w/ jamesmunns postcard crate.

19:19 <cr1901> I'm working on automating the linker script snippet generation and finishing the docs

19:19 <re_irc> < (@jamesmunns:beeper.com)> : I'm out of the loop, do we not have any crates for armv7a now?

19:20 <cr1901> So there will unfortunately be a bit more breakage before release is ready (but will be soon)

19:20 <re_irc> < (@jamesmunns:beeper.com)> (we can discuss this after meeting, just idly wondering)

19:22 <re_irc> < (@adamgreig:matrix.org)> the cortex-a crate was renamed aarch64-cpu

19:22 <re_irc> < (@adamgreig:matrix.org)> I don't know to what extent it originally supported armv7a?

19:23 <re_irc> < (@jamesmunns:beeper.com)> Gotcha, I just noticed the rename after that person was having bss issues

19:24 <re_irc> < (@jamesmunns:beeper.com)> I think? It used to support 32-bit arm, I know the iqlusion imx6ull project was arm7a

19:25 <re_irc> < (@jamesmunns:beeper.com)> Ah, maybe Jorge forked it to get things working: https://github.com/iqlusioninc/usbarmory.rs/tree/develop/firmware/cortex-a

19:26 <cr1901> Where is japaric, btw?

19:26 <cr1901> Haven't seen/heard from them in ages

19:27 <re_irc> <thejpster> Busy at Ferrous

19:33 <re_irc> <thejpster> If we’re quiet tonight, can I plug rust-embedded-community? The GitHub org where crates go to get some love and attention when their owners no longer have time.

19:34 <re_irc> < (@adamgreig:matrix.org)> that sounds nice 😭

19:35 <re_irc> < (@adamgreig:matrix.org)> well, if that's all for this week let's wrap up early, thanks everyone!

19:36 <re_irc> < (@adamgreig:matrix.org)> hopefully next week i won't be wrangling pipes until two minutes before the meeting starts 😥

23:18 <re_irc> < (@drtobbe:matrix.org)> : Exactly! But due to the missing qspi trait, I am not sure anymore how we should implement our driver code in an MCU-agnostic way.

23:18 <re_irc> I guess we will have a look at the nrf qspi peripherals to get a better understanding of how other qspis work (we mostly use stm32). Then, we'll decide. Thanks for the input.

23:18 <re_irc> < (@dirbaio:matrix.org)> fwiw i'm not saying it's a bad idea

23:18 <re_irc> < (@dirbaio:matrix.org)> it doesn't exist because there hasn't been enough demand for it

23:19 <re_irc> < (@dirbaio:matrix.org)> * much

23:19 <re_irc> < (@dirbaio:matrix.org)> we could still have the trait even if nrf can't impl it

23:19 <re_irc> < (@dirbaio:matrix.org)> nrf would do:

23:19 <re_irc> hal impls embedded-storage trait -> user code uses embedded-storage trait