Giter VIP home page Giter VIP logo

arm-software / cmsis-dsp Goto Github PK

View Code? Open in Web Editor NEW
425.0 16.0 113.0 68.42 MB

CMSIS-DSP embedded compute library for Cortex-M and Cortex-A

Home Page: https://arm-software.github.io/CMSIS-DSP

License: Apache License 2.0

C 63.59% Shell 0.02% Makefile 0.02% Batchfile 0.04% Python 2.72% Jupyter Notebook 21.73% C++ 11.42% CMake 0.23% Assembly 0.10% Roff 0.13%
cortex-a cortex-m dsp embedded fft filter matrix ml numpy fixed-point-arithmetic

cmsis-dsp's Introduction

CMSIS-DSP

GitHub release (latest by date including pre-releases) GitHub

About

CMSIS-DSP is an optimized compute library for embedded systems (DSP is in the name for legacy reasons).

It provides optimized compute kernels for Cortex-M and for Cortex-A.

Different variants are available according to the core and most of the functions are using a vectorized version when the Helium or Neon extension is available.

This repository contains the CMSIS-DSP library and several other projects:

  • Test framework for bare metal Cortex-M or Cortex-A
  • Examples for bare metal Cortex-M
  • ComputeGraph
  • PythonWrapper

You don't need any of the other projects to build and use CMSIS-DSP library. Building the other projects may require installation of other libraries (CMSIS), other tools (Arm Virtual Hardware) or CMSIS build tools.

License Terms

CMSIS-DSP is licensed under Apache License 2.0.

CMSIS-DSP Kernels

Kernels provided by CMSIS-DSP (list not exhaustive):

  • Basic mathematics (real, complex, quaternion, linear algebra, fast math functions)
  • DSP (filtering)
  • Transforms (FFT, MFCC, DCT)
  • Statistics
  • Classical ML (Support Vector Machine, Distance functions for clustering ...)

Kernels are provided with several datatypes : f64, f32, f16, q31, q15, q7.

Python wrapper

A PythonWrapper is also available and can be installed with:

pip install cmsisdsp

With this wrapper you can design your algorithm in Python using an API as close as possible to the C API. The wrapper is compatible with NumPy. The wrapper is supporting fixed point arithmetic. This wrapper works in google colab.

The goal is to make it easier to move from a design to a final implementation in C.

Compute Graph

CMSIS-DSP is also providing an experimental static scheduler for compute graph to describe streaming solutions:

  • You define your compute graph in Python
  • A static and deterministic schedule (computed by the Python script) is generated
  • The static schedule can be run on the device with low overhead

The Python scripts for the static scheduler generator are part of the CMSIS-DSP Python wrapper.

The header files are part of the CMSIS-DSP pack (version 1.10.2 and above).

The Compute Graph makes it easier to implement a streaming solution : connecting different compute kernels each consuming and producing different amount of data.

Support / Contact

For any questions or to reach the CMSIS-DSP team, please create a new issue in https://github.com/ARM-software/CMSIS-DSP/issues

Table of content

Building for speed

CMSIS-DSP is used when you need performance. As consequence CMSIS-DSP should be compiled with the options giving the best performance:

Options to use

  • -Ofast must be used for best performances.
  • When using Helium it is strongly advised to use -Ofast
  • GCC is currently not giving good performances when targeting Helium. You should use the Arm compiler

When float are used, then the fpu should be selected to ensure that the compiler is not using a software float emulation.

When building with Helium support, it will be automatically detected by CMSIS-DSP. For Neon, it is not the case and you must enable the option -DARM_MATH_NEON for the C compilation. With cmake this option is controlled with -DNEON=ON.

  • -DLOOPUNROLL=ON can also be used when compiling with cmake
  • It corresponds to the C options -DARM_MATH_LOOPUNROLL

Compilers are doing unrolling. So this option may not be needed but it is highly dependent on the compiler. With some compilers, this option is needed to get better performances.

Speed of memory is important. If you can map the data and the constant tables used by CMSIS-DSP in DTCM memory then it is better. If you have a cache, enable it.

Options to avoid

  • -fno-builtin
  • -ffreestanding because it enables previous options

The library is doing some type punning to process word 32 from memory as a pair of q15 or a quadruple of q7. Those type manipulations are done through memcpy functions. Most compilers should be able to optimize out those function calls when the length to copy is small (4 bytes).

This optimization will not occur when -fno-builtin is used and it will have a very bad impact on the performances.

Some compiler may also require the use of option -munaligned-access to specify that unaligned accesses are used.

Half float support

f16 data type (half float) has been added to the library. It is useful only if your Cortex has some half float hardware acceleration (for instance with Helium extension). If you don't need f16, you should disable it since it may cause compilation problems. Just define -DDISABLEFLOAT16 when building.

How to build

You can build CMSIS-DSP with the open CMSIS-Pack, or cmake, or Makefile and it is also easy to build if you use any other build tool.

How to build with MDK or Open CMSIS-Pack

The standard way to build is by using the CMSIS pack technology. CMSIS-DSP is available as a pack.

This pack technology is supported by some IDE like Keil MDK or Keil studio.

You can also use those packs using the Open CMSIS-Pack technology and from command line on any platform.

You should first install the tools from https://github.com/Open-CMSIS-Pack/devtools/tree/main/tools

You can get the CMSIS-Toolbox which is containing the package installer, cmsis build and cmsis project manager. Here is some documentation:

Once you have installed the tools, you'll need to download the pack index using the cpackget tool.

Then, you'll need to convert a solution file into .cprj. For instance, for the CMSIS-DSP Examples, you can go to:

Examples/cmsis_build

and then type

csolution convert -s examples.csolution_ac6.yml

This command processes the examples.csolution_ac6.yml describing how to build the examples for several platforms. It will generate lots of .cprj files that can be built with cbuild.

If you want to build the FFT example for the Corstone-300 virtual hardware platform, you could just do:

cbuild "fftbin.Release+VHT-Corstone-300.cprj"

How to build with Make

There is an example Makefile in Source.

In each source folder (like BasicMathFunctions), you'll see files with no _datatype suffix (like BasicMathFunctions.c and BasicMathFunctionsF16.c).

