ROOT is pointing to the root CMSIS folder (the one containing CMSIS and Device).
cmake will check it can find the cross compiling tools as defined in armcc.cmake
PLATFORM is used to select the boot code for the example. In example below, Fast Model (FVP) is selected and the boot code for fast model will be used.
### Toolchain
CMAKE_TOOLCHAIN_FILE is selecting the toolchain (ac6, ac5 or gcc). The files are in CMSIS/DSP.
You may have to change the "tools" variable in armcc.make. It is pointing to your toolchain.
The version of armcc.cmake on github is using the ARM AC6 compiler coming from the ArmDS environment. The tools variable is thus pointing to ArmDS.
ARM_CPU is selecting the core. The syntax must be the one recognized by the compiler.
(So for instance different between AC5 and AC6).
If you use a different clang toolchain, you can just modify the tools path.
The final .. is the path to the directory containing the CMakeLists.txt of the variance example.
Since the build folder is assumed to be created in arm_variance_examples then the path to CMakeLists.txt from the build folder is ..
If you build with gcc, you'll need to change armcc.cmake, config.cmake and configUtils.cmake
To build for A5, you need to change DCMAKE_TOOLCHAIN_FILE and ARM_CPU:
config.make is defining options like -mfpu and the value to pass to gcc (or other compiler) may be different.
-DCMAKE_TOOLCHAIN_FILE=../../../../armac5.cmake
-DARM_CPU="cortex-a5"
configUtils.cmake is defining the use of a scatter file and it may be different with gcc.
To build for A5 with Neon acceleration, you need to add:
-DNEON=ON
### Building
make VERBOSE=1
Once cmake has generated the makefiles, you can use a GNU Make to build.
make VERBOSE=1
### Running
The executable can run on a FVP.
The generated executable can be run on a fast model.
For instance, if you built for m7, you could just do:
FVP_MPS2_Cortex-M7.exe -a arm_variance_example
FVP_MPS2_Cortex-M7.exe -a arm_variance_example
The final executable has no extension in the filename.
## Building only the CMSIS-DSP library
If you want to build only the CMSIS-DSP library and don't link with any boot code then you'll need to write a specific cmake.
Create a folder BuildCMSISOnly.
Inside the folder, create a CMakeLists.txt with the following content:
```cmake
cmake_minimum_required (VERSION 3.6)
# Define the project
project (testcmsisdsp VERSION 0.1)
## Customization
# Define the path to CMSIS-DSP (ROOT is defined on command line when using cmake)
set(DSP ${ROOT}/CMSIS/DSP)
armcc.make is use to cross compile with AC6 coming from ArmDS.
# Add DSP folder to module path
list(APPEND CMAKE_MODULE_PATH ${DSP})
You'll need to create a different toolchain file if you use something different.
Then you'll need to pass this file to cmake on the command line.
###########
#
# CMSIS DSP
#
config.cmake is included by the CMSIS-DSP cmake and is defining the options and include paths
needed to compile CMSIS-DSP.
# Load CMSIS-DSP definitions. Libraries will be built in bin_dsp
add_subdirectory(${DSP}/Source bin_dsp)
```
configBoot.cmake are definitions required to run an executable on a platform. It is using files from the Device folder of CMSIS. The result can run on FVP.
Create a build folder inside the BuildCMSISOnly folder.
Inside the build folder, type following cmake command
cmake -DROOT="path to CMSIS Root" \
-DCMAKE_PREFIX_PATH="path to compiler (folder containing the bin folder)" \
When the build has finished, you'll have a bin_dsp folder inside your build folder.
Inside bin_dsp, you'll have a folder per CMSIS-DSP Folder : BasicMathFunctions ...
Inside each of those folders, you'll have a library : libCMSISDSPBasicMath.a ...
If you need to run on something different, you'll need to modfy configBoot. If you need a different scatter file you'll need to modify configBoot.
configBoot is relying on some functions defined in configUtils and most of the customizations should be done here.
## Compilation symbols for tables
@ -75,8 +119,9 @@ Some new compilations symbols have been introduced to avoid including all the ta
If no new symbol is defined, everything will behave as usual. If ARM_DSP_CONFIG_TABLES is defined then the new symbols will be taken into account.
Then you can select all FFT tables or all interpolation tables by defining following compilation symbols:
ARM_ALL_FFT_TABLES : All FFT tables are included
ARM_ALL_FAST_TABLES : All interpolation tables are included
* ARM_ALL_FFT_TABLES : All FFT tables are included
* ARM_ALL_FAST_TABLES : All interpolation tables are included
If more control is required, there are other symbols but it is not always easy to know which ones need to be enabled for a given use case.
@ -93,9 +138,7 @@ We see that following symbols need to be enabled :
In addition to that, ARM_DSP_CONFIG_TABLES must be enabled and finally ARM_FFT_ALLOW_TABLES must also be defined.
This last symbol is required because if you don't want to include the TransformFunctions in your build of CMSIS-DSP then all tables related to FFT must not be included. It is the purpose of this flag.
This last symbol is required because if no transform functions are included in the build, then by default all flags related to FFT tables are ignored.
@ -324,9 +324,9 @@ Once those folders have been created. You can use following commands to create t
This will create a file Output.pickle which is containing a Python object representing
the parsed data structure. It is done because parsing a big test description file is quite slow.
So, it is needed to be done only once or if you modify the test descriptino file.
So, it is needed to be done only once or if you modify the test description file.
Then the tests can be processed to configure the test environment with
Then, the tests can be processed to configure the test environment with
python processTests.py -f Output.pickle
@ -334,14 +334,18 @@ or just
python processTests.py
You can also use the -e option (for embedded). It will include all the patterns (for the selected tests) into a C array. It is the preferred method if you want to run on a board. In below examples, we will
always use -e option.
python processTests.py -e
You can pass a C++ class to specifiy that you want to generate tests only for a specific group or suite.
python processTests.py BasicTests
python processTests.py -e BasicTests
You can add a test ID to specify that you wan to run only a specific test in the suite:
python processTests.py BasicTests 4
python processTests.py -e BasicTests 4
Before filtering desc.txt by using a C++ class, you should (at least once) parse the full file without filtering.
@ -359,7 +363,7 @@ If BENCHMARK=ON is used, other options should be enabled to have better performa
### Build and run the tests
Folder Output/BasicMaths should exist. For example, on windows with ArmDS:
Folder Output/BasicMaths should exist. For example, on Windows with ArmDS:
cd build
make VERBOSE=1
@ -368,7 +372,7 @@ Folder Output/BasicMaths should exist. For example, on windows with ArmDS:
### Parse the results
cd ..
python processResult.py -r build\result.txt
python processResult.py -e -r build\result.txt
-e option is needed if the mode -e was used with processTests because the output has a different
format with or without -e option.
@ -382,6 +386,10 @@ The script summaryBench can parse those results and compute regression formula.
python summaryBench.py -r build\result.txt
The file result.txt must be placed inside the build folder for this script to work.
Indeed, this script is using the path to result.txt to also find the file currentConfig.csv which has
been created by the cmake command.
The Output.pickle file is used by default. It can be changed with -f option.
The output of this script may look like:
@ -409,24 +417,23 @@ Output.pickle is used by default. It can be changed with -f option.
The database must be created with createDb.sql before this script can be used.
### FPGA mode
In FPGA mode, it is slightly different.
The script processTests and processResult must be used with additional option -e
### Semihosting or FPGA mode
The script processTests and processResult must be used with additional option -e for the FPGA (embedded mode)