Jack (working with David Palchak) working on I3C initiator API.
I3C has additional complexity in initiator compared to I2C. Requires global view of all devices on bus and needs that info in advance.
I2C just needs address of device it's talking to. Been a lot of discussion on how to provide global info to I3C initiator.
Comes down to philosophical argument about centralizing hardware info. What's best way to accomplish that in Pigweed so that you're not coupling all hardware that might use I3C?
In Linux it's easy via Devicetree. I3C is first subsystem API that requires global view of otherwise unrelated pieces of hardware.
Possible to use product glue code to hand-carry info that API needs to product (e.g. board.c)? Wasn't scalable for Linux but could work for Pigweed.
General debate is whether each board would needs its own subclass.
Pigweed's HAL layer needs some reconsideration once async stuff lands. Should also consider whether Pigweed wants something like Devicetree.
I3C initiator has 2 roles: accepting registrations and then being the object to communicate with bus devices. David's leaning towards 2 classes for the 2 different roles.
Erik: A model that might work well for async future is to keep every device stateful and they get events when the bus is ready.
Logistics: we need someone to drive this through upstream Pigweed.
pw_emu, a new module for emulator frontends
UniquePtr (and broader discussion of upcoming allocator work?)
Looking for feedback on other allocation use cases. Leave comments through the SEED.
ETA for landing the SEED? Last call this week, wrapped up next week.
SEEDS
Kudzu, electronic badge that Pigweed team made for Maker Faire 2023
Source code is an example of complex Pigweed usage
Brought hardware to Maker Faire in wearable form factor
New docs: Get started with Bazel guide, Facades and backends explainer, landing page for getting started docs