since this reply actually refers to CMSIS, I moved the discussion on the other thread.
> On 09 Jul 2015, at 05:42, Peter Crosthwaite <peter.crosthwa...@xilinx.com> > wrote: > > On Wed, Jul 8, 2015 at 6:50 PM, Liviu Ionescu <i...@livius.net> wrote: >> >>> ... my interest is to generate the entire MCU description from the CMSIS >>> .pdsc and .svd files, not to define the bitfields manually, so I would >>> model everything to be CMSIS centric. >> > > Are these files text and can I get a pointer to an example? both are in fact xml files. the .pdsc file format is documented at http://www.keil.com/pack/doc/cmsis/Pack/html/_pack_format.html generally there is one pdsc file for each mcu family, for example STM32F1, F2, F3, F4, etc. have separate packs. the .svd file format is documented at http://www.keil.com/pack/doc/cmsis/SVD/html/svd__outline_pg.html generally there is one svd file for a group of devices with identical peripherals, usually called a sub-family. each pdsc device refers to one svd file, with multiple devices referring to one svd. I already have some experience with them, since my Eclipse debug plug-ins use the definitions in the svd files to create memory views for the registers, and the CMSIS PACK plug-ins use the pdsc files for build and documentation. there is more information in these files then simple bitfield definitions, there are interrupts, memory regions, more or less the entire hardware is there. the pdsc files are specific to CMSIS PACKs. they are available from Keil. since I already have a CMSIS Package Manager plug-in for Eclipse, for me it is very easy to check the content of the PDSC files. the svd file is now more or less standard for Cortex-M devices, I guess Keil pushed most manufacturers to publish these files. they are also available in the CMSIS PACKs. --- as strategy, I evaluated several options: - pack the original svd files with qemu, and parse the required one each time a new MCU is instantiated - parse the svd files in a pre-build step, generate a .c file with the tree of definitions, and include it to the build - parse the svd files in a pre-build step and generate a json file with exactly the needed information, and load it at run time when the MCU is instantiated. for the pdsc file I currently evaluated only the option to parse them in the pre-build step, generate a .c file, include it in the build, and at run time create a registry of all available MCUs, similar to the existing registry of types. (I think it makes little sense to create QOM types for each existing MCU, there are probably thousands of them). regards, Liviu