Those files are all you need in your makefile. They are including all other C files from the source folders.

Then, for the includes you'll need to add the paths: Include, PrivateInclude and, since there is a dependency to CMSIS Core, Core/Include from CMSIS_5/CMSIS.

If you are building for Cortex-A and want to use Neon, you'll also need to include ComputeLibrary/Include and the source file in ComputeLibrary/Source.

How to build with cmake

Create a CMakeLists.txt and inside add a project.

Add CMSIS-DSP as a subdirectory. The variable CMSISDSP is the path to the CMSIS-DSP repository in below example.

cmake_minimum_required (VERSION 3.14)

# Define the project
project (testcmsisdsp VERSION 0.1)

add_subdirectory(${CMSISDSP}/Source bin_dsp)

CMSIS-DSP is dependent on the CMSIS Core includes. So, you should define CMSISCORE on the cmake command line. The path used by CMSIS-DSP will be ${CMSISCORE}/Include.

You should also set the compilation options to use to build the library.

If you build for Helium, you should use any of the option MVEF, MVEI or HELIUM.

If you build for Neon, use NEON and/or NEONEXPERIMENTAL.

Launching the build

Once cmake has generated the makefiles, you can use a GNU Make to build.

make VERBOSE=1

How to build with any other build system

You need the following folders:

  • Source
  • Include
  • PrivateInclude
  • ComputeLibrary (only if you target Neon)

In Source subfolders, you may either build all of the source file with a datatype suffix (like _f32.c), or just compile the files without a datatype suffix. For instance for BasicMathFunctions, you can build all the C files except BasicMathFunctions.c and BasicMathFunctionsF16.c, or you can just build those two files (they are including all of the other C files of the folder).

f16 files are not mandatory. You can build with -DDISABLEFLOAT16

How to build for aarch64

The intrinsics defined in Core_A/Include are not available on recent Cortex-A processors.

But you can still build for those Cortex-A cores and benefit from the Neon intrinsics.

You need to build with -D__GNUC_PYTHON__ on the compiler command line. This flag was introduced for building the Python wrapper and is disabling the use of CMSIS Core includes.

When this flag is enabled, CMSIS-DSP is defining a few macros used in the library for compiler portability:

#define  __ALIGNED(x) __attribute__((aligned(x)))
#define __STATIC_FORCEINLINE static inline __attribute__((always_inline)) 
#define __STATIC_INLINE static inline

If the compiler you are using is requiring different definitions, you can add them to arm_math_types.h in the Include folder of the library. MSVC and XCode are already supported and in those case, you don't need to define -D__GNUC_PYTHON__

Then, you need to define -DARM_MATH_NEON

For cmake the equivalent options are:

  • -DHOST=ON
  • -DNEON=ON

cmake is automatically including the ComputeLibrary folder. If you are using a different build, you need to include this folder too to build with Neon support.

Code size

Previous versions of the library were using compilation directives to control the code size. It was too complex and not available in case CMSIS-DSP is only delivered as a static library.

Now, the library relies again on the linker to do the code size optimization. But, this implies some constraints on the code you write and new functions had to be introduced.

If you know the size of your FFT in advance, use initializations functions like arm_cfft_init_64_f32 instead of using the generic initialization functions arm_cfft_init_f32. Using the generic function will prevent the linker from being able to deduce which functions and tables must be kept for the FFT and everything will be included.

There are similar functions for RFFT, MFCC ...

If the flag ARM_DSP_CONFIG_TABLES is still set, you'll now get a compilation error to remind you that this flag no more have any effect on code size and that you may have to rework the initializations.

Folders and files

The only folders required to build and use CMSIS-DSP Library are:

  • Source
  • Include
  • PrivateInclude
  • ComputeLibrary (only when using Neon)

Other folders are part of different projects, tests or examples.

Folders

  • cmsisdsp

    • Required to build the CMSIS-DSP PythonWrapper for the Python repository
    • It contains all Python packages
  • ComputeLibrary:

    • Some kernels required when building CMSIS-DSP with Neon acceleration
  • Examples:

    • Examples of use of CMSIS-DSP on bare metal Cortex-M
    • Require the use of CMSIS Build tools
  • Include:

    • Include files for CMSIS-DSP
  • PrivateInclude:

    • Some include needed to build CMSIS-DSP
  • PythonWrapper:

    • C code for the CMSIS-DSP PythonWrapper
    • Examples for the PythonWrapper
  • Scripts:

    • Debugging scripts
    • Script to generate some coefficient tables used by CMSIS-DSP
  • Compute Graph:

    • Not needed to build CMSIS-DSP. This project is relying on CMSIS-DSP library
    • Examples for the Compute Graph
    • C++ templates for the Compute Graph
    • Default (and optional) nodes
  • Source:

    • CMSIS-DSP source
  • Testing:

    • CMSIS-DSP Test framework for bare metal Cortex-M and Cortex-A
    • Require the use of CMSIS build tools

Files

Some files are needed to generate the PythonWrapper:

  • PythonWrapper_README.md
  • LICENSE
  • MANIFEST.in
  • pyproject.toml
  • setup.py

And we have a script to make it easier to customize the build:

  • cmsisdspconfig.py:
    • Web browser UI to generate build configurations (temporary until the CMSIS-DSP configuration is reworked to be simpler and more maintainable)

cmsis-dsp's People

Contributors

a1lu avatar cdknorow avatar christophe0606 avatar clamar01 avatar dangorogoro avatar davemgreen avatar dependabot[bot] avatar dflogeras avatar fabklein avatar felixvanoost avatar gorgonmeducer avatar guenthermartin avatar jbr-smtg avatar jkrech avatar johan-uden avatar jonatanantoni avatar keilchris avatar kevingoh avatar killua-killua avatar ldong-arm avatar madcowswe avatar rsaxvc avatar silfurion avatar stephanosio avatar tfosdike avatar timgates42 avatar torfinnberset avatar ttornblom avatar vovamarch avatar xenuiswatching avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

cmsis-dsp's Issues

Pre-compiled CMSIS-DSP

Hi, sorry if it is the wrong place to ask this kind of question

