Feedback: *.genlayer.yml proposal lacks option to specify dependencies on components

[ReinhardKeil]

The *.gpdsc implementation allows to use conditions to express dependencies to other software components. An equivalent feature is missing in the new Generators proposal

To solve this, a require: node could be added to the components: list as shown below. It allows to request multiple components or a selection of components (when separating by comma as delimiter).

A deny: node could solve the fact that components cannot be combined in a similar manner.

Maybe it also makes sense to add a reference to a connect:, but this could be also achieved by adding a connection: - consumes: node

generator:
  generated-by: STM32CubeMX <command-line>
  for-device: STM32F407IGHx    # only for consistency check
  for-board: NucleoF407        # only for consistency check

  packs:                       # packs that are used by the generator (consistency check, but may supply version information)
    - pack: Keil::STM32F4xx_DFP@2.16.1
    - pack: Keil::STM32F4xx_BSP@2.1.1

  components:               # components that have a genid and are specified in *.cproject.yml / *.clayer.yml must be in this list
                            # but additional components can be supplied by the generator
    - component: Device:STM32Cube HAL:Common
      require:                                           # here both components are required
        - component: CMSIS:CORE               
        - component: Device:Startup 
      deny:                                               # using this component would create an error at csolution convert
        - component: CMSIS:DSP
    - component: Board:LED
      require:
         - component: Driver:GPIO, Virtual-Driver:GPIO    # either Driver:GPIO or Virtual-Driver:GPIO is required
    - component: Device:HAL:UART
      require:
        - connect: CMSIS-Driver-Printf                        # reference to a connect?  not sure if required.

[ReinhardKeil]

@slhultgren does this solve the fundamental issue?

[iomint]

Reinhard, One comment: To my understanding in your example above 'component' is pointing to software components, I think it is interesting to put this in perspective with the proposal from my ST colleagues posted in the issue #182

[ReinhardKeil]

Eric,

So, you would suggest to specify also hardware-part: in addition to component:. Maybe it should be named hw-component: so that all is applicable under components:. Below is a possible example:

generator:
  generated-by: STM32CubeMX <command-line>
  for-device: STM32F407IGHx    # only for consistency check
  for-board: NucleoF407        # only for consistency check

  packs:                       # packs that are used by the generator (consistency check, but may supply version information)
    - pack: Keil::STM32F4xx_DFP@2.16.1
    - pack: Keil::STM32F4xx_BSP@2.1.1

  components:               # components that have a genid and are specified in *.cproject.yml / *.clayer.yml must be in this list
                            # but additional components can be supplied by the generator
    - component: Device:STM32Cube HAL:Common
      require:                                           # here both components are required
        - component: CMSIS:CORE
        - hw-component: ST::USART-COM               
        - component: Device:Startup 
      deny:                                               # using this component would create an error at csolution convert
        - component: CMSIS:DSP
    - component: Board:LED
      require:
         - component: Driver:GPIO, Virtual-Driver:GPIO    # either Driver:GPIO or Virtual-Driver:GPIO is required
    - component: Device:HAL:UART
    - hw-component: ST::I2S               
      require: 
        - component: Driver:I2S

[jkrech]

I recommend to replace the term hw-component with the part since this is the term we are using the Open-CMSIS-Pack Specification. Probably it should be listed under parts: rather than components:

[ReinhardKeil]

Yes there are several options to specify parts. We just should agree on one.

Here the version with part: instead of hw-component.

generator:
  generated-by: STM32CubeMX <command-line>
  for-device: STM32F407IGHx    # only for consistency check
  for-board: NucleoF407        # only for consistency check

  packs:                       # packs that are used by the generator (consistency check, but may supply version information)
    - pack: Keil::STM32F4xx_DFP@2.16.1
    - pack: Keil::STM32F4xx_BSP@2.1.1

  components:               # components that have a genid and are specified in *.cproject.yml / *.clayer.yml must be in this list
                            # but additional components can be supplied by the generator
    - component: Device:STM32Cube HAL:Common
      require:                                           # here both components are required
        - component: CMSIS:CORE
        - part: ST::USART-COM               
        - component: Device:Startup 
      deny:                                               # using this component would create an error at csolution convert
        - component: CMSIS:DSP
    - component: Board:LED
      require:
         - component: Driver:GPIO, Virtual-Driver:GPIO    # either Driver:GPIO or Virtual-Driver:GPIO is required
    - component: Device:HAL:UART
    - part: ST::I2S               
      require: 
        - component: Driver:I2S

Another way might be to extend the name convents for components to specify parts.

generator:
  generated-by: STM32CubeMX <command-line>
  for-device: STM32F407IGHx    # only for consistency check
  for-board: NucleoF407        # only for consistency check

  packs:                       # packs that are used by the generator (consistency check, but may supply version information)
    - pack: Keil::STM32F4xx_DFP@2.16.1
    - pack: Keil::STM32F4xx_BSP@2.1.1

  components:               # components that have a genid and are specified in *.cproject.yml / *.clayer.yml must be in this list
                            # but additional components can be supplied by the generator
    - component: Device:STM32Cube HAL:Common
      require:                                           # here both components are required
        - component: CMSIS:CORE
        - component part{ST::USART-COM}
        - component: Device:Startup 
      deny:                                               # using this component would create an error at csolution convert
        - component: CMSIS:DSP
    - component: Board:LED
      require:
         - component: Driver:GPIO, Virtual-Driver:GPIO    # either Driver:GPIO or Virtual-Driver:GPIO is required
    - component: Device:HAL:UART
    - component: part{ST::I2S}               
      require: 
        - component: Driver:I2S

[jkrech]

@iomint if I am not mistaken https://github.com/Open-CMSIS-Pack/Open-CMSIS-Pack-Spec/issues/182 is requesting to extend the filter condition and not the dependency on another part. In other words a generator could specify multiple components but depending on a <part> being present or not a different component could be selected.

Maybe you could describe a use case scenario here?

[ReinhardKeil]

@iomint to be honest, the use case of parts is somewhat unknown to me. The use case with components could be:

• for require: when the user does not select the component (i.e. CMSIS:CORE) the tool reports an error
• for deny: when the user selects the component (i.e. CMSIS:DSP) the tool reports an error

I did add part as this was a requested. How parts are used in practice is not yet understood, maybe something that can be explained in the TRM today.

[jkrech]

@iomint can we get to the bottom of this? https://github.com/Open-CMSIS-Pack/Open-CMSIS-Pack-Spec/issues/182 specifically talks about a filter condition using Hvendor and Hname. My understanding of a Hardware Project boils down to a list of partId entries representing all the parts that are present in the targeted board. Assuming a future tool-version reads the Hardware Project conditions of software components may get filtered depending on the list of part IDs (Hvendor::Hname). My question is, whether the generator is expected to be aware of the hardware project or whether the generator produces many components regardless of the available parts and that the filter conditions will be required to ensure the right subset is selected for the build?