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