I have a project built on Make, with included pre-compiled math library libarm_cortexM4lf_math.a. Then I started moving to the CMSIS-5, as I can play with it in python (many thanks for that!). But I found that it is not easy to build this library and can't find any compiled version. In case I will build it by myself I see some potential problems, such another gcc version that has not been tested or wrong compiler flags.

Could you suggest any solution for that? Is there any place where I can find already compiled version or some reliable way to compile it by myself?

Thank you!

While loop replaced by for loop

ARM-software/CMSIS_5#779

CMSIS-DSP is using while loop with decrementing counter.

For compiler point of view, it may be easier to use for loop and array indexing.

This is also related to this other github issue about pointer indexing : #20

Unfortunately, those changes are highly compiler dependent and not always giving more performant code.

Q formats should not be used as storage types

If I look at arm_dot_prod_q15, the comment of the function is:

The return result is in 34.30 format

and the return type is q63_t

So q63_t is here used as a storage type. The real fixed type being q34_30_t

The same problems is present in every function where the datatype are not q63, q15 or q7 but other fixed point types are used.

This should be improved.

Why the Q15 type of matrix multiplication is transposed, while its Q31 type is not transposed ?

  1. I'm curious about why a transposition is carried out before multiplication in the function arm_mat_mult_fast_q15 , while there is no transposition in the function arm_mat_mult_fast_q31. But transposition can also bring better performance for function arm_mat_mult_fast_q31 actually.
  2. Function arm_mat_mult_q15 also has an input "pState", but also has not do the transposition.
    Would you please give an explanation?Thanks a lot!

Controlling optimization levels

I generally like to build CMSIS DSP with optimizations. Right now I am doing something like this:

target_compile_options(CMSISDSP PUBLIC "-03")

in my CmakeLists.txt

Is there a better option?

Table config error in RFFT F32 for MVEF

I've been trying to restrict tables from a Helium build, and hit an error in the conditionalising of the RFFT functions.

My particular case was looking to use arm_rfft_fast_init_f32(1024).

This conditionalises on ARM_TABLE_BITREVIDX_FLT_512, but it uses arm_cfft_init_f32 which conditionalises on ARM_TABLE_BITREVIDX_FXT_512.

#if !defined(ARM_DSP_CONFIG_TABLES) || defined(ARM_ALL_FFT_TABLES) || (defined(ARM_TABLE_TWIDDLECOEF_F32_512) && defined(ARM_TABLE_BITREVIDX_FLT_512) && defined(ARM_TABLE_TWIDDLECOEF_RFFT_F32_1024))

#if !defined(ARM_DSP_CONFIG_TABLES) || defined(ARM_ALL_FFT_TABLES) || (defined(ARM_TABLE_TWIDDLECOEF_F32_512) && defined(ARM_TABLE_BITREVIDX_FLT_512) && defined(ARM_TABLE_TWIDDLECOEF_RFFT_F32_1024))

#if !defined(ARM_DSP_CONFIG_TABLES) || defined(ARM_ALL_FFT_TABLES) || (defined(ARM_TABLE_BITREVIDX_FXT_512) && defined(ARM_TABLE_TWIDDLECOEF_F32_512))

