Project Requirements we should consider

[ReinhardKeil]

NOTE This topic has been explained in the Open-CMSIS-Pack+Technical+Meeting+2021-06-29.

Application programmers will require in future a more flexible system to manage projects. We should therefore consider new use-cases that Embedded application developers face in future. Open-CMSIS-Pack mandates therefore to a holistic view on software projects that considers:

• A project structure that allows to manage dependent/related projects and enables reuse of partial projects.
• Control of the code generation where build order dependencies and multiple build configurations are a requirement.
• Hardware resource allocation where the system resources are partitioned for sub-projects.
• Assisted configuration where bespoke, domain-specific tools are used to configure hardware or software components.
• Deployment and Download to setup flash programming and manage firmware update processes including OTA programming.
• Debug setup and configuration with the flexiblity to support different debug methods, i.e. board-level debug adapter, debug with trace, simulation via models.
• Support for validation processes where unit testing, integration testing, and system testing is a requirement.

To work on this topics, we discuss in the following the current existing files that manage the project related data and then propose extensions. The Use Cases described below give you further context why this extensions are proposed.

Existing files that contain project related data with links to the specification.

File	points to…	Description
*.pack	*.rzone, *.svd	Device Family Pack: describes device, device variants, processor cores, memory, and debug options.
*.rzone		Resource file: describes device, processor cores, memory, and peripherals. *. rzone files describe also sub systems (after an assignment).
*.azone	*.rzone	Describes assignments to project zones (relates to *.cprj files) or execution zones (to setup MPU within a project).
*.cprj	*.clayer (proposed)	Describes a project and repeats device information. Linker setup could be potentially achieved using *.azone files.
*.clayer		Describes a layer with pre-configured software components and additional source files.
*.flm		Flash algorithm files (ELF format); contain information about flash sector and block sizes which is somewhat duplicated in *.rzone alignment information.

New proposed files that help us to address the use cases described above.

File	points to…	Description
*.ctarget #7	*.rzone, *.cprj, *.cdebug	Describes the projects that compose a target application. Potentially this could be merged with the *.azone file.
*.cdebug		Debug configuration for the target. Potentially a *.ctarget could have multiple debug configurations, i.e. for CMSIS DAP, ULINK, J Link, DSTREAM, etc.
<packlist> #9		Inventory files of packs that are used in an IDE workspace that may contain multiple *.ctarget and *.cprj files.

Note: for stand-along tools like CMSIS-Build or a command-line debug tool it should be sufficient to use a *.cprj or *.cdebug file to configure the tool. It is therefore OK to somewhat duplicate information in the various files.

Use cases

Multi-Project Requirements

The diagram above shows a top-level software structure of a multi-processor system, where Processor #1 has also a secure and non-secure execution area. The diagram implies that four different projects are used to organize the different parts. The concept should allow therefore to manage sub-projects that compose the overall application. The *.ctarget file proposed above should allow that.

To manage the memory and peripheral resources of such complex applications, CMSIS-Zone was developed, however the concepts are not yet adopted by the industry, which might be due to the lack of integration into the wider project management.

During this project we should therefore review and discuss the concept of CMSIS-Zone and also consider how other solutions (such as DeviceTree) should be considered. Maybe the right approach is a multi-step approach, where we first start with (a potentially modified) CMSIS-Zone concept and merge it later with DeviceTree.

Building Blocks for Applications

We use the concept of software layers today to generate example projects for a diverse range of boards and applications. A small set of software layers can be combined to a large set of examples and provided that each layer is tested and has proper attributes, these examples run.

In the example generation:

• A Readme.md that describes the overall example is generated from markdown file snippets that describe each layer.
• Interface strings that list interfaces provided by a layer and consumed by a layer allow to auto generate possible combinations for examples.

As software layers represent a set of pre-configured software components, we think that a next-generation project management could allow to select layers to simplify the overall project generation. Again the Interface strings could be used to show potential layer combinations (and we should therefore review this concept). That is one reason why the proposal suggests to include the *.clayer concept into the project file.

Layers can also help to manage the software validation process where a setup for unit testing, integration testing, and system testing is a requirement. In the diagram below a complex application (composed of IoT/ML SW Platform and User Application Code) is retargeted for testing to simulation models (with the FVP Layer), test board hardware (with the Board Layer), and the final target application (with the Target Layer). We believe that this concept diagram should be explored further.

[0Grit]

Please consider creating a strong distinction for packs that implement a board if not already done.

Boards contain various devices and a pack for a board needs to include board specific software. Example would be if a host mcu needs to turn on a regulator in order to power another device on the board.

[0Grit]

Also, very interested in seeing where device tree fits in this.

[0Grit]

The data within the board pack and that is part of device tree should be useable by middleware to help the device describe and provide interfaces to remote systems.