• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 78 subscribers
  • Views 823 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.

Bugs in _Qtoa() and _atoQ()?

Dirk Osswald
Prodigy 175 points
Other Parts Discussed in Thread: MSP430WARE, MSP430-IQMATHLIB

Hi,

I'm successfully using the "q" math (16 bit fixed point math) from QmathLib.h on an MSP430 (F5528). However I seem to have stumbled in 2 problems related to _q to / from ASCII conversion:

First ASCII to _q conversion using _atoQ()

_atoQ() fails for numbers without decimal point! So e.g.

  • _atoQ( "100" ) will yield 0 (unexpectedly),
  • while _qtoQ( "100." ) will yield 100.0 as expected!

Now _q to ASCII conversion using _Qtoa()

This works for all (?) values except for the minimum value! So e.g. with GLOBAL_Q = 3

  • _Qtoa( string, "%4.3f",  -32768 ) will put a strange "-58:4" into string, while using the next larger value:
  • _Qtoa( string, "%4.3f",  -32767 ) will put "-4095.875" into string, as expected

Am I doing something wrong? Or is the library doing something wrong? At least it does not do what I expect...

I can easily use workarounds for these unexpeced behaviours, but a fix would be helpfull in the long term.

I'm using the QmathLib.h from MSP430ware_1_80_01_03


Thanks in advance for any replies.

  • 0
    TI__Intellectual 1930 points

    Hello Dirk,

    Thank you for bringing these issues to our attention. I can confirm that both of these issues are indeed bugs in the IQmathLib code. I've filed bugs on the IQmathLib product with high importance and will make sure they are fixed in the next release of the library. There is no major release planned at the moment however I will discuss with the team whether we can make a patch release to fix these issues.

    I will reply back to this post when I have more information about when a release can be made available.

    Regards,
    Brent Peterson

  • 0
    TI__Intellectual 1930 points

    Hi Dirk,

    To follow up on my previous reply we've released a new version of the IQmathLib which addresses the issues in your post. The libraries will be included in the new MSP430ware when it is released but you can download the IQmathLib standalone package and start using the updated libraries from the link below.

    http://www.ti.com/tool/msp430-iqmathlib

    Regards,

    Brent Peterson

  • 0 in reply to Brent Peterson
    Prodigy 175 points

    Hi Brent,

    thank you for taking care of that. But....

    I just recently cleaned up my code and I removed my workarounds for _Qtoa() and _atoQ() since I'm now using MSPware 3_30_00_18 with the latest  01.00.02.07 QmathLib/IQmathLib which state that these bugs ID 7946 and ID 7947 are fixed.

    And indeed the _Qtoa() and _IQtoa() now work for the maximum negative numbers work, so bug ID 7947 is indeed fixed.

    Additionally e.g. "30" as input for _atoQ() or _atoIQ() now correctly yields something corresponding to 30.0 as expected.

    But for negative numbers without "." in the string, the _q/_iq output will always be positive, other than expected.
    So e.g. "-30" as input for _atoQ() or _atoIQ() now unexpectedly yields something corresponding to 30.0.
    While "-30." as input for _atoQ() or _atoIQ() correctly yields something corresponding to -30.0 as ever.

    So IMHO bug ID 7946 is not fixed completely.

      

  • 0 in reply to Dirk Osswald
    Prodigy 175 points
    I discovered an additional annoyance (bug):

    When invalid or out-of-range input is given to _atoQ() / _atoIQ() then the global interrupt flag is cleared and not restored!
    Examples:
    - Input like "a", is of course not a suitable input for _atoQ() / _atoIQ(), but still, the interrupts should not be disabled unexpectedly
    - input like "-9000.0" for an _atoIQ18() correctly returns an _iq value corresponding to -8192.0, but still the interrupts are disabled unexpectedly

**Attention** This is a public forum