• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 78 subscribers
  • Views 152 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

MSP430FR6043: IQmathLib and GCC with -mlarge

MSP430FR6043: poor iqmathlib performance with GCC?

Daniel Pantea
Prodigy 91 points
Part Number: MSP430FR6043
Other Parts Discussed in Thread: MSP430WARE

Created a test which fills 256 floats with normal multiplication/divisions and then another 256 array with IQ20 using corresponding IqmathLib operations, with:

  • -mlarge
  • -mcode-region=either
  • -mdata-region=none
  • C:\ti\msp430ware_3_80_14_01\iqmathlib\libraries\CCS\MPY32\5xx_6xx\IQmathLib_CCS_MPY32_5xx_6xx_CPUX_large_code_large_data.lib

First 2 (-mlarge and -mcode-region=either) are a must as we need both low-FRAM and the HIFRAM. The last is unfortunate (_large_data.lib) but only this seems to compile with GCC and given memory requirements (see).

 The floats and math fillings are surrounded by Debug LED and traced on oscilloscope:

 

And the results are not promising at all:

  • 2.17s with normal float operations:

 

  • And only 1.79s with IqmathLib operations:

 

Also when trying to convert the IqmathLib results to float (using _IQ20toF) in order to compare with real floats the code doesn’t work anymore and even the debug session gets stuck immediately after flashing:

 

As noticed above, seems that a limit? is at 247, where the project still works and can be debugged too, while with 248 or above, not anymore. The map difference between 247/248 builds doesn’t reveal anything special to break so badly the code:

 

The test project is attached.

test_GCC.zip

Help or suggestions are greatly appreciated, thank you!

Daniel

  • +1
    Guru 21145 points

    On speed, your fixed point version isn't going to see a speed advantage over the float version because it also performs floating point operations.

    _IQ20((float)(i + 1U)

    This converts an integer to a float and back again for no good reason. Worse, you get a floating point multiply. (See the definition of_IQ20 in the header file.)

    As for things falling apart when the array size increases, that sounds like the stack running out of space.

  • 0 in reply to David Schultz
    Prodigy 91 points

    Thank you! Indeed, that improves IQmath test timing a lot!

    The code corrected as per David's suggestion is: 

    static _iq20 xm[TEST_SIZE];
static void math_test(void)
{
    _iq20 f1 = _IQ20(2.103f);
    _iq20 f2 = _IQ20(1.135f);
    xm[0] = _IQ20(1.0f);
    for (uint16_t i = 2; i <= TEST_SIZE; i++) {
        if (xm[i - 2U] > _IQ20(1.0f)) {
            xm[i - 1U] = _IQ20div((_IQ20mpy(f1, _IQ20(i + 1U)) + _IQ20mpy(f2, _IQ20(i - 1U))), xm[i - 2U]);
        } else {
            xm[i - 1U] = _IQ20mpy((_IQ20mpy(f1, _IQ20(i + 1U)) + _IQ20mpy(f2, _IQ20(i - 1U))), xm[i - 2U]);
        }
    }
}

**Attention** This is a public forum