So both need to be enabled at present to make the RFFT work, although only the FXT is used, and armlink can eliminate the FLT table anyway (at least with -fdata-sections, which we've got on).

By the way, the python config helper told me to use the FLT form despite selecting Helium. I can see the code has logic to say FXT instead, but it didn't seem to activate for me. Some confusion about HELIUM versus config["HELIUM"] perhaps? And it should perhaps be switching on (MVEF && !AUTOVECTORISE) anyway.

Update the header prefixes to be architecture agnostic

I have a need for a similar math library in Zephyr which needs to work for and ideally be optimized for additional architectures beyond ARM. I was wondering if it would be possible to rename the headers and replace the arm_ prefix with cmsis_? the arm_ prefixed headers can still exist and simply include their generic counterparts. This would allow us to provide Zephyr implementations for non arm optimized math logic.

Reference zephyrproject-rtos/zephyr#50012

Fixed-Point Helium Complex Multiplication saturation sensitivy

Combining vqdmlsdh and vqdmladhx for running complex multiplications operations on full scale vectors is likely to saturate
It would be safer to downscale the inputs prior to the multiplication.

arm_cmplx_mult_cmplx_q15/q31 would be modified the following way

{
            vecSrcA = vld1q(pSrcA);    pSrcA += ELTS(vecSrcA);
            vecSrcB = vld1q(pSrcB);    pSrcB += ELTS(vecSrcB);

           /* downscale inputs */          
            vecSrcA >>= 1;
            vecSrcB >>= 1;
         
            vecDst = vqdmlsdhq(vuninitializedq(vecSrcA), vecSrcA, vecSrcB);
            vecDst = vqdmladhxq(vecDst, vecSrcA, vecSrcB);

           vst1q(pDst, vecDst);           pDst += ELTS(vecDst);
}

In this case downscaling of the result before storing must be removed

Other locations involving vqdmlsdh / vqdmladhx pairs should be verified as well

MVE integer absmax functions can return -1.0

Looking at the MVE implementation of arm_absmax_no_idx_q15 (q31 and q7 are analogous), if the data contains 0x8000, it returns this as the result. This is not what the other implementations do.

curExtremValVec is correctly modelled as unsigned (VMAXA produces unsigned results from 0 to 0x8000), but the final gathering uses vmaxavq instead of an unsigned vmaxvq on it, with this type mismatch being indicated by the presence of the cast to q15x8_t. (Doesn't change the result directly, but contributes to the type confusion).

Then the final uint16_t from vmaxvq needs to be saturated to get the q15_t result from 0 to 0x7fff.

The non-no_idx implementations seem to be okay, just looking at the result, not inspecting the implementations.

Many MVE tables are not const-qualified

Many constant tables in arm_mve_tables.c and arm_mve-tables_f16.c have no const qualifier, so end up being copied to RAM.

A little over 1.5K of RAM is being used for fft1024 alone.

Pythonwrapper sometimes crashes with arm_fir_decimate_f32

Hello

The code below mostly runs fine when running it as a script. But if running it in interactive mode or trying to debug it, it crashes without any clear error at the arm_fir_decimate_f32 call.

Edit: This is on Windows

Maybe it's a segmentation fault because of some error in reference counting in the C code, and hence, too early garbage collection? (I'm not an expert on the python <-> C interface)

Code:

# %%
import cmsisdsp as dsp
import matplotlib.pyplot as plt
from scipy import signal
import numpy as np
import sys
# %%

test_length_seconds = 0.1
frequency = 87
us_length_buffers = int(np.ceil(test_length_seconds * (12000/32)))
us_length_samples = int(us_length_buffers * 32)
ds_length_buffers = int(np.ceil(test_length_seconds * (16000/32)))
ds_length_samples = int(ds_length_buffers * 32)
ds_source = np.sin(2*np.pi*frequency*np.linspace(0,test_length_seconds,ds_length_samples))
us_source = np.sin(2*np.pi*frequency*np.linspace(0,test_length_seconds,us_length_samples))

# %% Downsampling
ds_zero_stuffed = np.zeros(ds_source.size*3)
ds_zero_stuffed[::3] = ds_source
# %% 
ds_filter = signal.firwin(9,0.25)
ds_state = np.zeros(12)
decimator = dsp.arm_fir_decimate_instance_f32()
dsp.arm_fir_decimate_init_f32(decimator, 9,4, ds_filter, ds_state)
output = dsp.arm_fir_decimate_f32(decimator,ds_zero_stuffed)
output = output[:ds_zero_stuffed.size//4]*3
print(output)
# %%

In-place operations

Hi,

I'm wondering what, if any linear algebra methods support in-place operations. I expect the elementwise operations (e.g. scaling, addition, etc.) should but it's not mentioned in the documentation.

Thanks!

MVE arm_correlate_f32 may write to negative pDst index

MVE arm_correlate_f32 implementation may write to a negative pDst index (before the beginning of the pDst buffer).

This happens when incr is a negative number.

This is observed when running the following test cases:

case MISCF32::TEST_CORRELATE_F32_4:
{
this->nba = 4;
this->nbb = 8;
ref.reload(MISCF32::REF4_F32_ID,mgr);
}
break;

case MISCF32::TEST_CORRELATE_F32_5:
{
this->nba = 4;
this->nbb = 11;
ref.reload(MISCF32::REF5_F32_ID,mgr);
}
break;

case MISCF32::TEST_CORRELATE_F32_14:
{
this->nba = 6;
this->nbb = 8;
ref.reload(MISCF32::REF14_F32_ID,mgr);
}
break;

case MISCF32::TEST_CORRELATE_F32_15:
{
this->nba = 6;
this->nbb = 11;
ref.reload(MISCF32::REF15_F32_ID,mgr);
}
break;

case MISCF32::TEST_CORRELATE_F32_25:
{
this->nba = 10;
this->nbb = 11;
ref.reload(MISCF32::REF25_F32_ID,mgr);
}
break;

MVE arm_scale_q15 does not operate as specified

The MVE implementation of arm_scale_q15 does not use a 2.30 intermediate, as per the documentation and other implementations, but truncates the multiplication immediately to 2.14. This reduces the output range and produces irregular steps when scaling up significantly, for example, in extremis:

Given scaleFract = 0x6666, shift = 13

input 2.30 intermediate non-MVE result 2.14 intermediate MVE result
0x0000 0x00000000 0x0000 0x0000 0x0000
0x0001 0x00006666 0x1999 0x0000 0z0000
0x0002 0x0000CCCC 0x3333 0x0000 0x0000
0x0003 0x00013332 0x4CCC 0x0001 0x4000
0x0004 0x00019998 0x6666 0x0001 0x4000
0x0005 0x0001FFFE 0x7FFF 0x0001 0x4000

I've not checked how far this extends to other MVE variants - this was the function I was using and noticed.

aarch64 support

Some build issues reported for cortex-a76 / cortex-a55:

qsub intrinsics not supported. But the CMSIS Core_A/Include has not compilation flag to disable the definition of intrinsics like qsub.

In arm_max_f32 and arm_min_f32:

/home/sandal/CMSIS_5_BK/CMSIS/DSP/Source/StatisticsFunctions/arm_max_f32.c:168:24: warning: conversion fromlong unsigned inttouint32_t’ {akaunsigned int’} changes value from18446744073709551615to
4294967295’ [-Woverflow]
  168 |   maxIdx = vdupq_n_u32(ULONG_MAX);

ULONG_MAX is 32 bits so I don't understand why the value is 64 bits according to the compiler.

issue when implementing IIR filter designed by scipy

Hi,

I am trying to reproduce an IIR filter designed with scipy using CMSIS DSP library on a cortex-M7 device.

Here comes my filter design in python environment:


In [5]: from scipy import signal                                                
In [6]: b,a=signal.iirfilter(1,[0.01126,0.03050])                               
In [7]: b,a                                 
Out[7]: 
(array([ 0.02934421,  0.        , -0.02934421]),
 array([ 1.        , -1.93802145,  0.94131158]))

In [8]: signal.lfilter(b,a,[1,2])                                               
Out[8]: array([0.02934421, 0.11555813])

Here is my implementation using CMSIS DSP, note that I've negated the a[1:] coeffs below:

#define IIR_NUMSTAGES 1
#define IIR_ORDER 2
float32_t _iir_states[IIR_ORDER]={0};
float32_t _iir_coeffs[5*IIR_NUMSTAGES] = { 0.02934421, 0. , -0.02934421, 1.93802145, -0.94131158};
arm_biquad_cascade_df2T_instance_f32 _iir = {IIR_NUMSTAGES, _iir_coeffs, _iir_states};
float32_t x[] = {1, 2};
float32_t exp_y[] = {0.02934421, 0.11555813};
float32_t y[ARRAY_LEN(x)];
arm_biquad_cascade_df2T_f32(&amp;_iir, x, y, ARRAY_LEN(x));

But the C implementation outputs {0.0293442104, -0.00465790788} on the cortex-m7 MCU.
This result is different from the scipy output.

Regards,
yf13

arm_fir_f64 documentation

Documentation for fir f64 must be corrected. Current one is a copy / paste of the documentation for fir f32 and it is confusing since f64 implementation has no Helium code.

Cortex-A build warning : vlogq_f32 definitions

/DSP/ComputeLibrary/Include/NEMath.h:394:79: warning: ‘vlogq_f32is static but used in inline functionvlogq_f16which is not static
  394 |     const float16x8_t res = vcvt_high_f16_f32(vcvt_f16_f32(vlogq_f32(x_low)), vlogq_f32(x_high));

static keyword missing

Improve consistency with different compilers

The following two header files should be modified as shown so that when compiling with Arm Clang or GCC on Ubuntu, the C function macros and the inline intrinsic functions are used. I believe this is correct, unless there is additional setup I missed? In my use-case I compile only the individual DSP function-files that are needed rather than linking the library. I'm building on these two non-Arm platforms as a simple reference-code example that is portable to any OS (EEMBC's AudioMark benchmark) with the intention that an Arm target would use NEON and the enhancements.

arm_math_types.h

#elif defined ( __APPLE_CC__ ) || defined ( __GNUC__ )
#include <stdint.h>
#define  __ALIGNED(x) __attribute__((aligned(x)))
#define __STATIC_FORCEINLINE static inline __attribute__((always_inline)) 
#define __STATIC_INLINE static inline

dsp/none.h

#if defined ( _MSC_VER ) || defined(__GNUC_PYTHON__) || defined(__APPLE_CC__) || defined (__GNUC__)
    __STATIC_FORCEINLINE uint8_t __CLZ(uint32_t data)
    {
      if (data == 0U) { return 32U; }

      uint32_t count = 0U;
      uint32_t mask = 0x80000000U;

      while ((data & mask) == 0U)
      {
        count += 1U;
        mask = mask >> 1U;
      }
      return count;
    }
:
:

arm_vsi.h is missing

This library does not compile. arm_vsi.h is missing. Same ARMCM3.h used in startup_ARMCM3.c.
This may indicate a serious flaw in testing approach/release policy.
It seems that this library is not yet at a state where it could be just included with another project, which probably was its original purpose.

Matching MFCC configuration with Librosa's

Hello,

I am trying to replicate the MFCC output of Librosa, which is widely used as the reference library for audio manipulation.

   mfccs = librosa.feature.mfcc(y=data,
        sr=16000,
        n_mfcc=32,
        n_fft = 2048,
        hop_length = 1024,
        window='hamming',
        center=False,            # for padding, not used
        pad_mode='constant',    # for padding, not used
        power=2.0,
        n_mels=32,
        fmin=64,
        fmax=8000,
        dct_type=2,
        norm='ortho'
        )

On my ARM microcontroller, I am using the arm_mfcc_f32 callback and the arm_mfcc_init_f32 to initialize the parameters.
The parameters have been generated with the scripts from this repository.

Generally, I would expect some small deviation from the results on the two platforms, since CMSIS uses approximated calculations for logarithms, etc; however, I found that the outputs are completely different (one order of magnitude, sign).

I also could not find a clear explanation of which parameters are used in the CMSIS implementation for power, dct_type, and norm.
Am I missing some steps? Or is this expected altogether?

I believe this would be quite important to clarify, to allow people to design a data pipeline that can be quite reproducible in the microcontroller :)

