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

Owned by Bill Fletcher, created
Last updated: Aug 18, 2021 by Joachim Krech
3 min read

Date

Aug 17, 2021

Participants

Maxime Dortel

Leo Farfalle

Bill Fletcher

Ian Fyall

Reinhard Keil

Joachim Krech

Laurent Meunier

Charles Oliveira

David Jurajda

 

Slides

 

Notes

Open-CMSIS-Pack: Tools that will be published

IF: One usecase - vendor tools to configure and generate code and used live to update/generate new code?

RK: This is in the ‘Generators’ section

LM: How does the CMSIS project manager relate to components provided in GitHub?

RK: “cproject” on previous slide

LM: Why YAML files?

RK: Easier to edit than XML files. For the extension are completely open but extensions need to be supported by YAML editors. Without the schema would need to read the documentation.

LM: ctarget vs application project?

RK: Other proposals are welcome. Using ‘target’ in multiple places. Feel free to propose something in the comments space.

CMSIS-Pack Generator Component

IF: Implication is that vendor tools are updated to accomplish the goal or there’s post processing to generate gpdsc?

JK: Somehow need to organise synchronisation of the 2 systems. Would need to be able to fit the files you’ve added/modified to the project are taken into account.

IF: Wonder if that will be limiting to adoption? A lot of vendor tools have been around for a very long time. Wonder if could have a file that specifies a place where vendor tools would deposit arbitrary files to be included in the build.

JK: Could have some trigger point to chain the operation. Would like to know what principle we could establish. Would be interested to see how it could work. rungen could be a script that does additional stuff to make it work. What kind of requirements would such an orchestration have.

RK: Think NXP is not using it. So agree has not got the adoption. See if there’s a better way to get the functionality.

LM: The generator input files would be made available to the rungen?

JK: Yes. Has a metadata reference.

LM: Metadata is build from attributes?

JK: One angle but guess there is more information that needs to be added to the metadata. Need to get to what kind of information is essential to run the rungen. One example is the resource file - the generator would need to know about other projects (or secure/non-secure).

LM: Not clear to me the picture for input files

JK: Need to be selected to contribute to the generator input. If not checked, doesn’t contribute. Should have included that in the example. Would appreciate further comment in Issue #20.

RK: Add a link to the slides in issue #20. Maybe think about a data model and use frame marker so a generic approach to vendor tools. This is how we’ve implemented it and how we think it should move forward.

Wrap Up

DJ: Automatic generation of packet descriptions. Started with include files. Feedback was that there are too many. Made a script able to identify files in PDSC and got these results. Case of FreeRTOS - 98% of files not described. Would like to publish this content and script but still in the process

RK: We don’t clean up FreeRTOS so it’s original FreeRTOS plus metadata to make it a pack. Could reduce the side of this pack radically.

DJ: Would personally prefer explicit description or removal of the content.

LM: Is there a way to specify folders in the pack e.g. for examples that are set aside? Otherwise problematic to fork and contribute if start removing files.

DJ: Dealing with similar problems internally.

JK: The more we get people owning the pack as well as the source component will help. Think this could be a good metric.

Recording