Problem with arm_math.h in the newest mxCube

Lukasz Przenioslo · ‎2016-07-15

Posted on July 15, 2016 at 12:35

Hello there,

I have just updated mxCube to version 4.0. I am genereting startup code for SW4STM I am using arm_math libarry. Since this version, I am getting warning I should not be getting... For example:

M:/5/Software/trunk/Embedded/eclipse_embedded_projects/SmartServo2/Drivers/CMSIS/Include/arm_math.h: In function 'arm_pid_q15':
M:/5/Software/trunk/Embedded/eclipse_embedded_projects/SmartServo2/Drivers/CMSIS/Include/arm_math.h:4889:19: warning: implicit declaration of function '__SMUAD' [-Wimplicit-function-declaration]
acc = (q31_t) __SMUAD((uint32_t)S->A0, (uint32_t)in);

And the thing is, I am not even using this __SMUAD macro, because my MCU is cortex M4 and I have the define ARM_MATH_CM4 set properly. So the preprocessor should not even consider this part of code and for some reason he is doing that and giving me a lot of warnings. Is there a way to suppress this somehow? This is the part of code in arm_math.h:

#ifndef ARM_MATH_CM0_FAMILY
__SIMD32_TYPE *vstate;
/* Implementation of PID controller */
/* acc = A0 * x[n] */
acc = (q31_t) __SMUAD((uint32_t)S->A0, (uint32_t)in);
/* acc += A1 * x[n-1] + A2 * x[n-2] */
vstate = __SIMD32_CONST(S->state);
acc = (q63_t)__SMLALD((uint32_t)S->A1, (uint32_t)*vstate, (uint64_t)acc);
#else
/* acc = A0 * x[n] */
acc = ((q31_t) S->A0) * in;
/* acc += A1 * x[n-1] + A2 * x[n-2] */
acc += (q31_t) S->A1 * S->state[0];
acc += (q31_t) S->A2 * S->state[1];
#endif

ARM_MATH_CM0_FAMILY

is not defined in my project, so why does he give the warning? I would appreciate all help.

Tesla DeLorean · ‎2016-07-15

Posted on July 15, 2016 at 13:19

Note it is an #ifndef not an #ifdef

Check if all include files are from the same version/time.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Lukasz Przenioslo · ‎2016-07-15

Posted on July 15, 2016 at 13:46

You are right, I havent noticed that. In that case I dont understand why doesnt he see the functions. __QADD for example is in file cmsis_gcc.h and I can follow the symbol there.

__attribute__( ( always_inline ) ) __STATIC_INLINE uint32_t __QADD16(uint32_t op1, uint32_t op2)
{
uint32_t result;
__ASM volatile (''qadd16 %0, %1, %2'' : ''=r'' (result) : ''r'' (op1), ''r'' (op2) );
return(result);
}

Lukasz Przenioslo · ‎2016-07-15

Posted on July 15, 2016 at 14:03

Also, this is the arm_mat_add_qc file header:

/* ---------------------------------------------------------------------- 
* Copyright (C) 2010-2014 ARM Limited. All rights reserved. 
* 
* $Date:  March 2015
* $Revision: V.1.4.5
* 
* Project: CMSIS DSP Library 
* Title: arm_mat_add_qc 
* 
* Description: Q15 matrix addition 
* 
* Target Processor: Cortex-M4/Cortex-M3/Cortex-M0

and this is arm_math.h:

/* ----------------------------------------------------------------------
* Copyright (C) 2010-2015 ARM Limited. All rights reserved.
*
* $Date:  October 2015
* $Revision: V1.4.5 b
*
* Project: CMSIS DSP Library
* Title: arm_math.h
*
* Description: Public header file for CMSIS DSP Library
*
* Target Processor: Cortex-M7/Cortex-M4/Cortex-M3/Cortex-M0

I have listed all the warning here:

https://pastebin.com/9GWXzsxD

Please notice that I am not even using those functions ie. arm_pid_q15 in the code,

waclawek.jan · ‎2016-07-15

Posted on July 15, 2016 at 15:27

> Problem with arm_math.h in the newest mxCube

You mean, CubeMX, presumably. The problem is, more precisely, with a new version of Cube (and, indirectly, new version of the ARM CMSIS headers).

Those __SMUAD, __SMLALD etc. are SIMD intrinsics, and for Cortex-M4 they are defined through core_cmSimd.h. Their definition is compiler-dependent. Previously, a chain of #ifdef/#elif directly in core_ cmSimd.h contained directly the inline-code/#defines needed for these intrinsics; now, that chain contains #includes to headers individual to particular toolchains.

So, ultimately, this boils down to the set of implicit defines which come with your particular toolchain. You should learn, from the documentation coming with your toolchain, how to output all these defines from the preprocessor, and/or observe the preprocessed output of a simple source which contains only an #include of arm_math.h.

JW

Lukasz Przenioslo · ‎2016-07-15

Posted on July 15, 2016 at 15:33

I am using the openSTM32 toolchain that comes with the plugin. Could you please more clarify what can I do about this situation?

Lukasz Przenioslo · ‎2016-07-17

Posted on July 17, 2016 at 22:21

Waclawek, could you please extend you answer? I would really like to fix this annoying problem but I am not sure how to proceed from what you have provided. I would appreciate further help.

Tesla DeLorean · ‎2016-07-17

Posted on July 18, 2016 at 00:26

Most compilers provide an option to output the results of the Pre-Processor pass.

Most tools have the defines output in the object file as a debug/diagnostic record.

Find something that works, and ensure you pass in the same command line defines to the compiler for the chip/build in question. Review Project files for different tools chains, review makefiles for GNU/GCC

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

George Ruinelli · ‎2016-08-25

Posted on August 25, 2016 at 14:34

Hmm, that doesn't really help me :(

Using Eclipse, what would need to be done?

I expect to need to include a header file somewhere, but can't come up with the right place for it.

Note that I already have the symbol ARM_MATH_CM7 defined!

Tesla DeLorean · ‎2016-08-25

Posted on August 25, 2016 at 15:16

I expect to need to include a header file somewhere, but can't come up with the right place for it.

Immediately before you use the functions it describes?

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..