floating point calcultations within interrupts

[longchair]

Posted on November 04, 2012 at 10:25

Hello,

I am experiencing some troubles recently with floating point calculation within interrupts. I have a dma interrupt running at 400 Khz in double buffer mode. I have an usart RX interrupt coming at 50 Hz. the 400khz interrupt will drive and RGB barled very smoothly. The 50Hz interrupts decodes an RC Radio signal. the 400Khz interrupt has higher priority than the 50 Hz one. in the 50Hz interrupt, I am retrieving integer values that I wanted to scale to 0 -> 100%. If I do the floating point calculation which is basic : Y = (a - offset) / Scale, this results in a very strange behaviour (Scale and offset are constant non zero values ). My whole main loop is very much slowed (from 30hz to 2Hz). Is there any issue with using floating point calculation within interrupts?  The same calculation done in the main loop will not cause any issue.  

[GHITH.Abdelhamid]

Posted on November 04, 2012 at 10:59

there is no restriction to use FPU in ISR.

using FPU in an ISR adds some latency for ISR entry/exit. FPU frame has to be saved/restored before starting the processing.disabling the FPU context save/restore can reduce the latencies if not used any where else.maybe you can share the disassembly of the ISR to check if HW /or SW single precision operation is used.

[frankmeyer9]

Posted on November 05, 2012 at 08:46

You did not mention that you actually use an uC with FPU, say, a F3 or F4.

If not so, take a look at the assembler code. The called library routines will definitely take longer than 2.5us. I rather suggest to invest some minutes and solve your scaling in the integer realm. Multiply by 100 or 1000, do your scaling, and than divide again.

[michaelrigby-jones9]

Posted on November 13, 2012 at 12:20

The lower end STM32 micros do not have floating point units, so all floating point calculations have to be performed via software libraries which makes these operations far slower than integer ones.  The problem you are having is simply that the micro does not have enough time to complete the floating point operations before the next interrupt.

It's nearly always possible to replace floating point operations with integer ones, certainly in the case of a simple scaling operation which would speed things up significantly. However, 400kHz is an extraordinarily fast rate for an interrupt to run at, and makes me think that you have a fundamental design issue.  Why do you have to run this interrupt so fast?  I have made smooth RGB LED faders on tiny 8 bit PICs without maxing out the CPU, so an STM32 should barely be running above idle.

[frankmeyer9]

Posted on November 13, 2012 at 13:28

It's nearly always possible to replace floating point operations with integer ones, certainly in the case of a simple scaling operation which would speed things up significantly.

Maybe the initiator of this thread is a Mathlab/Simulink disciple ? That software produces nice models with an option to export as C code, but unfortunately uses floating point datatypes by default. The reality on FPU-less controllers is a little different than the model ... And for the speed up when using scaled integer - two orders of mangnitude are not uncommon.