Open-CMSIS-Pack Technical Meeting 2021-09-07

Date:

Sep 7, 2021

Participants:

Joe Alderson

Jonatan Antoni

Daniel Brondani

Maxime Dortel

Bill Fletcher

Graham Hammond

Reinhard Keil

Joachim Krech

Laurent Meunier

David Jurajda

Pascale Mondoloni

Petr Hradsky

Slides:

Notes:

Support of Component Features in PACK description

LM: (gap analysis) list is a good summary

JK: Reinhard wanted to provide more detail without stating the solution. Look at different challenges separately and then put them together and look for overlaps.

LM: If we want to get into more details - number #10 issue is a good summary. I answered in issue #10 but will things happen in parallel in the same issue or do we create separate issues?

JK: If we break up things need to links them back - can’t do it hierarchically in GitHub unfortunately

LM: Can put the links in the description.

LM: Understood that ‘environment’ was already a type. What made you change?

JK: ‘environment’ was a pname very specific to the device section

LM: If we want a file to be renamed to a new name … just looking for ideas. Wonder if an extended list of attributes would be enough or wanted to attach specific information to a file. Understand why you want to avoid wider use of extensions. We want to be able to create packs that would meet the standard against a hard deadline to include our features.

JK: Have a section where you can do whatever you want and make sure the standard is not affected.

LM: Hard to tell as don’t have a concrete case today.

RK: Have you considered the proposal from NXP to extend the #include filetypes (distinguish C and C++)?The complexity is to keep the compatibility.

JK: Not in this draft.

RK: Main thing is to make sure that we’ve captured all the gaps.

cpackget - contributors/collaborators wanted

LM: looks like a good topic to start collaboration

AOB

DJ: Separation of component identification from classification. Would it be possible to make a backward compatible change? My feeling is it seems to be quite counterintuitive (example of Cclass representing two different levels of abstraction - interfaces vs middleware). Is it better to create two different classifications.

Other frameworks are defining their own APIs. If we want to create a successful software manager should support alternative API sets. For example might want to integrate Zephyr in a pack

JK: Could do it under e.g. Cclass Zephyr.

DJ: Could be ‘framework’ and ‘class’ on a lower level.

JK: Sounds like an interesting idea to talk about

RK: RTOS is not standardised - but “CMSIS RTOS” is standardised. FreeRTOS and Micrium are different APIs but can’t use both in an application.

JK: Maybe “middleware class” and “API class” would be more descriptive?

RK: Have both native FreeRTOS API or CMSIS FreeRTOS API in our pack.

JK: CMSIS is a class and RTOS is a class but they seem to have a different scope for meaning.

RK: User could have own naming conventions but what would the user benefit?

MD: Believe it’s disturbing that the same information is expected to be found at different places depending on the components (cf USB). Descriptor should be consistent.

RK: So suggest to add a keyword list?

MD: Yes - dissociate the ID from the classification - but appreciate this is breaking things

RK: Think we need a clear description of the problem we want to solve and a proposal. Don’t understand there’s a problem to call USB drivers vs the USB middleware implementation.

LM: The middleware is only implicit. It isn’t stated anywhere.

RK: Should we work on the taxonomy?

LM: Should be stated in the standard.

RK: think we need an alternative way to identify components or a keywords list. Should we go from the user interface

DJ: Believe it’s more natural to start with the data. The user interface is also being defined in the command line tool but some things are issues in the runtime environment.

JK: Will create an issue for this

Recording:

Open