Date
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.
