Floating point FOR Loop Problem in STM32F4 - Page 1
Forum section: electronics / general

author: SolarSunrise
author_rank: Regular Contributor
timestamp: July 29, 2014, 03:27:44 am
content: Hello, I was implementing a code to window my data (On STM32F4 with CMSIS DSP Lib) when I experienced something that has not happened before (on my desktop computer):I tried window my data like this, using a for loop:Code:for(i = 0; i < WINDOW_SIZE; i++) testInput = (float32_t)(testInput_f32_10khz * window);But it generated a peculiar assembly output, and my data was not windowed at all:Code:31786 8006640: ecb3 7a01 vldmia r3!, {s14}31787 8006644: ecf1 7a01 vldmia r1!, {s15}31788 8006648: ee67 7a27 vmul.f32 s15, s14, s1531789 800664c: 4283 cmp r3, r031790 800664e: ece2 7a01 vstmia r2!, {s15}31791 8006652: d1f5 bne.n 8006640 <main+0xa0>Why is this happening? Why wasn't my data multiplied by the window function? FYI I have used the CMSIS arm_mult_f32 vector multiplication function:Code:arm_mult_f32(window, testInput_f32_10khz, testInput, WINDOW_SIZE);and it worked fine.Thanks in advance!

author: Kremmen
author_rank: Super Contributor
timestamp: July 29, 2014, 04:44:57 am
content: Your code is not using the loop structure for anything so it was probably optimized out. Try to set the compiler switches to no optimization and check what you get then.

author: miguelvp
author_rank: Super Contributor
timestamp: July 29, 2014, 05:05:05 am
content: turning off optimization will change the executable but not the resultInside the loop i is not used, window and testInput_f32_10Khz don't change so no matter what testInput is just the multiplication of the two regardless of iterations.

author: hamster_nz
author_rank: Super Contributor
timestamp: July 29, 2014, 05:11:34 am
content: Quote from: miguelvp on July 29, 2014, 05:05:05 amIt looks like 'testInput_f32_10khz' or 'window' does not change with each iteration?If not it doesn't matter if the loop runs once or 1000 times, testInput will have the same value, so the the compiler emits the could to calculate it only once (and maybe set 'i' to WINDOW_SIZE).

author: miguelvp
author_rank: Super Contributor
timestamp: July 29, 2014, 05:17:02 am
content: The function you want to use is described as this:void arm_mult_f32 (float32_t *pSrcA, float32_t *pSrcB, float32_t *pDst, uint32_t blockSize)and this is what it does inside:pDst = pSrcA * pSrcB, 0 <= n < blockSize.And:for(i = 0; i < WINDOW_SIZE; i++) testInput = (float32_t)(testInput_f32_10khz * window);is not the same as:arm_mult_f32(hm_window, testInput_f32_10khz, testInput, WINDOW_SIZE);What you want is:Code:for(i = 0; i < WINDOW_SIZE; i++) testInput = hm_window * testInput_f32_10khz;Unless you want to use pointers so there is not that much indexing, but that's another thing all together.BTW your original code didn't show right, you typedCode:for(i = 0; i < WINDOW_SIZE; i++) testInput = (float32_t)(testInput_f32_10khz * window);So your only problem was that you mistyped hm_windowbut the i within square brackets gets interpreted so next time include it within a code sectionCode:[ code ]xxxxxxx[ /code ]Argh is hard to escape the code statements, so it's like above but without the spaces.

author: SolarSunrise
author_rank: Regular Contributor
timestamp: July 29, 2014, 05:53:02 am
content: Quote from: miguelvp on July 29, 2014, 05:17:02 amOh sorry. I'll useCode:codetags from now on. Thanks for catching that! I'll edit my original post.Well in my code, hm_window array and window array are the same... So that is not the problem... Sorry for the confusing naming. I was just testing different windows hence the different arrays.The question still remains... Why does this work:Code:arm_mult_f32(window, testInput_f32_10khz, testInput, WINDOW_SIZE);And not this:Code:for(i = 0; i < WINDOW_SIZE; i++) testInput = (float32_t)(testInput_f32_10khz * window);?

author: miguelvp
author_rank: Super Contributor
timestamp: July 29, 2014, 06:16:27 am
content: Are testInput, testInput_f32_10khz and window all declared at pointers to float32_t or at least as arrays for them?Also if they are you don't need the cast.Maybe showing us more of the code?Edit, specially the declaration of WINDOW_SIZE, if it's a macro you might want to put it in parenthesis, because it could be it evaluates to just 1 (of course I'm assuming is a complicated macro instead of a plain old pound define to a simple value)

author: andersm
author_rank: Super Contributor
timestamp: July 29, 2014, 07:38:30 am
content: Quote from: SolarSunrise on July 29, 2014, 03:27:44 amWhat is peculiar about it? What did you expect?Code:31786 8006640: ecb3 7a01 vldmia r3!, {s14} ; temp_float1 = *testInput_f32_10khz_ptr++31787 8006644: ecf1 7a01 vldmia r1!, {s15} ; temp_float2 = *window_ptr++31788 8006648: ee67 7a27 vmul.f32 s15, s14, s15 ; temp_float2 *= temp_float131789 800664c: 4283 cmp r3, r0 ; temp_bool = (testInput_f32_10khz_ptr == testInput_f32_10khz + WINDOW_SIZE)31790 800664e: ece2 7a01 vstmia r2!, {s15} ; *testInput_ptr++ = temp_float231791 8006652: d1f5 bne.n 8006640 <main+0xa0> ; if (temp_bool == false) goto 8006640(EDIT: wrong goto address)

author: miguelvp
author_rank: Super Contributor
timestamp: July 29, 2014, 08:00:03 am
content: Quote from: andersm on July 29, 2014, 07:38:30 amHis code didn't show right on his post, he actually typed:Code:for(i = 0; i < WINDOW_SIZE; i++) testInput = (float32_t)(testInput_f32_10khz * window);and he claims window is a pointer to hm_window so it should be the same.My thinking is that maybe WINDOW_SIZE is a macro that subtracts two numbers#define WINDOW_SIZE 100-1then the compare will be (i<100)-1, so i is less than 100 so that is true, minus 1 then it's false, or something to that matter, but we need to see the rest of the code.Edit: well not that because minus has precedence, but some other macro like a bit-wise operator that makes it act weird.

author: SolarSunrise
author_rank: Regular Contributor
timestamp: July 29, 2014, 12:40:19 pm
content: Alright, I found a problem, along with a lesson. From now on, remember that when FFT is executed, it modifies the INPUT buffer.This is why I kept on reading the data resembling the original data, I read the windowed data buffer AFTER the FFT has done its job on the input buffer. This whole time the code was working fine.......I hate problems like these... Thanks again for everyone's help!