Open-CMSIS-Pack Technical Meeting 2022-05-17


Jaeden Amero


Evgueni Driouk

Bill Fletcher

Vincent GRENET

Reinhard Keil

Joachim Krech

Charles Oliveira

Anca Oprea

Holt Sun

Luís Tonicha

Cristian Tepus

Daniel Brondani

Marc Goodner

Sourabh Mehta





Meeting Notes

Decision Committee Charter & Stages of Change Process

Bill’s slides

Request for Review



#335 ( was #171 )

HS: Want to provide out of the box debugging experience for customers. Need to pre-configure debug. In existing CMSIS mechanism there is an extension point “environment” and maybe we can produce debug information. We need to find a place to put the configuration for examples where the default configuration isn’t the right one.

TB: csolution can have multiple configuration including a debug configuration.

JK: Can link debug configuration to context.

VG: There are some insertion points available in yaml now. Let’s use those and then see if we need to extend the specification.

JK: Need more inputs/discussion on this.


HS: Have comments in the issue. We directly provide information on the dependencies in/between the examples. Out IDE will automatically do some loads. Want to retain this feature when we move to Open-CMSIS-Pack.

HS: Not sure if a solution yaml can contain (only) 2 projects. If we have 4-5 pairs of projects it’s hard for the IDE to follow.

JK: Have the build type and target type. Doesn’t need to be a pair. Can have projects dependent on build and target type. These are the dependent projects. Can we have an example?

HS: In csolution docs I don’t see a practical way to figure out the relationship between 2 targets. In some cases one target depends on another target.

(multicore usecase example)

JK: Will take an action to go through the example and then NXP can feed back why existing mechanism isn’t sufficient.


RK: Generic example projects are based on a unified layer. It’s a phrase invented for projects that use a common interface.

Other Updates

cpackget 0.5.0 available now


Meeting Recording