tables/function placement macros/options

On Cortex M7 targets such the i.MXRT10xx family, it is important to be able to control memory placement of the functions/tables for best performance. For example, the default placement of functions and twiddle tables into the QSPI flash region. IN previous versions of the CMSIS DSP, I would keep a local copy of the source in my repo and "patch" functions and tables like this:

FAST_DATA_RAM const q15_t ALIGN4 realCoefAQ15[8192] = {
    (q15_t)0x4000, (q15_t)0xc000, (q15_t)0x3ff3, (q15_t)0xc000, (q15_t)0x3fe7, (q15_t)0xc000, (q15_t)0x3fda, (q15_t)0xc000,
 .
.
.

FAST_DATA_RAM would be defined elsewhere so I easily place the table in DTCM, etc.

It would be beneficial for the library to have some mechanism for specifying placement of the routines & tables. I am migrating to the latest version of CMSIS DSP with the cmake build flow and would like to minimize how much manually modify the library.

Error while building the BIQUAD Tests

/home/ubuntu/cmsis-dsp/CMSIS-DSP/Testing/Include/Tests/BIQUADF64.h:13:22: fatal error: 'BIQUADF64_decl.h' file not found
#include "BIQUADF64_decl.h"
^~~~~~~~~~~~~~~~~~
1 error generated.
Applies to all BIQUAD

Linear interpolation: incorrect for x outside of the table boundary

i = (int32_t) ((x - S->x1) / xSpacing);

For values, where ((x - S->x1) / xSpacing) lies within (-1.f, 0.f), the cast to int32_t results in 0 and therefore i < 0 does not apply. Hence, values outside of the table boundary are not clipped, but wrongly interpolated.
The following code fixes it for me, but results in a slight performance overhead for the float32_t comparison, instead of the original int32_t:

/* Calculation of index */
const float32_t x_diff = x - S->x1;
i                      = (int32_t)(x_diff / xSpacing);

if (x_diff < 0.f)

Jinja2 dependency

Using cmsisdsp as part of a signal processing framework, I stumbled across the limitation of Jinja2 versions. Since 2021, there is a new major release (Jinja2 3.x.y), introducing a few new features and fixes, but cmsisdsp only allows versions <= 2.

Since cmsisdsp is a dependency of mine, I cannot use the latest release of Jinja2. Is there a reason for not allowing the latest release?

Thanks in advance

GCC error - missing cast in MVE arm_biquad_cascade_df1_q15

We've had a report that GCC doesn't like the MVE version of arm_biquad_cascade_df1_q15. And its complaint seems valid:

bCoeffs2 =
vsetq_lane_s32(vgetq_lane_s32((q31x4_t) bCoeffs0, 3), (q31x4_t) bCoeffs2, 3);
bCoeffs3 =
vsetq_lane_s32(vgetq_lane_s32((q31x4_t) bCoeffs1, 3), (q31x4_t) bCoeffs3, 3);

arm_biquad_cascade_df1_q15.c:106:13: error: incompatible types when assigning to type 'q15x8_t' {aka 'int16x8_t'} from type 'int32x4_t'

I'd say you need an explicit (q15x8_t) cast on the output of vsetq_lane_s32.

What's not clear to me is why armclang accepts it, which it does. Indeed, armclang doesn't seem to require the existing (q31x4_t) casts either, at least within that C file.

Pasting the same function into some other C++ code I had handy made armclang produce the equivalent error, unless you have 3 casts. Is it performing implicit conversion in C mode, maybe? Intentionally? Possible armclang bug?

Various warnings when building with GCC 12

When building CMSIS-DSP with GCC 12.1, Wmaybe-uninitialized warnings are seen:

In function '__arm_vqmovnbq_s16',
    inlined from 'arm_float_to_q7' at /home/gmarull/ws/nordic/zephyrproject/modules/hal/cmsis/CMSIS/DSP/Source/SupportFunctions/arm_float_to_q7.c:104:18:
/home/gmarull/zephyr-sdk-0.15.0/arm-zephyr-eabi/lib/gcc/arm-zephyr-eabi/12.1.0/include/arm_mve.h:6384:10: error: 'vecDst' may be used uninitialized [-Werror=maybe-uninitialized]
 6384 |   return __builtin_mve_vqmovnbq_sv8hi (__a, __b);
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/gmarull/ws/nordic/zephyrproject/modules/hal/cmsis/CMSIS/DSP/Source/SupportFunctions/arm_float_to_q7.c: In function 'arm_float_to_q7':
/home/gmarull/ws/nordic/zephyrproject/modules/hal/cmsis/CMSIS/DSP/Source/SupportFunctions/arm_float_to_q7.c:71:21: note: 'vecDst' was declared here
   71 |     q7x16_t         vecDst;
      |                     ^~~~~~
In function '__arm_vqmovnbq_s32',
    inlined from 'arm_float_to_q7' at /home/gmarull/ws/nordic/zephyrproject/modules/hal/cmsis/CMSIS/DSP/Source/SupportFunctions/arm_float_to_q7.c:99:18:
/home/gmarull/zephyr-sdk-0.15.0/arm-zephyr-eabi/lib/gcc/arm-zephyr-eabi/12.1.0/include/arm_mve.h:6587:10: error: 'oddVec' may be used uninitialized [-Werror=maybe-uninitialized]
 6587 |   return __builtin_mve_vqmovnbq_sv4si (__a, __b);
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/gmarull/ws/nordic/zephyrproject/modules/hal/cmsis/CMSIS/DSP/Source/SupportFunctions/arm_float_to_q7.c: In function 'arm_float_to_q7':
/home/gmarull/ws/nordic/zephyrproject/modules/hal/cmsis/CMSIS/DSP/Source/SupportFunctions/arm_float_to_q7.c:70:28: note: 'oddVec' was declared here
   70 |     q15x8_t         evVec, oddVec;
      |                            ^~~~~~
In function '__arm_vqmovnbq_s32',
    inlined from 'arm_float_to_q7' at /home/gmarull/ws/nordic/zephyrproject/modules/hal/cmsis/CMSIS/DSP/Source/SupportFunctions/arm_float_to_q7.c:94:17:
/home/gmarull/zephyr-sdk-0.15.0/arm-zephyr-eabi/lib/gcc/arm-zephyr-eabi/12.1.0/include/arm_mve.h:6587:10: error: 'evVec' may be used uninitialized [-Werror=maybe-uninitialized]
 6587 |   return __builtin_mve_vqmovnbq_sv4si (__a, __b);
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/gmarull/ws/nordic/zephyrproject/modules/hal/cmsis/CMSIS/DSP/Source/SupportFunctions/arm_float_to_q7.c: In function 'arm_float_to_q7':
/home/gmarull/ws/nordic/zephyrproject/modules/hal/cmsis/CMSIS/DSP/Source/SupportFunctions/arm_float_to_q7.c:70:21: note: 'evVec' was declared here
   70 |     q15x8_t         evVec, oddVec;
      |                     ^~~~~
cc1: all warnings being treated as errors
[298/374] Building C object modules/cmsis/CMSIS/DSP/Source/SupportFunctions/CMakeFiles/..__modules__hal__cmsis__CMSIS__DSP__Source__SupportFunctions.dir/arm_q15_to_q7.c.obj
FAILED: modules/cmsis/CMSIS/DSP/Source/SupportFunctions/CMakeFiles/..__modules__hal__cmsis__CMSIS__DSP__Source__SupportFunctions.dir/arm_q15_to_q7.c.obj 
ccache /home/gmarull/zephyr-sdk-0.15.0/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc -DARM_ALL_FAST_TABLES -DARM_DSP_CONFIG_TABLES -DARM_FAST_ALLOW_TABLES -DARM_FFT_ALLOW_TABLES -DARM_TABLE_RECIP_Q15 -DARM_TABLE_RECIP_Q31 -DARM_TABLE_SIN_F32 -DARM_TABLE_SIN_Q15 -DARM_TABLE_SIN_Q31 -DKERNEL -DTC_RUNID=5daaff6597b061944ae4b8f0da905274 -D_FORTIFY_SOURCE=2 -D__LINUX_ERRNO_EXTENSIONS__ -D__PROGRAM_START -D__ZEPHYR__=1 -I/home/gmarull/ws/nordic/zephyrproject/modules/hal/cmsis/CMSIS/DSP/PrivateInclude -I/home/gmarull/ws/nordic/zephyrproject/zephyr/include -I/home/gmarull/ws/nordic/zephyrproject/zephyr/twister-out/mps3_an547/tests/lib/cmsis_dsp/filtering/libraries.cmsis_dsp.filtering.misc.fpu/zephyr/include/generated -I/home/gmarull/ws/nordic/zephyrproject/zephyr/soc/arm/arm/mps3 -I/home/gmarull/ws/nordic/zephyrproject/zephyr/lib/libc/newlib/include -I/home/gmarull/ws/nordic/zephyrproject/zephyr/subsys/testsuite/include -I/home/gmarull/ws/nordic/zephyrproject/zephyr/subsys/testsuite/ztest/include -I/home/gmarull/ws/nordic/zephyrproject/modules/hal/cmsis/CMSIS/Core/Include -I/home/gmarull/ws/nordic/zephyrproject/modules/hal/cmsis/CMSIS/DSP/Include -fno-strict-aliasing -Os -imacros /home/gmarull/ws/nordic/zephyrproject/zephyr/twister-out/mps3_an547/tests/lib/cmsis_dsp/filtering/libraries.cmsis_dsp.filtering.misc.fpu/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -gdwarf-4 -fdiagnostics-color=always -mcpu=cortex-m55 -mthumb -mabi=aapcs -mfpu=auto -mfloat-abi=hard -mfp16-format=ieee --sysroot=/home/gmarull/zephyr-sdk-0.15.0/arm-zephyr-eabi/arm-zephyr-eabi -imacros /home/gmarull/ws/nordic/zephyrproject/zephyr/include/zephyr/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-pointer-sign -Wpointer-arith -Wexpansion-to-defined -Wno-unused-but-set-variable -Werror=implicit-int -fno-pic -fno-pie -Werror -fno-asynchronous-unwind-tables -fno-reorder-functions --param=min-pagesize=0 -fno-defer-pop -fmacro-prefix-map=/home/gmarull/ws/nordic/zephyrproject/zephyr/tests/lib/cmsis_dsp/filtering=CMAKE_SOURCE_DIR -fmacro-prefix-map=/home/gmarull/ws/nordic/zephyrproject/zephyr=ZEPHYR_BASE -fmacro-prefix-map=/home/gmarull/ws/nordic/zephyrproject=WEST_TOPDIR -ffunction-sections -fdata-sections -mcmse -specs=nano.specs -std=c99 -MD -MT modules/cmsis/CMSIS/DSP/Source/SupportFunctions/CMakeFiles/..__modules__hal__cmsis__CMSIS__DSP__Source__SupportFunctions.dir/arm_q15_to_q7.c.obj -MF modules/cmsis/CMSIS/DSP/Source/SupportFunctions/CMakeFiles/..__modules__hal__cmsis__CMSIS__DSP__Source__SupportFunctions.dir/arm_q15_to_q7.c.obj.d -o modules/cmsis/CMSIS/DSP/Source/SupportFunctions/CMakeFiles/..__modules__hal__cmsis__CMSIS__DSP__Source__SupportFunctions.dir/arm_q15_to_q7.c.obj -c /home/gmarull/ws/nordic/zephyrproject/modules/hal/cmsis/CMSIS/DSP/Source/SupportFunctions/arm_q15_to_q7.c
In file included from /home/gmarull/ws/nordic/zephyrproject/modules/hal/cmsis/CMSIS/DSP/Include/arm_math_types.h:249,
                 from /home/gmarull/ws/nordic/zephyrproject/modules/hal/cmsis/CMSIS/DSP/Include/dsp/support_functions.h:30,
                 from /home/gmarull/ws/nordic/zephyrproject/modules/hal/cmsis/CMSIS/DSP/Source/SupportFunctions/arm_q15_to_q7.c:29:
In function '__arm_vqshrnbq_n_s16',
    inlined from 'arm_q15_to_q7' at /home/gmarull/ws/nordic/zephyrproject/modules/hal/cmsis/CMSIS/DSP/Source/SupportFunctions/arm_q15_to_q7.c:74:18:
/home/gmarull/zephyr-sdk-0.15.0/arm-zephyr-eabi/lib/gcc/arm-zephyr-eabi/12.1.0/include/arm_mve.h:8812:10: error: 'vecDst' may be used uninitialized [-Werror=maybe-uninitialized]
 8812 |   return __builtin_mve_vqshrnbq_n_sv8hi (__a, __b, __imm);
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/gmarull/ws/nordic/zephyrproject/modules/hal/cmsis/CMSIS/DSP/Source/SupportFunctions/arm_q15_to_q7.c: In function 'arm_q15_to_q7':
/home/gmarull/ws/nordic/zephyrproject/modules/hal/cmsis/CMSIS/DSP/Source/SupportFunctions/arm_q15_to_q7.c:63:13: note: 'vecDst' was declared here
   63 |     q7x16_t vecDst;
      |             ^~~~~~
cc1: all warnings being treated as errors
[299/374] Building C object modules/cmsis/CMSIS/DSP/Source/SupportFunctions/CMakeFiles/..__modules__hal__cmsis__CMSIS__DSP__Source__SupportFunctions.dir/arm_float_to_q15.c.obj
FAILED: modules/cmsis/CMSIS/DSP/Source/SupportFunctions/CMakeFiles/..__modules__hal__cmsis__CMSIS__DSP__Source__SupportFunctions.dir/arm_float_to_q15.c.obj 
ccache /home/gmarull/zephyr-sdk-0.15.0/arm-zephyr-eabi/bin/arm-zephyr-eabi-gcc -DARM_ALL_FAST_TABLES -DARM_DSP_CONFIG_TABLES -DARM_FAST_ALLOW_TABLES -DARM_FFT_ALLOW_TABLES -DARM_TABLE_RECIP_Q15 -DARM_TABLE_RECIP_Q31 -DARM_TABLE_SIN_F32 -DARM_TABLE_SIN_Q15 -DARM_TABLE_SIN_Q31 -DKERNEL -DTC_RUNID=5daaff6597b061944ae4b8f0da905274 -D_FORTIFY_SOURCE=2 -D__LINUX_ERRNO_EXTENSIONS__ -D__PROGRAM_START -D__ZEPHYR__=1 -I/home/gmarull/ws/nordic/zephyrproject/modules/hal/cmsis/CMSIS/DSP/PrivateInclude -I/home/gmarull/ws/nordic/zephyrproject/zephyr/include -I/home/gmarull/ws/nordic/zephyrproject/zephyr/twister-out/mps3_an547/tests/lib/cmsis_dsp/filtering/libraries.cmsis_dsp.filtering.misc.fpu/zephyr/include/generated -I/home/gmarull/ws/nordic/zephyrproject/zephyr/soc/arm/arm/mps3 -I/home/gmarull/ws/nordic/zephyrproject/zephyr/lib/libc/newlib/include -I/home/gmarull/ws/nordic/zephyrproject/zephyr/subsys/testsuite/include -I/home/gmarull/ws/nordic/zephyrproject/zephyr/subsys/testsuite/ztest/include -I/home/gmarull/ws/nordic/zephyrproject/modules/hal/cmsis/CMSIS/Core/Include -I/home/gmarull/ws/nordic/zephyrproject/modules/hal/cmsis/CMSIS/DSP/Include -fno-strict-aliasing -Os -imacros /home/gmarull/ws/nordic/zephyrproject/zephyr/twister-out/mps3_an547/tests/lib/cmsis_dsp/filtering/libraries.cmsis_dsp.filtering.misc.fpu/zephyr/include/generated/autoconf.h -ffreestanding -fno-common -g -gdwarf-4 -fdiagnostics-color=always -mcpu=cortex-m55 -mthumb -mabi=aapcs -mfpu=auto -mfloat-abi=hard -mfp16-format=ieee --sysroot=/home/gmarull/zephyr-sdk-0.15.0/arm-zephyr-eabi/arm-zephyr-eabi -imacros /home/gmarull/ws/nordic/zephyrproject/zephyr/include/zephyr/toolchain/zephyr_stdint.h -Wall -Wformat -Wformat-security -Wno-format-zero-length -Wno-main -Wno-pointer-sign -Wpointer-arith -Wexpansion-to-defined -Wno-unused-but-set-variable -Werror=implicit-int -fno-pic -fno-pie -Werror -fno-asynchronous-unwind-tables -fno-reorder-functions --param=min-pagesize=0 -fno-defer-pop -fmacro-prefix-map=/home/gmarull/ws/nordic/zephyrproject/zephyr/tests/lib/cmsis_dsp/filtering=CMAKE_SOURCE_DIR -fmacro-prefix-map=/home/gmarull/ws/nordic/zephyrproject/zephyr=ZEPHYR_BASE -fmacro-prefix-map=/home/gmarull/ws/nordic/zephyrproject=WEST_TOPDIR -ffunction-sections -fdata-sections -mcmse -specs=nano.specs -std=c99 -MD -MT modules/cmsis/CMSIS/DSP/Source/SupportFunctions/CMakeFiles/..__modules__hal__cmsis__CMSIS__DSP__Source__SupportFunctions.dir/arm_float_to_q15.c.obj -MF modules/cmsis/CMSIS/DSP/Source/SupportFunctions/CMakeFiles/..__modules__hal__cmsis__CMSIS__DSP__Source__SupportFunctions.dir/arm_float_to_q15.c.obj.d -o modules/cmsis/CMSIS/DSP/Source/SupportFunctions/CMakeFiles/..__modules__hal__cmsis__CMSIS__DSP__Source__SupportFunctions.dir/arm_float_to_q15.c.obj -c /home/gmarull/ws/nordic/zephyrproject/modules/hal/cmsis/CMSIS/DSP/Source/SupportFunctions/arm_float_to_q15.c
In file included from /home/gmarull/ws/nordic/zephyrproject/modules/hal/cmsis/CMSIS/DSP/Include/arm_math_types.h:249,
                 from /home/gmarull/ws/nordic/zephyrproject/modules/hal/cmsis/CMSIS/DSP/Include/dsp/support_functions.h:30,
                 from /home/gmarull/ws/nordic/zephyrproject/modules/hal/cmsis/CMSIS/DSP/Source/SupportFunctions/arm_float_to_q15.c:29:
In function '__arm_vqmovnbq_s32',
    inlined from 'arm_float_to_q15' at /home/gmarull/ws/nordic/zephyrproject/modules/hal/cmsis/CMSIS/DSP/Source/SupportFunctions/arm_float_to_q15.c:87:18:
/home/gmarull/zephyr-sdk-0.15.0/arm-zephyr-eabi/lib/gcc/arm-zephyr-eabi/12.1.0/include/arm_mve.h:6587:10: error: 'vecDst' may be used uninitialized [-Werror=maybe-uninitialized]
 6587 |   return __builtin_mve_vqmovnbq_sv4si (__a, __b);
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/gmarull/ws/nordic/zephyrproject/modules/hal/cmsis/CMSIS/DSP/Source/SupportFunctions/arm_float_to_q15.c: In function 'arm_float_to_q15':
/home/gmarull/ws/nordic/zephyrproject/modules/hal/cmsis/CMSIS/DSP/Source/SupportFunctions/arm_float_to_q15.c:71:21: note: 'vecDst' was declared here
   71 |     q15x8_t         vecDst;
      |                     ^~~~~~
cc1: all warnings being treated as errors

arm_sin_cos_f32: unused values

It is clearly seen that 'temp' value that is calculated on the first lines of the snippets below (parts of the arm_sin_cos_f32) is never used:

  temp = (1.0f - fract) * f1 + fract * f2;

  Dn = 0.0122718463030f; /* delta between the two points (fixed), in this case 2*pi/FAST_MATH_TABLE_SIZE */
  Df = f2 - f1;          /* delta between the values of the functions */

  temp = Dn * (d1 + d2) - 2 * Df;

  temp = (1.0f - fract) * f1 + fract * f2;

  Df = f2 - f1; // delta between the values of the functions
  temp = Dn * (d1 + d2) - 2 * Df;

Why is `dt` not used in the PID computation?

While looking at the PID Controller algorithm, I was confused by the omission of the time differential (dt) in the gains A0, A1, A2.

The algorithm used by the CMSIS library is

y[n] = y[n-1] + A0 * x[n] + A1 * x[n-1] + A2 * x[n-2]

A0 = Kp + Ki + Kd
A1 = (-Kp ) - (2 * Kd )
A2 = Kd

But, to my understanding, it should be

y[n] = y[n-1] + A0 * x[n] + A1 * x[n-1] + A2 * x[n-2]

A0 = Kp + Ki*dt + Kd/dt  //< notice dt
A1 = -Kp - 2*Kd/dt       //< notice dt
A2 = Kd/dt               //< notice dt

What is the underlying mathematical assumption here?
Is dt assumed to always be 1 ?
Or Ki and Kd should be computed with sampling time in it?

Regards,

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.