According to the C standard q15_t * and const q15_t * are not compatible
types which, among other things, imply that an object of type const
q15_t * can't be modified by writing to a q15_t ** or vice versa.
Programs doing this are undefined.
Because of this rule all programs using the functions read_q15x2_ia,
read_q15x2_da, read_q7x4_ia, or read_q7x4_da for reading data from an
array of constant elements will be undefined. To solve this it is not
enough to change the type of the function since this will give problems
when reading data from an array of non-const elements. To get a defined
solution I needed to switch from functions to macros to allow the
increment to be done in the original type of the pointer.
Wrong initialization code for Neon version of biquad DF2T.
Initialization function was trying to modify a const array.
Added Neon function to Doxygen output and some correction because of Doxygen.
This attempts to ensures that even on a 64bit system, the array access
will be treated as a negative number, not a large unsigned offset ending
up reading from the middle of nowhere.
Solve most of f16 issues. But there are still some remaining
build issues with gcc10q4.
2 functions are reverting to scalar version when build with gcc on M55.
(Since Helium versions of those functions are not building).
There is a small typo in CMSIS/DSP/Source/FilteringFunctions/arm_conv_fast_opt_q15.c, CMSIS/DSP/Source/FilteringFunctions/arm_conv_opt_q15.c, CMSIS/DSP/Source/FilteringFunctions/arm_conv_opt_q7.c, CMSIS/DSP/Source/FilteringFunctions/arm_conv_partial_fast_opt_q15.c, CMSIS/DSP/Source/FilteringFunctions/arm_conv_partial_opt_q15.c, CMSIS/DSP/Source/FilteringFunctions/arm_conv_partial_opt_q7.c, CMSIS/DSP/Source/FilteringFunctions/arm_correlate_fast_opt_q15.c, CMSIS/DSP/Source/FilteringFunctions/arm_correlate_opt_q15.c, CMSIS/DSP/Source/FilteringFunctions/arm_correlate_opt_q7.c.
Should read `accumulate` rather than `accumlate`.
Johan Bengtsson
Christophe Favergeon
JbR
David Green
Tim Gates
Kishinami
GuentherMartin