Add tool to automate updating to latest SDK from NXP. #10
Conversation
45f9ebf to
30286f6
Compare
|
Update: I've been trying to use the outputs from this update script and found the reorganising of common drivers into separate tree (each in their own subfolder) would result in a lot more change to projects using this than originally anticipated. As such I've reworked the tool (including rewrite from bash to python) to parse the cmake snippet files in each target chip folder to identify all related common drivers, then symlink them into the target driver dir. As such this should now be more compatible with existing projects, while also reducing maintenance burdon of updating this repo. |
This script grabs the latest release (or tag passed as argument) from NXP's github and updates the contents of existing target chip drivers from the download. It also updates the common drivers from the downloaded SDK and symlinks them as appropriate into the target chip drivers dirs.
30286f6 to
77a4373
Compare
|
Hi @hathach after I first started this MR I saw you'd moved to the official repo for TinyUSB. Thanks for the merge regardless! There have been a few micropython project discussions and currently I think they'll stick with the trimmed down repo considering the significant size difference (~100MB vs ~1.3GB). I don't want to place ongoing maintenance effort on you however so plan to suggest pinning the micropython submodule to a fork of this repo instead. |
This script grabs the latest release (or tag passed as argument) from NXP's github and updates the contents of existing target chip drivers from the download.
It lastly updates the common drivers from the downloaded SDK.
This common drivers folder threw me off for a while. When you download a specific chip pack from MCUXpresso SDK Builder or look an an example application for a particular chip board there's typically a
devices/<chip>/driversfolder that at first glance looks the same as the official sdkdevices/<chip>/driversfolder - except the sdk folder is missing a bunch!It seems they also copy relevant drivers from the
sdk/devicesintosdk/devices/<chip>/driverswhich I found very confusing...and it makes this script a bit harder to write.
I'm leaving those common drivers in a common folder, rather than copying them into the target chip folders, as for one I don't really know which ones are relevant to each chip and secondly duplication is generally a bad thing.
But it does mean a bit of a breaking change to bring in an automatically generated update due to some driver files moving, ie: #9