tdittr
commented
3 weeks ago Yeah, I thought about this, but from what I could tell, for most chips there is only one (active) driver, so there is not a lot of duplication yet.
I agree that having an extra "DevBoardDB" would be cleaner. But we can also extract that later. This is one of the reasons why I want to keep the toml files in a single spot, so if we decide to extract the dev-board info into a separate project we can do it from one place.
Do you know of an existing project in this space? I did not find one last time.
I also brainstormed with some people to have a similar list for board support packages, with nice pin-out diagrams etc, there I found more available info like: https://pico2.pinout.xyz/
currently a single TOML file is used to define (a) crate, (b) the chip (or other device) it is interacting with and (c) dev. boards hosting this chip. however these are not 1:1 relations. thus if there are two crates for the same chip they'd have to duplicate (and keep in sync) the chip + dev. board information.
it might be worth contemplating splitting this into three? maybe as an optional feature, i.e. if there's a clear 1:1 relation it's kept in a single file but the moment a 1:n (or n:m) relation pops up it'd be split into multiple files?
i realise that this might collide with #2 where the idea is to fetch the metadata from crates.io instead of having it specified here. and maybe there's also already a good database out there of chips & dev. boards (that information isn't rust-specific, after all) which could be used instead of re-defining the information here?