Code processing time takes too long. I'm using STM32L476JGYx.

[Min-Kyoung Kim]

I'm using SPI Communication in STM32L476JGYx.

But the code processing time takes too long.

[Sensor_IO_SPI_Read] function takes 2 micro sec.

After that, I calculated the received raw data.

But, it took more 30 micro sec. (32 micro sec)

Below, the calculating code is here.

	ctx->pDataRX->Axis_x = (float)((-1.0f) * raw_data_tmp.i16bit[0] * ctx->sensitivity * M_PI / 180.0f);
	ctx->pDataRX->Axis_y = (float) ((-1.0f) * raw_data_tmp.i16bit[1] * ctx->sensitivity * M_PI / 180.0f);
	ctx->pDataRX->Axis_z = (float) ((-1.0f) * raw_data_tmp.i16bit[2] * ctx->sensitivity * M_PI / 180.0f);

What happened in my code.....?

Below, I attach my clock configuration.

[S.Ma]

Try to calculate without float as mucg as possible and especially outside interrupt service routine.

[After Forever]

M_PI is defined as double, so all the calculation in your expression is done in double precision without using hardware acceleration. use (float)M_PI.

Also make sure the hardware FPU is enabled and the compiler is configured to use it. See the disassembly code to make sure FPU is being used.

[AvaTar]

> M_PI is defined as double, ...

Not necessarily. In PC based math.h header files, it is, though.

But as mentioned, there is no need to use floats at all.

And if using float, be careful with interrupts. When normal and interrupt code uses the FPU, half of the FPU regs need to be added to the stack frame, increasing latency and stack requirements.

If the FPU regs are not saved, you will find out quickly...

[After Forever]

> Not necessarily. In PC based math.h header files, it is, though

Hmm, I think it's in the standard that the unprefixed math functions like sin, cos and the others are operating on doubles, so those constants (which are not in the C standard) in <math.h> are most likely to doubles too. Even AVR-GCC defines M_PI as double. [Click Show More]

> there is no need to use floats at all

I don't see any suggested alternative solution. Maybe OP doesn't know about fixed point math or just can't use it here for some reason or FPU is better suited for his project or whatever.

Good point about FPU and interrupt context.

[AvaTar]

> Hmm, I think it's in the standard that the unprefixed math functions like sin, cos and the others are operating on doubles, so those constants (which are not in the C standard) in <math.h> are most likely to doubles too. Even AVR-GCC defines M_PI as double.

I know. But one can override this definition.

Most toolchains even have an option to "Treat all double as float". Which is dangerous IMHO, and I would never use.

> I don't see any suggested alternative solution. Maybe OP doesn't know about fixed point math or just can't use it here for some reason or FPU is better suited for his project or whatever.

An alternative suggestion makes (IMHO) only sense with more context information.

But generally, you don't gain accuracy by "blowing up" bits. Integer algorithms (scaled math) are sometimes a bit more complex then FP math, but faster and easier on other resources.

[Danish1]

A couple of naive points:

1. Have you turned the optimizer on in your build configuration?
2. If possible, try to pre-calculate something that is used multiple times. In your example (-1.0f) * ctx->sensitivity * M_PI / 180.0f seems to be used 3 times. You could calculate that expression once per set of calculations. But if ctx->sensitivity changes rarely, then only recalculate that expression when it changes.

The point made by After Forever about ensuring that your code is using the built-in FPU is also important.

Hope this helps,

Danish

[S.Ma]

Also put the math in the special core sram to run faster. McC?

[S.Ma]

Worst case like in 8 bit mcu, digitize your sin, cos, etc as a limited points then use linear intetpolation between 2 known points of the curve. Mul mul div. Fast, good enough precision. Q32 fractional bit mode.

[Min-Kyoung Kim]

Thank you for all your comments!!

I could solve this problem thank for your comments!

I changed the code to below.

#define FROM_MDPS_TO_RAD_INV			(float)((-1.0f)*M_PI*180.0f)

That way, I can reduce the code processing time to 1 micro sec.

When I use F4, I didn't care about code processing time.

Is it because I use L4???