-
Notifications
You must be signed in to change notification settings - Fork 15
Open
Description
Let's have a discussion around the future structure of nxp within embassy.
I'll propose and state some things here as a starting base.
Goal:
- Be able to build one unified nxp-hal
- hal shares peripheral driver for compatible peripheral IPs
Current problems:
- No metadata so far
- Each device is generated from individual SVD files
- This means there's no homogenization across devices
Solution:
- SVDs no longer the source of truth for generating pacs, instead pre-extracted yamls using
chiptool extract(-all) - We extract all peripheral IPs & versions from all chips of each family
- Clean them up
- Compare them to sort them into IP families and versions
- Create a mapping from device -> peripheral IP
- build.rs of HAL takes the mapping and sets cfg's for the drivers
- build.rs of HAL generates calls to the pin macros
This should all be very similar to stm32 except that our metadata and sources for peripherals are different.
So what shape should everything have?
- Have an nxp-data repo/crate (something like https://github.com/felipebalbi/nxp-data-gen) that takes metadata from the reference manual attachments
- Expose pin mappings
- Expose which peripherals are available per chip
- Expose DMA mappings
- (meta-)PAC:
- Has a feature flag for every chip
- Has peripheral types for all peripherals we have YAMLs for
- Uses metadata as build dep to generate the right peripheral constants for the selected chip
- Probably needs to be generated by
nxp-dataunless we want to bundle all YAMLs in the pac crate and use chiptool as a build-dep
- HAL:
- Has a feature flag for every chip (forwarded to the PAC)
- Build.rs reads metadata to set cfg's to enable the correct drivers
- Build.rs reads metadata and generates pin and dma macro calls
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels