MDK-Packs / CB_Lab4Layer

CMSIS-Build Lab with Layers
4 stars 9 forks source link

File removed from cprj still added in uvprojx #3

Open fred-r opened 3 years ago

fred-r commented 3 years ago

Hi,

I have generated the file: AWS_MQTT_Demo.cprj in : CB_Lab4Layer\build\AWS_MQTT_Demo\32F746GDISCOVERY_ESP8266_WiFi_RTX

Then, I modify this file as indicated below to remove one system file:

<component Cclass="Device" Cgroup="Startup" Cvendor="Keil" layer="Board">
  <file attr="config" category="source" name="Drivers/CMSIS/Device/ST/STM32F7xx/Source/Templates/arm/startup_stm32f746xx.s" version="1.2.2"/>
  <!-- <file attr="config" category="source" name="Drivers/CMSIS/Device/ST/STM32F7xx/Source/Templates/system_stm32f7xx.c" version="1.2.2"/> -->
</component>

Unfortunately, when I open the cprj file with Keil microvision 5.30 I can still see the "system_stm32f7xx.c" file being present.

Indeed, if I check the uvprojx, I can still see this item:

  <file attr="config" category="source" name="Drivers\CMSIS\Device\ST\STM32F7xx\Source\Templates\system_stm32f7xx.c" version="0.0.0">
    <instance index="0">RTE\Device\STM32F746NGHx\system_stm32f7xx.c</instance>
    <component Cclass="Device" Cgroup="Startup" Cvendor="Keil" Cversion="1.2.5" condition="STM32F7 CMSIS" layer="Board"/>
    <package name="STM32F7xx_DFP" schemaVersion="1.6.3" url="http://www.keil.com/pack/" vendor="Keil" version="2.13.0"/>
    <targetInfos>
      <targetInfo name="Target 1"/>
    </targetInfos>
  </file>

This is something I can also reproduce with my own packs and clayer.

Thanks & Regards, Fred

32F746GDISCOVERY_ESP8266_WiFi_RTX.zip

ReinhardKeil commented 3 years ago

Hi Fred, in MDK v5.30 the Import was experimental. Could you please upgrade to MDK v5.32 (the current version).

fred-r commented 3 years ago

Hi Reinhard,

I just upgraded to version 5.32 but I'm still facing the same phenomenon.

Thanks & Regards, Fred

RobertRostohar commented 3 years ago

Hi Fred,

You have removed a configuration file within a component. This is not intended usage.

Once the cprj is opened with uVision the Device::Startup component will be selected from the installed pack and the missing configuration file will get regenerated (default configuration file from the pack).

fred-r commented 3 years ago

Hi Robert,

I understand your point but this is not what I see in the clayer file of "CB_Lab4Layer\layer\Board\32F746GDISCOVERY". If I look at "Board.clayer", I can see the following directive:

<component Cclass="Device" Cgroup="Startup" Cvendor="Keil" layer="Board">
  <file attr="config" category="source" name="Drivers/CMSIS/Device/ST/STM32F7xx/Source/Templates/arm/startup_stm32f746xx.s" version="1.2.2"/>
  <file attr="config" category="source" name="Drivers/CMSIS/Device/ST/STM32F7xx/Source/Templates/system_stm32f7xx.c" version="1.2.2"/>
</component>

So to me it looks like you specify which files from the Startup component you want to add in your project. Why specifying some files if finally the entire component is imported in the project ?

Thanks & Regards, Fred

ReinhardKeil commented 3 years ago

Fred,

Q: Why specifying some files if finally the entire component is imported in the project ? A: In this way you can upgrade to new packs that may have newer versions of the configuration files.

CMSIS-Pack has different types of source files:

Configuration files are stored in the project as they may contain user setup. When you open the project, the IDE checks if the component contains the same versions of the config files (as you may now have an updated pack). If there are new versions, the IDE attempts to merge those config files.

In your case you have manually deleted it - which is a use case that we have NOT envisioned. The question now comes to what is the right behaviour in this case. Right now the IDE copies in the "new" config file with default configuration as this was previously missing in your pack.

Question: why do you want to remove a config file from a component?

Reinhard

fred-r commented 3 years ago

Hi Reinhard,

actually we envision the possibility to "generate" some files.

For the time being, I kept the pack content "as is" for the device part and I was expecting to be able to pick only what I need in my project, knowing that I would generate the missing files.

But maybe I should do so using the "template" concept ? The files in the pack would be tagges as templates and would be overriden by my generated files ?

Thanks & Regards, Fred

ReinhardKeil commented 3 years ago

Hi Fred,

that is actually achieve by using the generator attribute in the \<component> element of the software pack. Documentation is here: https://arm-software.github.io/CMSIS_5/Pack/html/pdsc_generators_pg.html

The generator attribute is not exposed a *.cprj level, but for example this component is generated by CubeMX: https://github.com/MDK-Packs/CB_Lab4Layer/blob/master/layer/Board/B-L475E-IOT01A/Board.clayer#L75

For a component with the generator attribute, you get an initial file set from the pack, but you can add/remove/change files later as needed. I believe this does exactly what you need. You can even add/remove other software components depending on your configuration settings

Moreover the system retains the underlying files of the generator, so that you can start with the configuration and take it to custom hardware. Take a look here https://github.com/MDK-Packs/Documentation/tree/master/Porting_to_Custom_Hardware

Let me know if you have further questions on that.

Reinhard

jkrech commented 3 years ago

Sorry for joining the discussion late. I just want to clarify the purpose of the child elements of elements in the CPRJ format. The sole purpose is for the CMSIS-Pack Runtime Environment to know the origin of configuration files as well as their version:

<file attr="config" category="source" name="Drivers/CMSIS/Device/ST/STM32F7xx/Source/Templates/arm/startup_stm32f746xx.s" version="1.2.2"/> Therefore the only effect of "deleting" this information is that the system will not know anything about this configuration file. In any case the system will search for the component:

<component Cclass="Device" Cgroup="Startup" Cvendor="Keil" layer="Board">

Since it has no Cversion attribute, it will take whatever version it will find in the installed packs. As Reinhard already mentioned, if the system does not find a configuration file in the corresponding RTE subdirectory, the default configuration file specified by the identified component version will copied from the pack into the project.

LMESTM commented 3 years ago

@ReinhardKeil @jkrech I'm following up on the generator topics with @fred-r I understand from the doc that the gpdsc file would be created if it does not exist when generator is called first time, so my guess is that there should be a generator section in a PACK pdsc, or ?
I could find a few examples of generator sections in gpdsc files, is that supposed to be the same section as could be used from the pdsc ? Could you maybe point to an reference example PACK which uses generator ?