Adding crates that support multiple distinct devices

[oddlama]

Is it possible to add a crate to this database which supports several different devices? I've recently been working on a more generalized driver crate called embedded-devices which abstracts register based devices of any kind. The idea was to make supporting async & non-async simultaneously less cumbersome and share some common abstractions and boilerplate such as SPI/I2C register access codecs. Currently I have 9 devices implemented in the framework (mostly temperature sensors and ADCs), but more are to come.

I love the idea of a search database, since crates.io is not always great for that. Unfortunately I don't understand whether it is intended or even possible to list my crate here (doesn't look like it), since it would require adding multiple addresses, footprints, links etc. per supported device. It seems like it is designed strictly for 1:1 crate to device relationships.

Is this generally something you'd like to have listed in the future?

[tdittr]

Oh interesting approach, I know my colleague @diondokter was working on a similar Register abstraction device-driver.

Could you export your drivers as one crate per device? This would also help with compile times, once you accumulate more drivers, a user would always need to fetch and compile the drivers for all your supported chips. All those drivers could still use the common register abstraction generation as a dependency.

Otherwise you can also just add your crate here and leave out the device specific details, just listing the chip names and maybe dev-boards.

[Sympatron]

Another example would be port-expander. I tried adding it to the registry, but the data structures don't fit very well. The manufacturer for example would be difficult to specify, because they vary and in some cases one chip can be produced by multiple manufacturers.

[Sympatron]

Maybe we could split driver crate from chip specifications in those cases or move most properties of Driver into a Vec.
Something like this:

pub struct Driver {
    /// Version of this driver description TOML schema
    pub manifest_version: semver::Version,
    /// Metadata about the driver
    pub meta: DriverMeta,
    /// Supported chips
    pub chips: Vec<Chip>,
}
pub struct Chip {
    /// Metadata about the chip
    pub meta: ChipMeta,
    /// List of development boards that house this chip
    #[serde(skip_serializing_if = "Vec::is_empty", default)]
    pub dev_boards: Vec<DevBoard>,
    /// Interfaces used by this chip
    #[serde(skip_serializing_if = "Interfaces::is_empty", default)]
    pub interfaces: Interfaces,
    /// Blog articles and similar covering this driver and its usage
    #[serde(skip_serializing_if = "Vec::is_empty", default)]
    pub resources: Vec<Resource>,
}

[tdittr]

That sounds like a good idea. What kept me from doing this is the nested dev-boards in chips, but from a bit more reading it looks like that is not a problem with toml.

Would you want to contribute a PR for this?

[Sympatron]

I could do that when I find the time.

How would you reflect that in the UI? It's probably best if it stays the same if only one chip is specified and only renders differently for multiple chips. Should this be hidden like the dev boards or displayed in a small table?
We could also aggregate the data for now. So that 🛠️ Manufacturer: AnalogDevices could become 🛠️ Manufacturers: AnalogDevices, NXP and so on.

What do you think?

[tdittr]

I think aggregating could be nice, since that would also be what the filter will do.

If you like we can also work on this together or even do a bit of pair programming :)