Extend /package/requirements with targets for device, board, and processor depend packs

[ReinhardKeil]

Problem Currently it is impossible to mark a pack device or board specific, except when it contains a <device> or <board> element.

Suggested Solution Extend element \<requirements> with child element <targets> to filter for devices, boards, and processors.

Example:

  <requirements>
    <targets>
      <target Dname="STM32F4*"/>         // content of pack is only used for STM32 devices
      <target Dvendor="NXP"/>            // content of pack is only used devices from NXP
      <target Bname="LPCxpresso14000"/>  // content of pack is only used for the board with name LPCxpresso14000
    </targets>
  </requirements>

The element <target> could allow the following attributes.

Attribute	Description
Dvendor	Specifies the silicon vendor of the device.
Dname	Specifies the name of the device (wildcards possible).
Dcore	Specifies a processor core.
Bvendor	Specifies a board vendor.
Bname	Specifies a board name (wildcards possible).
Brevision	Specifies a board revision.

The element <target> acts as:

• indicator for device or board specific packs used during pack installation.
• extension of <conditions> as the complete content of the pack is only relevant when <target> specification matches.

It should be possible to specify more than one element <target> to indicate that more then one device/board is supported by a pack.

[mdortel-stm]

Hi Reinhard,

My first reaction on your proposal:

• You say "Currently it is impossible to mark a pack device or board specific": my feeling it is not really true for device. We already have the Dname and 'Dvendorattributes on thepackage` node for that purpose. At least, it is the way we understood it on ST side and CubeMX currently relies on that understanding to make filtering on applicable packs for a device.
• We also use requirements to check the condition of usage: but, so far, it remains at a level of "warning" for our tools. What do we expect as a behavior from an end-user point of view?
• If we assume that we should promote your solution and that my assumptions on the package node are true, how do we deal with the coexistence of both information?
• In some ways, should we say that we expect to have a kind of "high-level condition", applicable to all components of the packs?

Maybe the problem statement is the result of a pre-analysis and I don't catch exactly the impacted user flow. Should I maybe watch a record of the weekly session for such clarification?

[ReinhardKeil]

Hi Maxime,

a pack that only contains software components (no <device> or <board> element) cannot be made device or board specific.

The suggestion is to use <requirements> as a filter for choosing software packs. We have discussed if an explicit request to the pack should bypass that filter or not, but on this behavior is not yet decided. The filter would primarily apply to pack installers, web infra structure, etc. to select the right packs for a solution.

To see the problem that we are addressing, open the Pack Installer of MDK v5. It shows many example packs that are device specific as generic packs.

Yes it would be to an extend a "top-level" condition for a pack.

[jkrech]

@ReinhardKeil , I think Maxime is referring to: https://open-cmsis-pack.github.io/Open-CMSIS-Pack-Spec/main/html/pdsc_package_pg.html#element_package

• Dcore
• Dvendor
• Dname*

which is more restricted. I do not think these <package> level attributes are currently used/read by any tools like cpackaget or the RTE Models.

[mdortel-stm]

@jkrech indeed, this is what I was referring to. As mentioned, the Dname attribute from package node is taken into account by STM32CubeMX. It would be interesting to discuss what is the future of this existing mechanism.

[ReinhardKeil]

Thanks for pointing to that. I have overlooked that. So perhaps all we need is to extend it to boards.

[iomint]

Aside mdortel proposal above, I would like also to point to the issue https://github.com/Open-CMSIS-Pack/devtools/issues/1178 "hproject.yml a proposal for hardware project" that I hope we can resume soon by providing examples of hcondition