Open-CMSIS-Pack Technical Meeting 2021-08-03

Date

Aug 3, 2021

Attendees

Joe Alderson

Jonatan Antoni

Daniel Brondani

Bill Fletcher

Reinhard Keil

Martin Kojtal

Joachim Krech

Charles Oliveira

David Jurajda

David Noverraz

Petr Hradsky

Slides

Notes

#10 Add fileCategory for source type specific include and header files:

JK: Agreement to go for an extension

RK: Believe we should do it as requested. Combine other tools into 1 include path. Should we allow specific extensions that are effectively vendor specific?

DN: Not moving that way with our tooling at the moment

DJ: Motivation is mapping paths of include paths in user interface. Would prefer to put only necessary include paths.

RK: So only apply include path when needed?

DJ: In MDK are different forms for assembler, and also for C/C++. Customers complained we are presenting unnecessary include paths. Need to be distinguished somehow.

JK: Include c and include cpp - we have a clean separation but need to look at the general includes.

#10 Identify unreferenced header files:

RK: Think we should extend to unreferenced (C) files.

JK: Separate function to check if all files are referenced. Header files are more nasty because you have an include path which is set or not set. Modules are explicit.

DJ: Would also like to mention role of Pack vs component. Would like to have all files referenced by component and Pack serves as a handle(?). Where header files are not referenced by a component, then they would be owned by the pack.

JK: As a side effect of including on header file it includes other headers. Still owned by component.

DJ: Think the file should be explicitly identified with a component. If used in another component should be defined as a dependency (not implicit)

JK: Not necessarily a dependency. They may not both be active.

DJ: See a difference when using atomic components vs Packs.

JK: Think we need to go through an example.

#20 Review Generator concept.

DN: RZONE and AZONE files makes perfect sense and CMSIS Zone is a good way to display. We’re not 100% sure if it makes sense to integrate into the packs. Don’t have a problem with the file formats. Managing the data totally in the IDE.

PH: Currently using our own tool.

RK: One discussion in a previous call was to combine SVD and resource files. Quite complex so hesitant to change at this point.

…

PH: Already had some discussion in the past about generators. Our generators usually serve a large number of components. One generator handles configuration of everything. Can we leverage this concept with this data model?

JK: Could have single generator associated with multiple components, regardless if you click the generator for component A or B. Agree it’s not immediately clear. Is it necessary to reference a generator that lives in another pack?

…

JK: Is this a direction we want to go in?

DN: Agree but not sure if we’re hijacking the Open-CMSIS-Pack discussion

JK: Think we’re in a difficult situation with restricted MVP scope but to move things forward. #6 Project Requirements - includes hardware resource allocation so don’t see it as a distraction.

DJ: Have recognised we are discussing at short and long term (broader and ok to introduce any topic related to SW management)

RK: Think we need to consider this in the long run even if not supported in the first implementation.

#7 & #12

RK - proposal that we work with YAML files for configuration as user friendlier. Do we need to revisit e.g. generating linker scripts?

DJ: Prefer YAML files where there’s manual input/editing required/expected.

Recording

Open