Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Update CMSIS pack index json for STM32H7xx family #11709
Manually replaced the existing STM32H7 section and replaced it with the
See related PR; #11707
Pull request type
CMSIS pack index updated for STM32H7xx -family.
@jeromecoutant - for the modifications here - all the information is coming from the cmsis-pack you have supplied to KEIL. Nothing is generated manually and if we start changing things manually, it means we must maintain this file manually forever. Which might or might not be something we really want. @jeromecoutant - in an ideal world, STM would re-generate the STM file, after which I would re-generate the CMSIS-pack to match.
@MarceloSalazar @mark-edgeworth @bulislaw @kjbracey-arm @madchutney - we really need to think what exactly we need and where, as it seems to me have lots of duplicate information. Flash sectors and sizes are in the cmsis-packs (in this PR) AND the target files. Either one of them is a duplicate. We have some similar information also in the compiler linker/scatter files, too.
Also, having one 13 MB JSON file also does not sound like a feasible plan going into the future, we should consider splitting the file into vendor parts (if we truly even need that one .JSON file) - too large files become unmanageable/hard to review.
@jeromecoutant can you rereview? As data in this PR are coming from the pack, can we use these and once pack is fixed, it will be fixed as well.
We would like to have this update on master as soon as possible.
Separation should help here, it will just grow in size day-by-day.
I don't think these are duplicates. Not all drivers provide memory layout in the driver itself like the reference above (they could but there is no way we could get it writing one script without changes per each target family and its SDK). This information is in the cmsis packs - what we use, also what other tools use. This is standardized way to get this data.
Regarding linker scripts - this is one of the things we would like to have - one linker file per toolchain and generate it per target.
Oh yes, the device name for DISCO_H747I was still wrong - it's not
On the other hand, I'd like to get this one merged in pretty soon - the problem is that the