Open-CMSIS-Pack Technical Meeting 2022-12-13

Participants

Wilfried Chauveau

Erik Mållberg

Joachim Krech

Daniel Brondani

David Jurajda

Luís Tonicha

Evgueni Driouk

Reinhard Keil

Bill Fletcher

Frédéric Ruellé

Eric Finco

Anca Oprea

Dragos Miloiu

Graham Hammond

Will Lord

Cristian

Holt Sun

Slides

Meeting Notes

#450 Local support in cproject.yml for build-type and target-type

HS: Got some suggestions from Joachim for for-type.

RK: for-type is not required

HS: Think it (#450) meets our requirements. It’s very important for multicore projects in RT platforms.

RK: We have agreement that #450 is the framework we’re going to implement. Will rename for-type to for-context to make it clearer. Will work to get it into the specification.

#175/#176 File category mapping

RK: Backward compatibility vs older versions of the tools is the compelling part.

ED: If a file is for both C and C++ how do we specify that?

JK: Would have needed to specify it twice

RK: My opinion - have C-CPP to cover both

#615 Guidance for compiler agnostic projects

#607 ‘defines’ are used by all build tools

HS: Think the yaml file should have the same requirements as #175/#176

RK: Don’t think this is a big deal (to add it).

#618 way to rename build output in cproject/csolution

HS: Think not only about output, but also about output name.

JK: in this proposal you have file-path file extension

CMSIS-Toolbox Version 1.4.0

FR: Just for the naming, I think we should avoid saying "variant" when we say that they are all valid at the same time. With components, variants are exclusive.

JK: alternative

FR: I'm still confused - sometimes it is values, sometimes drivers instances ?

JK: Alternative layers need to be used exclusively like variants...

DB: Could be named ‘capabilities’ if interfaces is too confusing.

EF: Is there a way to describe how components are configured? Interested to know how it can work and how to use it.

RK: Have some demos in preparation.

JK: Still need to get to a taxonomy.