Open-CMSIS-Pack Technical Meeting 2022-01-25

Owned by Bill Fletcher, created
Last updated: Jan 27, 2022 by Jonatan Antoni
5 min read

Date

Jan 25, 2022

Participants

Joe Alderson

Jonatan Antoni

Kyle Dando

Maxime Dortel

Evgueni Driouk

Mark Edgeworth

Vincent GRENET

Graham Hammond

Reinhard Keil

Joachim Krech

Laurent Meunier

Frederic Ruelle

Daniel Brondani

David Jurajda

Marc Goodner

Slides

Notes

Agenda

JK opens the meeting and presents the agenda. No amendments to the agenda are raised.

IDE Development Flow

RK explains Arm’s vision of the IDE Development Flow with Open-CMSIS-Pack tools. This flow is going to be prototyped in Keil Studio Cloud. He suggests getting the flow working in VS Code to get a better feeling.

FR asks whether “project construction” is out of project manager.

RK clarifies that project manager shall address both, creating projects and managing dependencies.

MG points out IntelliSense of VS Code requires configuration files which may be generated by CMake. This might be a chicken-egg issue to be solved.

DB confirms that in Keil Studio CMSIS-Build is used to generate the IntelliSense compilation database.

JAl reports in Keil Studio this issue shows up as well and has been addressed. GH to comment on it once he joins (see below).

VG asks if it is foreseen that the project manager will be executed automatically once a project file is changed.

RK clarifies that project manager is called once the user closes the component selection dialog. Running the project manager is quiet fast hence it should not be an obstacle to run it in the background.

JK adds the term “commit change” might need to be clarified in detail once the implementation goes beyond just editing yaml files.

LM asks at which stage component dependencies will be checked.

RK replies that in the IDE Arm develops the checks are already done in the dialog during component selection. This is prerequisite for a resolve button in the dialog like what we have today in MDK/ArmDS. In addition, the project manager runs dependency checks during project generation.

LM adds question about the flow steps this relates to.

RK refines the check in the dialog relates to step 3. The check during project generation is step 5.

LM tries to correlate target-type selection in step 4 with device/board selection. He gets confused how component dependencies can be checked prior this selection.

RK clarifies that the project manager as implemented today just generates all defined target-types.

FR is puzzled about the responsibilities of IDE dialog and project manager. Both seem to do similar tasks when checking component dependencies. The question is if project manager can rely on the checks done by the IDE or need to check the dependencies again.

RK confirms that the project manager runs the dependency checks again.

FR raises another question about responsibilities between project manager and CMSIS-Build. Today, CMSIS-Build is required to get the IntelliSense configuration generated, ultimately. This looks like a strong entanglement to project manager and CMSIS-Build. How can this be changed in the future to something else than project manager?

RK recognizes that this tool interdependency might need to be changes in the future which should be possible. The current state is just how we have it implemented today.

FR asks if it would be possible to replace CMSIS-Build if one wants to generate other stuff than CMake Files, for instance for Cube? Or would CMSIS-Build anyway be needed for project manager?

RK clarifies that currently CMSIS-Build cannot easily be replaced. A possibility for generating different output than CMake might be possible by extending CMSIS-Build. CMSIS-Build already today supports make and CMake outputs. Adding Cube output would just be yet another output format.

JK asks DB to confirm that adding another generator next to make and cmake ones is already prepared.

DB confirms that CMSIS-Build is designed in the way that additional generators can be added. He adds that project manager shares this design concept. So instead of generating cprj one could extend project manager with a custom project format output.

FR summarizes that there are two possible extensions points to tweak the existing tools towards custom needs.

JAl jumps back to question raised by MG regarding IntelliSense to let GH or ME to add their views.

GH points out that the required files for IntelliSense are generated by CMake not by the actual build. The actual flow is through project manager, CMSIS-Build up to CMake to be ready to build something. This is already some kind of build step. 

JK clarifies that the issue is you already need to go some steps through the flow to get the IntelliSense database required to assist code editing. 

GH confirms this is the same for Keil Studio Cloud. 

MG repeats the question if one needs to run the full CMake build or if CMake cache generation is enough? 

DB confirms one don’t need to run a full build but only generate the CMake cache. 

MG summarizes with respect to the flow one needs to have all the steps running up to generated CMake files from CMSIS-Build to be able to generate IntelliSense database. 

RK points out that this is solved in Keil Studio already so we might need to share this knowledge. 

GH details that this specific functionality is part of the build service in Keil Studio Cloud. All the generation steps are triggered in the background once yml files are changed.

 CMSIS Project Manager

 RK summarizes feedback collected for the open proposal (PR #77). He highlights that not all topics might need to be implemented for a “minimal viable product” but shall be specified. The most relevant features shall be addressed and implemented during the next three of month. 

Project Name

VG explains potential issues when using the project name as a reference key. This may cause issues once a user wants to rename a project. I.e., one would need to change the name in many places. 

RK suggests to infer the project name from the folder name. 

JAl points out this might cause problems once having multiple cproject files part of one csolution in a single folder. 

RK adds that he expects a subfolder for each project and hence not having multiple cproject files. 

GH raises question about how to handle shared common files, i.e. files shared between projects. 

ME summarizes two competing issues: Repeating the project name all over the place. And specifying hierarchies of files.

RK puts together the goal might be “dropping a cproject.yml file into an arbitrary folder to make it a project”. This might have other implications we need to try out and learn. In an example like “myworkspace/blinky/cproject.yml” the last part (blinky) of the directory becomes the project name. 

Structure of AWS Software Stack

RK presents the usual layout of an AWS Software Stack. An arbitrary App Layer might be connected through different network interfaces, depending on the actual target hardware. Target hardware might be virtual hardware, evaluation boards or custom hardware.

Plan for next week

JK gives an outlook about plans for the upcoming week. Plan is to provide a development snapshot of Open-CMSIS-Pack tools. 

LM asks if then snapshot is going to be based on the available source code. 

DB confirms this will be a collection of the tools maintained in the public repo.

 Wrap up

 JK concludes the meeting and asks all participants to

  • Provide review feedback

    Suggest topics for upcoming meetings

 LM/RK discuss about ST requirements towards an MVP, specifically the RTE folder structure, see GitHub Issues #23, #24, and #30. These shall be addressed throught the next weeks.

 The next Open-CMSIS-Pack meeting is scheduled to Feb 1st 2022 16:00 CET (15:00 GMT).

Recording