Rust ESP32 Community Meeting 2025-07-03

[MabezDev]

The meeting is scheduled for 3rd of July 2025 - 5 pm CET/GMT+1.

Join the meeting here

[Frostie314159]

I would like to discuss, if it would be possible to expose the metadata from esp-metadata, somewhat publicly, so that out of tree drivers like esp-wifi, esp-ieee802154, esp-wifi-hal can rely on them.

To be totally transparent, my interest in this comes from developing esp-wifi-hal, since the Wi-Fi hardware varies between chips in terms of capabilities. Currently, we have a build script, that injects some metadata into cfg's, and other parameters are in constants, that also have cfg's around them. It would therefore be nicer to have one source of truth about the chip, which ideally would be esp-metadata.

[MabezDev]

It's only generated at build time, is that a big problem?

[Frostie314159]

Not really. It just felt odd to do it twice, but realistically if it's the same version of esp-metadata the overhead will probably be hardly noticeable.

[MabezDev]

I think it should be fine, @bugadani will be investigating reducing the build time of the metadata crate soon too, so that that'll help.

[bugadani]

I've thought about pre-generating code from metadata. I considered it for esp-hal only, but it wouldn't be unreasonable to turn this into a crate. The problem is that it's MUCH more convenient currently to work on esp-metadata if we regenerate everything in build time. Maybe that could be done in a separate crate, too.

So, instead of esp-metadata generating code for esp-hal, how about esp-metadata generated code for esp-metadata-gen, and esp-metadata-gen exposed the heaps of macros that we currently generate? Would that be a good first step?

[Frostie314159]

Yeah, that sounds pretty good.