Open-CMSIS-Pack development tools - C++

Related tags

Utilities devtools
Overview

CMSIS-Pack Development Tools and Libraries

This repository contains the source code of command line tools and library components for processing meta information specified by CMSIS-Pack and CMSIS-Build which are written in C++ as well as build and test configurations targeting Windows, Linux and macOS host platforms.

CMSIS-Pack defines a delivery mechanism for software components, device parameters, and evaluation board support. The XML-based package description (PDSC) file contains the meta information of a so called 'Software Pack' which is a collection of files including:

  • Source code, header files, and software libraries
  • Documentation and source code templates
  • Device parameters along with startup code and programming algorithms
  • Example projects

The complete file collection along with the PDSC file is distributed as a zip archive using the file extension *.pack.

CMSIS-Build defines an XML project file format that allows building projects based on hardware descriptions, software components, source modules and linker scripts distributed as software packs. The build manager (cbuildgen) is reading the project (`*.cprj) and generates the build instructions as CMake configuration files.

The end goal of this project is to provide a consistent and compliant set of command-line tools for covering the Software Pack lifecycle from creation and maintenance, via distribution and installation all the way to the project build, flash programming and debugging on the targeted microcontroller.

Repository toplevel structure

    📦
    ┣ 📂cmake       local cmake functions and configuration files
    ┣ 📂docs        documentation shared by all components
    ┣ 📂external    3rd party components loaded as submodules
    ┣ 📂libs        reusable C++ library component source code shared by tools
    ┣ 📂scripts     scripts used by validation, build and test actions
    ┣ 📂test        test related files shared across tool and library components
    ┗ 📂tools       command line tool source code

Building the tools locally

This section contains steps to generate native makefiles and workspaces that can be used in the compiler environment of your choice.

The instructions contain a complete guide to get you the project build on your local machine for development and testing purposes.

Prerequisites

The following applications are required to be installed on your machine to allow components in this repository to be built and run.

Note that some of the required tools are platform dependent:

  • Git
  • A tool chain for your platform
    • Windows:

      • GIT Bash
      • Visual Studio 2017 or 2019
      • CMake (minimum recommended version 3.18)
      ☑️ Note:
          Make sure 'git' and 'bash' paths are listed under the PATH environment
          variable and set the git bash priority higher in the path.
      
    • Linux/MacOS:

      • GNU Bash (minimum recommended version 4.3)
      • GNU Compiler (minimum recommended version 5.4)
      • CMake (minimum recommended version 3.18)
      • make or Ninja
    • General:

      ☑️ Required only for packgen tests.
      
      Set below mentioned environment variable:
        * CC : Full qualified path to GNU Arm Embedded compiler binary (arm-noneabi-gcc)
      
        for e.g.
          $export CC=/c/my/path/to/arm-noneabi-gcc
      

Clone repository

Clone github repository to create a local copy on your computer to make it easier to develop and test. Cloning of repository can be done by following the below git command:

git clone [email protected]:Open-CMSIS-Pack/devtools.git

Build components

This is a three step process:

  1. Download third party software components specified as git submodules.
  2. Generate configuration files for a build system
  3. Run build

Download third party software components

  • Go to / /devtools and run git command:

    git submodule update --init --recursive
  • Create and enter the build directory

    mkdir build
    cd build

Generate configuration files

As usual, the actual build steps vary by platform.

  • Linux/MacOS:
    On Linux or MacOS use the following commands.\

    Note: If DCMAKE_BUILD_TYPE is not selected, the binaries shall build with Release configuration:

    cmake -DCMAKE_BUILD_TYPE= ..

    for e.g.

    cmake -DCMAKE_BUILD_TYPE=Debug ..
  • Windows:
    On Windows system use the following command to generate the complete workspace:

    cmake -A x64 ..

Run build

One can trigger a build for all CMake targets or specific targets from the command line.

☑️ Note:
    The flag `--config` is optional. If it is not specified in the command, depending on
    the platform the binaries shall build in default configurations.
        - Windows: Debug
        - Linux/macOS: Release

Follow the respective commands:

  • Build all CMake targets

    cmake --build . --config for e.g.

    cmake --build . --config Debug
  • Users can build specific target of their choice and build:

    • Select the CMake generated target from the list below:

      • cbuild
      • cbuildgen
      • cbuildgenlib
      • CbuildUnitTests
      • CbuildIntegTests
      • CrossPlatform
      • CrossPlatformUnitTests
      • ErrLog
      • ErrLogUnitTests
      • packgen
      • packgenlib
      • PackGenUnitTests
      • RteFsUtils
      • RteFsUtilsUnitTests
      • RteModel
      • RteModelUnitTests
      • RteUtils
      • RteUtilsUnitTests
      • XmlReader
      • XmlReaderUnitTests
      • XmlTree
      • XmlTreeUnitTests
      • XmlTreeSlim
      • XmlTreeSlimUnitTests
    • Build the selected target and run command

      cmake --build . --config --target

      for e.g.

      cmake --build . --config Debug --target CbuildUnitTests

Run Tests

One can directly run the tests from command line.

☑️ Required only when the pack repository/installed toolchains reside in places different from the default values.

Set below mentioned environment variables:
  * CI_PACK_ROOT          : Directory that contains the software packs in CMSIS-Pack format
  * CI_GCC_TOOLCHAIN_ROOT : GCC toolchain installation path

  for e.g.
    $export CI_PACK_ROOT=/c/my/path/to/Pack/Root
    $export CI_GCC_TOOLCHAIN_ROOT=/c/my/path/to/toolchain
  • Using ctest:
    Use the command below to trigger the tests.

    • ctest -C : Run all registered tests (Note: Running all the tests can take a while)
    • ctest -R -C : Run all tests matching the regex

    for e.g.

    ctest -C Debug
        or
    ctest -R CbuildUnitTests -C Debug
  • Using test executable:

    • Go to root build directory

      cd <root>

    • Run the executable

      ./<path_to_executable>/<executable_name>

      for e.g.

      cd build
      ./tools/buildmgr/test/integrationtests/windows64/Debug/CbuildIntegTests.exe

Note

By default, few special tests are skipped from execution as they are dependent on specific environment configuration or other dependencies.

  1. CI dependent tests :
    These tests are designed to work only in CI (Continuous Integration) environment

  2. AC6 toolchain test :
    The below listed tests depend on a valid AC6 toolchain installed and can be run in the local environment on the installation of valid Arm Compiler 6.

    ☑️ Required only when the installed AC6 toolchain resides in places different from the default values.
    
    Set below mentioned environment variables:
    * CI_ARMCC6_TOOLCHAIN_ROOT : AC6 toolchain installation path
    
      for e.g.
        $export CI_ARMCC6_TOOLCHAIN_ROOT=/c/my/path/to/AC6/toolchain
    

    Make sure you have the proper Arm Compilers licenses.

License

Open-CMSIS-Pack is licensed under Apache 2.0.

Contributions and Pull Requests

Contributions are accepted under Apache 2.0. Only submit contributions where you have authored all of the code.

Proposals, Reviews and Project

Please feel free to raise an issue on GitHub to start the discussion about your proposal.

We are in the early days and discuss proposals which we are dividing into 5 work streams with a dedicated label:

  • Core Library Components - common libraries that are re-used across a range of tools. The PoC Tools are the first consumers, but the library components can also be used to create commercial derivatives or in-house tooling.
  • Overall Project Concept - procedures to generate packs and application software. We shall consider complex applications such as multi-core processor systems or secure/non-secure partitions.
  • PoC Tools - command line tools and utilities that implement the overall concepts and are intended to be used for open-source projects or even integrated into commercial software tools.
  • Process Improvements - documentation and tools that help the software community to streamline and secure the software delivery to the user base.
  • Resource Management - describes the data models used to manage and organized software packs and application projects.

These Issues are tracked inside the project board

Issues, Labels

Please feel free to raise an issue on GitHub to report misbehavior (i.e. bugs)

Issues are your best way to interact directly with the maintenance team and the community. We encourage you to append implementation suggestions as this helps to decrease the workload of the very limited maintenance team.

We shall be monitoring and responding to issues as best we can. Please attempt to avoid filing duplicates of open or closed items when possible. In the spirit of openness we shall be tagging issues with the following:

  • bug – We consider this issue to be a bug that shall be investigated.

  • wontfix - We appreciate this issue but decided not to change the current behavior.

  • out-of-scope - We consider this issue loosely related to CMSIS. It might be implemented outside of CMSIS. Let us know about your work.

  • question – We have further questions about this issue. Please review and provide feedback.

  • documentation - This issue is a documentation flaw that shall be improved in the future.

  • DONE - We consider this issue as resolved - please review and close it. In case of no further activity, these issues shall be closed after a week.

  • duplicate - This issue is already addressed elsewhere, see a comment with provided references.

Comments
  • [projmgr] Using existing .cprj as lockfile

    [projmgr] Using existing .cprj as lockfile

    With the recent advances to the .yml format and projmgr/csolution tools I'd like to reopen the discussion around lockfiles.

    It seems that the source of truth for the projects are now likely to be the .yml files.

    Use-case: User adds a compiler flag to the project

    1. Manually edit the cproject/csolution.yml file to add the defined symbol
    2. Run csolution/projmgr tool to update .cprj files
    3. Trigger build of the project using cbuildgen and the cprj file

    During step 2, if there is already a cprj file existing, we should preserve/reuse as much information from that as possible.

    For example, the yml files may not specify any packs, or without any version ranges, but the .cprj may be strictly locked down to a specific pack+version. Same for components.

    For the above use-case, the user expects only the define to be added in the build. If the 2. would result in a full recompute/resolving of components+pack-versions it would make the .yml files impossible to use over time or between colleagues, since the contents of the .cprj would very likely be different due to changing CMSIS_PACK_ROOT contents.

    This is a followup on the discussion from the build gap

    Also, working in this way means that the user should put commit the .yml and the .cprj files in their git repository to make sure that colleagues/CI are building the same thing.

    question 
    opened by slhultgren 26
  • Make creation of RTE folder optional

    Make creation of RTE folder optional

    This introduces the flag --no-update-rte for the csolution convert and cbuildgen cmake commands to skip creation/update of the RTE folder and files. It is useful when you just want to resolve the project but don't want the RTE files.

    In addition, the commands csolution list dependencies and csolution list generators are fixed to never create the RTE folder.

    Fixes #371

    Prerequisite: #436

    Contributed by STMicroelectronics

    Signed-off-by: Erik LUNDIN [email protected]

    opened by ErikLundinSTM 19
  • packchk semantic version issue

    packchk semantic version issue

    Hi

    It seems that Packchk tool is raising a M394 error for some specific version number:

    Not Semantic Versioning: '2.0.0-alpha.0.5'
    

    Pre-analysis from Thorsten: It doesn’t like the dot ‘.’ behind “0-alpha”. If this is an issue we should extend the parser. https://github.com/Open-CMSIS-Pack/devtools/blob/main/tools/packchk/src/ValidateSyntax.cpp#L394

    @YohMartST @PierreLeCorre @fred-r

    bug 
    opened by jeromecoutant 13
  • Proper way to support compiler specific sources, macro definitions, etc.

    Proper way to support compiler specific sources, macro definitions, etc.

    There are many cases about compiler specific sources for one project. One common example is linker. Based on existing mechanisms provided in csolution/cproject yml, followings are one way to support specify it: Under cproject.yml, using for-type

        - group: linker
          files:
            - file: ./iar/MK64FN1M0xxx12_flash.icf
              for-type: +iar
            - file: ./mdk/MK64FN1M0xxx12_flash.scf
              for-type: +mdk
            - file: ./armgcc/MK64FN1M0xxx12_flash.ld
              for-type: +armgcc
    

    under csolution.yml, define the target-type:

      target-types:
        - type: mdk
          device: MK64FN1M0VLL12
          compiler: AC6
        - type: iar
          device: MK64FN1M0VLL12
          compiler: IAR
        - type: armgcc
          device: MK64FN1M0VLL12
          compiler: GCC
    

    However, there is a defect in such way, per my understand that, cproject is used to define project contents. csolution is used to define solution. So one cproject may need to be used in many csolutions. So if we used targets defined in one csolution in cproject, then if other csolution uses this cproject again, then it may needs to update the cproject yml data. This coupling between cproject and csolution affects the reuse of cproject.

    Any other better/proper way to support compiler specific sources/files?

    discussion 
    opened by tcsunhao 12
  • Different configurations of different build-types to support in multproject csolution

    Different configurations of different build-types to support in multproject csolution

    For csolution yml with multi projects, build-types are shared and can only be shared.

    NXP data for multiproject example, each project has its own data suit copy, to map into csolution/cproject, then we need merge hello_world_cm4 and hello_world_cm0plus data into one copy. This requests 2 projects data should be mergeable which means they shouldn't have its own data related to build-types.

    If one project has its individual different build-type settings which the other project doesn't have. Then existing csolution yml cannot specify it.

    For example, project1 and project2 are in one csolution.yml, project1 needs to include bin of project2. project1 depends on a special component, for its configuration, XXDEBUG is needed under "Debug" build-target, XXNDEBUG is needed under "Release" build-target, there is no such XXDEBUG/XXNDEBUG macro definition needed in project2. It looks like there is no good way to support such case in existing csolution/cproject mechanism. If you record XXDEBUG under "Debug" build-type, then both project1 and project2 will get it.

    This is kind of corner case, but it may happen.

    discussion done 
    opened by tcsunhao 12
  • [csolution] project compiling with cbuild.sh does not compile with uvision

    [csolution] project compiling with cbuild.sh does not compile with uvision

    I can build successfully:

    $ cbuild.sh gpio-toggle.AC6+STM32U585I-IOT02A.cprj
    (cbuild.sh): Build Invocation 0.10.4 (C) 2021 ARM
    gpio-toggle.AC6+STM32U585I-IOT02A.cprj validates
    (cbuildgen): Build Process Manager 0.10.4+p53-g0715f4d (C) 2022 ARM
    M650: Command completed successfully.
    (cbuildgen): Build Process Manager 0.10.4+p53-g0715f4d (C) 2022 ARM
    M652: Generated file for project build: 'C:/Cube20/stm32cube_fw_all/examples/hal/gpio/toggle/projects/gpio-toggle.AC6+STM32U585I-IOT02A_IntDir/CMakeLists.txt'
    CMake Warning (dev) at C:/Program Files/CMake/share/cmake-3.22/Modules/Compiler/ARMClang.cmake:91 (message):
      Policy CMP0123 is not set: ARMClang cpu/arch compile and link flags must be
      set explicitly.  Run "cmake --help-policy CMP0123" for policy details.  Use
      the cmake_policy command to set the policy and suppress this warning.
    
      For compatibility, CMake will automatically add cpu/arch flags based on the
      CMAKE_SYSTEM_PROCESSOR and/or CMAKE_SYSTEM_ARCH variables.
    Call Stack (most recent call first):
      C:/Program Files/CMake/share/cmake-3.22/Modules/Compiler/ARMClang-C.cmake:3 (__compiler_armclang)
      C:/Program Files/CMake/share/cmake-3.22/Modules/CMakeCInformation.cmake:25 (include)
      CMakeLists.txt:59 (project)
    This warning is for project developers.  Use -Wno-dev to suppress it.
    
    -- Configuring done
    -- Generating done
    -- Build files have been written to: C:/Cube20/stm32cube_fw_all/examples/hal/gpio/toggle/projects/gpio-toggle.AC6+STM32U585I-IOT02A_IntDir
    [1/15] Building C object CMakeFiles/gpio-toggle.AC6+STM32U585I-IOT02A.dir/C_/Cube20/stm32cube_fw_all/examples/hal/gpio/toggle/targets/B-U585I-IOT02A/stm32_system.o
    [2/15] Building C object CMakeFiles/gpio-toggle.AC6+STM32U585I-IOT02A.dir/C_/Cube20/examples/hal/gpio/toggle/example.o
    [3/15] Building C object CMakeFiles/gpio-toggle.AC6+STM32U585I-IOT02A.dir/C_/Cube20/stm32cube_fw_all/examples/hal/gpio/toggle/targets/B-U585I-IOT02A/stm32_gpio.o
    [4/15] Building C object CMakeFiles/gpio-toggle.AC6+STM32U585I-IOT02A.dir/C_/Cube20/examples/hal/gpio/toggle/example_status.o
    [5/15] Building C object CMakeFiles/gpio-toggle.AC6+STM32U585I-IOT02A.dir/C_/Cube20/examples/hal/gpio/toggle/main.o
    [6/15] Building C object CMakeFiles/gpio-toggle.AC6+STM32U585I-IOT02A.dir/C_/Cube20/infra/Firmware/drivers/STM32U5xx_HAL_Driver/Src/stm32u5xx_hal_gpio.o
    [7/15] Building C object CMakeFiles/gpio-toggle.AC6+STM32U585I-IOT02A.dir/C_/Cube20/infra/Firmware/drivers/STM32U5xx_HAL_Driver/Src/stm32u5xx_hal.o
    [8/15] Building C object CMakeFiles/gpio-toggle.AC6+STM32U585I-IOT02A.dir/C_/Cube20/infra/Firmware/drivers/STM32U5xx_HAL_Driver/Src/stm32u5xx_hal_cortex.o
    [9/15] Building C object CMakeFiles/gpio-toggle.AC6+STM32U585I-IOT02A.dir/C_/Cube20/infra/Firmware/drivers/STM32U5xx_HAL_Driver/Src/stm32u5xx_hal_pwr.o
    [10/15] Building C object CMakeFiles/gpio-toggle.AC6+STM32U585I-IOT02A.dir/C_/Cube20/infra/Firmware/drivers/STM32U5xx_HAL_Driver/Src/stm32u5xx_hal_pwr_ex.o
    [11/15] Building C object CMakeFiles/gpio-toggle.AC6+STM32U585I-IOT02A.dir/C_/Cube20/infra/Firmware/drivers/STM32U5xx_HAL_Driver/Src/stm32u5xx_hal_rcc.o
    [12/15] Building C object CMakeFiles/gpio-toggle.AC6+STM32U585I-IOT02A.dir/C_/Cube20/infra/Firmware/drivers/STM32U5xx_HAL_Driver/Src/stm32u5xx_hal_rcc_ex.o
    [13/15] Building C object CMakeFiles/gpio-toggle.AC6+STM32U585I-IOT02A.dir/C_/Cube20/infra/Firmware/cmsis/Device/ST/STM32U5xx/Source/startup_stm32u585xx.o
    [14/15] Building C object CMakeFiles/gpio-toggle.AC6+STM32U585I-IOT02A.dir/c2beb62ea54e6255ca3e9c1c2ab641e8/gpio/toggle/projects/RTE/Device/STM32U585AIIx/system_stm32u5xx.o
    [15/15] Linking C executable C:\Cube20\stm32cube_fw_all\examples\hal\gpio\toggle\projects\gpio-toggle.AC6+STM32U585I-IOT02A_OutDir\gpio-toggle.AC6+STM32U585I-IOT02A.axf
    cbuild.sh finished successfully!
    

    This cprj:

    <?xml version="1.0" encoding="UTF-8" standalone="no" ?>
    <cprj schemaVersion="1.7.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="PACK.xsd">
      <created timestamp="2022-03-07T11:10:49" tool="csolution 0.9.1+p2-g0715f4d"/>
    
      <info isLayer="false">
        <description>Automatically generated project</description>
      </info>
    
      <packages>
        <package name="CMSIS" vendor="ARM" version="5.8.0"/>
        <package name="STM32U5xx_DFP" vendor="Keil" version="1.1.0"/>
        <package name="Example_HAL_GPIO_Toggle" vendor="STMicroelectronics" version="0.0.1"/>
        <package name="STM32U5xx_DFP" vendor="STMicroelectronics" version="0.0.1"/>
        <package name="STM32U5xx_Drivers" vendor="STMicroelectronics" version="0.0.1"/>
        <package name="board_resources_B-U585I-IOT02A" vendor="STMicroelectronics" version="0.0.1"/>
      </packages>
    
      <compilers>
        <compiler name="AC6" version="6.16.0"/>
      </compilers>
    
      <target Ddsp="DSP" Dfpu="SP_FPU" Dname="STM32U585AIIx" Dsecure="TZ-disabled" Dtz="TZ" Dvendor="STMicroelectronics:13">
        <output intdir="gpio-toggle.AC6+STM32U585I-IOT02A_IntDir/" name="gpio-toggle.AC6+STM32U585I-IOT02A" outdir="gpio-toggle.AC6+STM32U585I-IOT02A_OutDir/" type="exe"/>
        <ldflags compiler="AC6" file="RTE/Device/STM32U585AIIx/stm32u585xx_flash.sct"/>
        <defines>STM32U585xx;USE_HAL_DRIVER</defines>
      </target>
    
      <components>
        <component Cclass="CMSIS" Cgroup="CORE" Cvendor="ARM" Cversion="5.5.0"/>
        <component Cclass="Application" Cgroup="Example" Cvariant="HAL_GPIO_Toggle" Cvendor="STMicroelectronics" Cversion="0.0.1"/>
        <component Cbundle="B-U585I-IOT02A" Cclass="Board Support" Cgroup="Board Resource" Cvendor="STMicroelectronics" Cversion="0.0.1"/>
        <component Cclass="Device" Cgroup="STM32 HAL" Csub="Common" Cvendor="STMicroelectronics" Cversion="0.0.1"/>
        <component Cclass="Device" Cgroup="STM32 HAL" Csub="Cortex" Cvendor="STMicroelectronics" Cversion="0.0.1"/>
        <component Cclass="Device" Cgroup="STM32 HAL" Csub="GPIO" Cvendor="STMicroelectronics" Cversion="0.0.1"/>
        <component Cclass="Device" Cgroup="STM32 HAL" Csub="PWR" Cvendor="STMicroelectronics" Cversion="0.0.1"/>
        <component Cclass="Device" Cgroup="STM32 HAL" Csub="RCC" Cvendor="STMicroelectronics" Cversion="0.0.1"/>
        <component Cclass="Device" Cgroup="Startup" Cvendor="STMicroelectronics" Cversion="0.0.1">
          <file attr="config" category="header" name="Include/stm32_external_env.h" version="0.0.1"/>
          <file attr="config" category="linkerScript" name="Source/Templates/arm/linker/stm32u585xx_flash.sct" version="0.0.1"/>
          <file attr="config" category="source" name="Source/Templates/system_stm32u5xx.c" version="0.0.1"/>
        </component>
      </components>
    
      <files>
        <group name="Generated Code">
          <file category="sourceC" name="../targets/B-U585I-IOT02A/stm32_gpio.c"/>
          <file category="header" name="../targets/B-U585I-IOT02A/stm32_gpio.h"/>
          <file category="sourceC" name="../targets/B-U585I-IOT02A/stm32_system.c"/>
          <file category="header" name="../targets/B-U585I-IOT02A/stm32_system.h"/>
          <file category="header" name="../targets/B-U585I-IOT02A/stm32_target.h"/>
          <file category="header" name="../targets/B-U585I-IOT02A/stm32_assert.h"/>
          <file category="header" name="../targets/B-U585I-IOT02A/stm32u5xx_hal_conf.h"/>
        </group>
      </files>
    </cprj>
    

    And by default I get this error:

    image

    opened by fred-r 12
  • [projmgr] [buildmgr] Open door to more compilers

    [projmgr] [buildmgr] Open door to more compilers

    Per current schemas supported compilers are limited to AC6, IAR & GCC:

    "CompilerType": { "type": "string", "pattern": "^(GCC|AC6|IAR)(@(\d+\.\d+\.\d+((\+|\-)[\w.+-]+)?))?$", "description": "Selection of the toolchain used in the project (GCC, AC6, IAR), optionally with version, for example [email protected]" },

    What about if aiming to rely on clang as example ?

    question 
    opened by VGRSTM 12
  • [rtemodel] Target defines are not split

    [rtemodel] Target defines are not split

    In a regular ARM DFP PDSC, the device section's compile XML object has the attribute define (https://open-cmsis-pack.github.io/Open-CMSIS-Pack-Spec/main/html/pdsc_devices_pg.html). UV5 allows multiple definitions in this, separated by a comma. These are then put separately on the compiler's command like via the -D flag.

    Currently, this does not occur on invocation of cbuild, and a define of this type is put directly onto the command line, causing build failures for packs of this nature. The offending section seems to be here:

    https://github.com/Open-CMSIS-Pack/devtools/blob/4524cb6e6f2be0318e6e714e57fa38ce8aadc09a/libs/rtemodel/src/RteTarget.cpp#L613-L620

    discussion 
    opened by Quaker762 11
  • generators feature broken ?

    generators feature broken ?

    > csolution.exe --help
    CMSIS Project Manager 0.9.6 (C) 2022 ARM
    
    > csolution.exe list generators -s HAL_CRC_UserDefinedPolynomial.csolution.yml -p HAL_CRC_UserDefinedPolynomial.cproject.yml -c HAL_CRC_UserDefinedPolynomial.AC6+B-U585I-IOT02A
    
    > csolution.exe -s HAL_CRC_UserDefinedPolynomial.csolution.yml convert
    

    Nothing happens though the cproject references a component with a generator:

      components:
        - component: STMicroelectronics::Utility:Debug:basic trace&Configurable
    

    If I switch to a variant with no generator:

      components:
        - component: STMicroelectronics::Utility:Debug:basic trace&UART
    

    Then:

    > csolution.exe -s HAL_CRC_UserDefinedPolynomial.csolution.yml convert
    C:/stm32cube_fw_all/examples/hal/crc/UserDefinedPolynomial/targets/B-U585I-IOT02A/HAL_CRC_UserDefinedPolynomial.AC6+B-U585I-IOT02A.cprj - info csolution: file generated successfully
    C:/stm32cube_fw_all/examples/hal/crc/UserDefinedPolynomial/targets/B-U585I-IOT02A/HAL_CRC_UserDefinedPolynomial.GCC+B-U585I-IOT02A.cprj - info csolution: file generated successfully
    C:/stm32cube_fw_all/examples/hal/crc/UserDefinedPolynomial/targets/B-U585I-IOT02A/HAL_CRC_UserDefinedPolynomial.IAR+B-U585I-IOT02A.cprj - info csolution: file generated successfully
    
    bug question 
    opened by fred-r 10
  • Access Sequence for RTE folder

    Access Sequence for RTE folder

    It would be great to have an access sequence to link to the current RTE folder, e.g. for manual config header files.

    BTW, should $Bname$, $Dname$ etc work with the current release? For me, only $OutDir(project[.build-type][+target-type])$ seems to work.

    bug question 
    opened by jankap 9
  • Proposal for shorter file/pathnames

    Proposal for shorter file/pathnames

    Using the test project AWS_MQTT_MutualAuth_Demo from https://github.com/RobertRostohar/ctools_lab, currently the following files /directories are created in .\example\IoT\AWS_MQTT_MutualAuth_Demo:

    AWS_MQTT_MutualAuth_Demo.Debug+AVH_MPS2_Cortex-M7_IntDir
    AWS_MQTT_MutualAuth_Demo.Debug+AVH_MPS2_Cortex-M7_OutDir
    AWS_MQTT_MutualAuth_Demo.Release+AVH_MPS2_Cortex-M7_IntDir
    AWS_MQTT_MutualAuth_Demo.Release+AVH_MPS2_Cortex-M7_OutDir
    AWS_MQTT_MutualAuth_Demo.Debug+AVH_MPS3_Corstone-300_IntDir
     :
    AWS_MQTT_MutualAuth_Demo.Debug+AVH_MPS2_Cortex-M7.cprj
    AWS_MQTT_MutualAuth_Demo.Debug+AVH_MPS2_Cortex-M7.cprj
    AWS_MQTT_MutualAuth_Demo.Release+AVH_MPS2_Cortex-M7.cprj
    AWS_MQTT_MutualAuth_Demo.Release+AVH_MPS2_Cortex-M7.cprj
    AWS_MQTT_MutualAuth_Demo.Debug+AVH_MPS3_Corstone-300.cprj
    

    While this makes it easy to identify the relationship between *.cprj and IntDir/OutDir it creates long pathnames quickly.

    This is a suggestion to shorter path names while at the same time reducing directories and the length of the directory names. The output files of one project always use the same directory. The benefit is that post-steps like programming can always use the same output filename as there is no difference between Debug and Release build in the path/file name. Combining a Release build of a Boot part with a Debug build of an Application part is therefore easier.

    tmp\AVH_MPS2_Cortex-M7\Debug
    out\AVH_MPS2_Cortex-M7
    tmp\AVH_MPS2_Cortex-M7\Release
    out\AVH_MPS2_Cortex-M7
    tmp\AVH_MPS3_Corstone-300\Debug
     :
    AWS_MQTT_MutualAuth_Demo.Debug+AVH_MPS2_Cortex-M7.cprj
    AWS_MQTT_MutualAuth_Demo.Debug+AVH_MPS2_Cortex-M7.cprj
    AWS_MQTT_MutualAuth_Demo.Release+AVH_MPS2_Cortex-M7.cprj
    AWS_MQTT_MutualAuth_Demo.Release+AVH_MPS2_Cortex-M7.cprj
    AWS_MQTT_MutualAuth_Demo.Debug+AVH_MPS3_Corstone-300.cprj
    

    In CMakeLists.txt there is a set (TARGET ... command that also contributes to long path names. Suggestion is to just use the project-name, in this example: set (TARGET AWS_MQTT_MutualAuth_Demo) as the directories provide already enough separation.

    We might need to introduce configuration options in csolution to configure directory names, but before further exploration feedback on this proposal would be good.

    discussion 
    opened by ReinhardKeil 9
  • Definition mismatch between Cvariant in pdsc and component in cproject yml file

    Definition mismatch between Cvariant in pdsc and component in cproject yml file

    From https://github.com/Open-CMSIS-Pack/Open-CMSIS-Pack-Spec/blob/main/schema/PACK.xsd#L329 Seems that variant name could be a string "with no condition"

    In https://github.com/Open-CMSIS-Pack/devtools/blob/main/tools/projmgr/schemas/common.schema.json#L340 component and variant name are not "full" string and doesn't accept "(" for example

    opened by jeromecoutant 1
  • GCC warnings option could map to -Wall ?

    GCC warnings option could map to -Wall ?

    In https://github.com/Open-CMSIS-Pack/devtools/blob/main/tools/buildmgr/cbuildgen/config/GCC.11.2.1.cmake#L65

    I would map warnings: on to -Wall ?

    @tarek-bochkati

    discussion 
    opened by jeromecoutant 2
  • Should we assign clear names and definitions to working areas ?

    Should we assign clear names and definitions to working areas ?

    I think very often we have difficulties to understand each partner's needs because we have no clear definition of the "working areas" for OpenCMSIS-Pack compliant tools.

    I may propose this classification:

    1. User Code area This is where we place main.c/h and hand-written applicative code. This is fully under the control of the end-user (folders, files names and contents).

       Templates as well ? ==> If we update a component version the template may differ, like for a configuration file.
       So, is it wise to put it here ?
      
    2. Components code area This is where the components code is stored. This is $CMSIS_PACK_ROOT or local packs. It is under the control of the tool (folders and filenames).

    3. Generators area It contains the artefacts produced by the generators. It is fully under the control of the tool/generator (folders and files).

    4. Components configuration area This is the current RTE folder with the configuration files added by local copy. We have here the files:

      • added because tagged as "attr=config" files
      • some of these files are the result of the instantiation of a component The folder is under tool control but the files are RW for the end-user.

    I think that we should specify these working areas to make it clear what we are talking about.

    opened by fred-r 4
  • [csolution] generator variable $P needs to resolve to layer directory when component is selected by layer

    [csolution] generator variable $P needs to resolve to layer directory when component is selected by layer

    In csolution 1.2.0 we have changed the location of the RTE directory for layers. A layer directory (the directory containing the *.clayer.yml file) shall be self-contained and config files are no longer located/copied into the RTE directory of the *.cproject.yml.

    This has also implications on files being added to the projects by generator components.

    In case the generator description specifies $P this is defined to expand to the directory of the *.cproject.yml file. If the corresponding generator component is specified in a *.clayer.yml file, $P needs to expand to the directory of the *.clayer.yml file.

    bug documentation 
    opened by jkrech 0
  • `RTE_components.h`, preinclude files generated in wrong location and too late

    `RTE_components.h`, preinclude files generated in wrong location and too late

    Currently the file RTE_components.h and preinclude files are generated by cbuild in the directory with this naming:

    $ProjectDir$/RTE/_$Project$.$Build-Type$_%TargetType$
    

    I suggest that these files are generated by csolution and the directory is changed to:

    $ProjectDir$/RTE/_$Build-Type$_%TargetType$
    

    The change of the directory makes the behavior identical to MDK (when a *.CPRJ is imported) The change to generate the files by csolution allows to run static code analysis tools or intellisense engines before a build (these tools need visibility to all #define symbols).

    discussion done 
    opened by ReinhardKeil 4
  • Proposal `output-dir:` -> `output:`, add control for `target-name:`, rename `intdir:` -> `tmpdir:`, change in default settings

    Proposal `output-dir:` -> `output:`, add control for `target-name:`, rename `intdir:` -> `tmpdir:`, change in default settings

    Currently there is no way to control the output name (target-name) of the project.

    My suggestion for output-dir: is therefore to change it as below (with default settings):

    output:                          # was previously `output-dir:`
       build-dir: $ProjectDir$       # was previously `cprjdir`, specifies directory of `*.CPRJ`, `*.cbuild.yml` files, default location of the `*.cproject.yml`
       rte-dir: $ProjectDir$/RTE     # specifies directory for RTE configuration files.
       tmp-dir: $ProjectDir$/tmp/$TargetType/$BuildType   # was previously `intdir:`, but default is `tmp` as directory name
       out-dir: $ProjectDir$/out/$TargetType/$BuildType   # specifies the directory for the build output
       target-name: $Project$        # specifies the base name of the output files
    

    Note: the proposal also adds - before dir: to make it easier to understand.

    As a result of this proposal, I suggest to add to Access Sequences the following

    Access Sequence | Description :----------------------------------------------|:-------------------------------------- $ProjectDir$ | Directory path to the *.cproject.yml file; always refers to the currently processed project file

    This changes would simplify further the directory structure.

    opened by ReinhardKeil 0
Releases(tools/svdconv/3.3.44)
Owner
Open-CMSIS-Pack
Open-CMSIS-Pack
Open-CMSIS-Pack
Play Doh Windows ACL Tools

PDAcl 是一个支持Windows活动目录扩展权限设置、Windows活动目录常规权限设置、Windows服务权限设置的命令工具。

倾旋 61 Oct 30, 2022
A collection of tools to abuse chrome browser

A collection of tools to abuse chrome browser

batsec 266 Nov 14, 2022
This is a collection of tools for creating and manipulating BitTorrent v2 torrent files

torrent tools This is a collection of tools for creating and manipulating BitTorrent v2 torrent files. torrent-new can create hybrid torrents, but the

Arvid Norberg 9 Nov 12, 2022
Tools for analyzing and browsing Tarmac instruction traces.

Tarmac Trace Utilities Arm Tarmac Trace Utilities is a suite of tools to read, analyze and browse traces of running programs in the 'Tarmac' textual f

Arm Software 35 Oct 30, 2022
Documenting the development of a simple first module.

Your First Module This guide will look at writing a complete module, with many common features in a reduced form. This includes the module initialisat

Open Multiplayer 16 Jun 3, 2021
A C library for parsing/normalizing street addresses around the world. Powered by statistical NLP and open geo data.

libpostal: international street address NLP libpostal is a C library for parsing/normalizing street addresses around the world using statistical NLP a

openvenues 3.6k Nov 23, 2022
PANDA open source project

PANDA (Protocol And Network Datapath Acceleration) Protocol and Network Datapath Acceleration, or PANDA, is a software programming model, framework, s

null 40 Sep 7, 2022
Open Data Description Language

Open Data Description Language This is the reference parser for the Open Data Description Language (OpenDDL), version 3.0. The official language speci

Eric Lengyel 40 Nov 27, 2022
Orbit, the Open Runtime Binary Instrumentation Tool, is a standalone C/C++ profiler for Windows and Linux

Orbit, the Open Runtime Binary Instrumentation Tool, is a standalone C/C++ profiler for Windows and Linux. Its main purpose is to help developers visualize the execution flow of a complex application.

Google 2.9k Nov 28, 2022
AlleyWind is an advanced Win32-based and open-sourced utility that helps you to manage system's windows

AlleyWind AlleyWind is an advanced Win32-based and open-sourced utility that helps you to manage system's windows. AlleyWind could: Displays a graphic

KNSoft 22 Oct 20, 2022
WinMerge is an Open Source differencing and merging tool for Windows.

WinMerge is an Open Source differencing and merging tool for Windows. WinMerge can compare both folders and files, presenting differences in a visual text format that is easy to understand and handle.

null 3.6k Nov 28, 2022
cavi is an open-source library that aims to provide performant utilities for closed hierarchies (i.e. all class types of the hierarchy are known at compile time).

cavi cavi is an open-source library that aims to provide performant utilities for closed hierarchies (i.e. all class types of the hierarchy are known

Baber Nawaz 5 Mar 9, 2022
KeyScan is a C++ open source explanation tool targeting windows operating system.

KeyScan is a C++ open source explanation tool targeting windows operating system. it allows you to send keyboard events, mouse events and capture keystrokes (keylogger).!

null 15 Sep 21, 2022
An open source re-implementation of LEGO Rock Raiders 🪨⛏

OpenLRR An open source re-implementation of LEGO Rock Raiders (PC). This is created by slowly implementing and replacing game functionality, while rel

Robert Jordan 39 Oct 9, 2022
Open Source iOS 15 Jailbreak Project

Fugu Fugu is the first open source jailbreak tool based on the checkm8 exploit. UPDATE: Fugu will now install Sileo, SSH and Substitute automatically!

epeth0mus 261 Nov 26, 2022
CMSIS-DAP using TinyUSB

Dapper Mime This unearths the name of a weekend project that I did in 2014. Both then and now, this is a port of ARM's CMSIS-DAP code to a platform wi

null 70 Nov 28, 2022
built-in CMSIS-DAP debugger tailored especially for the RP2040 “Raspberry Pi Pico”

RP2040 has two ARM Cortex-M0+ cores, and the second core normally remains dormant. pico-debug runs on one core in a RP2040 and provides a USB CMSIS-DAP interface to debug the other core. No hardware is added; it is as if there were a virtual debug pod built-in.

null 262 Nov 28, 2022
Breakout game for Raspberry Pi Pico with Pimoroni Pico Display pack

breakout_rpi_pico Breakout game for Raspberry Pi Pico with Pimoroni Pico Display pack Prebuilt binary (breakout.uf2) is here. To build your own binary

null 19 Oct 15, 2022
A resource pack converter from Optifine/MCPatcher formats to other formats

MCPatcherPatcher++ A resource pack converter from Optifine format to newer and alternative formats. This project uses C++ as the language. This might

supsm 104 Nov 22, 2022
High-performance specialized replacements for PHP's pack() and unpack() functions

ext-encoding High-performance specialized replacements for PHP's pack() and unpack() functions Under a profiler, it becomes obvious that PHP's pack()

PMMP 15 Sep 17, 2022