atof没有给出正确的价值

我记得读过其他帖子，说如果错误的数学库被收录，ATOF可能会失败。



      以下为原文

    I recall reading other posts saying atof can fail if the wrong math library is being included.
 

代码很大，但我会把这里的重要部分，我用XC32编译器：即使值是大的，2017051913156000我甚至要求下一个89.026992，得到相同的结果。



      以下为原文

    The code its big , but I will put here the important parts, I'm using the xc32 compiler:
even if the value is to big , the 20170519131506.000 I even ask for the next one the 89.026992, got the same result
 
#include
#include
#include
#include "mcc_generated_files/mcc.h"

#include
#include

int get_coor() {
    uint8_t coor_data[500]
    uint8_t txData[200];
    uint8_t rxData[200];
    int rx_size = 0;
    
    double latitude = 0;
    double longitude = 0;
    int speed = 0;
    int satellites = 0;
    int quality = 0;
    double altitude = 0;
    double time=0;


    txData[0] = '';
    sprintf(txData, "AT+CGNSINFrn");
    txData[strlen(txData)] = '';
    UART1_WriteBuffer(txData, strlen(txData));
    rx_size = UART1_ReadBuffer(rxData, 100);
    rxData[rx_size] = '';
    
    //rxData gives this string +CGNSINF:
 
    // 1,1,20170519131506.000,89.026992,-20.927523,14.200,2.76,55.8,1,,1.2,1

    //removing the +CGNSINF: to get only the numbers and commas
     for (c = 12; c < rx_size; c++) {
        if (rxData[c] != 10) {
            coor_data[c - 12] = rxData[c];
        } else {
            break;
        }
    }
 
 
 
    char *p = coor_data;//coor_data is now 1,1,20170519131506.000,89.026992,-20.927523,14.200,2.76,55.8,1,,1.2,1
    p = strchr(p, ','); //skip fist number
    p = p + 1;
    p = strchr(p, ','); //skip second number
    p = p + 1;

   time =atof(p);//I want the time like that the 20170519131506.000 on a string ( i know its time and date, but its all save in this)

    uint8_t gps_coor[250];
    gps_coor[0] = '';
    sprintf(gps_coor, "%fn", time);
    gps_coor[(strlen(gps_coor))] = '';

}

当你得到同样的效果时，究竟为什么要这么做呢？



      以下为原文

    Why on earth do all this
txData[0] = '';
sprintf(txData, "AT+CGNSINFrn");
txData[strlen(txData)] = '';
UART1_WriteBuffer(txData, strlen(txData));
when you'd get the same effect with
uint8_t txData[] = "AT+CGNSINFrn";
UART1_WriteBuffer(txData, sizeof(txData));

如果这是真的，那么你的ATOF应该从201705开始返回一些值…但是对于一个单精度浮点值，它将不是你所期望的。看看QHB的注释，你应该首先尝试用一个简单的字符串“3.14”来填充你的ATOF，看看会发生什么。这听起来怪怪的。您已经拥有包含所需内容的字符串值，并且尝试通过使用浮点转换来得到它的子字符串。（这不取决于浮点精度）为什么你不把字符串解析到下一个逗号，也就是简单地从它中得到一个子字符串？您已经使用StrCHR解析调制解调器字符串…



      以下为原文

    If this is true
char *p = coor_data;//coor_data is now 1,1,20170519131506.000,89.026992,-20.927523,14.200,2.76,55.8,1,,1.2,1
then your atof should return some value beginning with 201705 ...
However for a single precision float value it will not be what you expect.
 
Looking at qhb's comment, you should first try to feed your atof with a simpler string like "3.14" and see what happens.
 

This sounds weird.  You already do have the string value containing what you want, and you try to get a sub-string  out of it by using float conversions back and forth ? (which will not work depending on float precision)
 
Why don't you "parse" the string up to the next comma, i.e. simply get a sub-string out of it ?
You already used strchr for parsing the modem string ...
 
 

真的！感谢这部分，它实际上有助于把代码放小：）！但问题是真正的问题：



      以下为原文

   
 
True! Thanks for that part , it actually help to put the code smaller :) ! 
 
but the problem is really the atof part :( 

我这样做了，它给了我非常奇怪的值，我创建了一个简单的字符串，把它传递给ATOF。我觉得这个问题真的很重要，这听起来很奇怪。您已经拥有包含所需内容的字符串值，并且尝试通过使用浮点转换来得到它的子字符串。（这不取决于浮点精度）为什么你不把字符串解析到下一个逗号，也就是简单地从它中得到一个子字符串？您已经使用StrCHR解析调制解调器字符串…因为我要用这个值做一些计算，所以我需要双格式。



      以下为原文

   
 
I did this and it gives me very strange values , I have created a simple string a pass it to the atof. I think the problem is really something with the atof function.
 

This sounds weird.  You already do have the string value containing what you want, and you try to get a sub-string  out of it by using float conversions back and forth ? (which will not work depending on float precision)
 
Why don't you "parse" the string up to the next comma, i.e. simply get a sub-string out of it ?
You already used strchr for parsing the modem string ...
 


 
 Because I'm gonna use this value to make some calculations so I need them in double form.

不要使用浮子，而是长的（也许）



      以下为原文

    Don't use float then, rather a long-long (maybe)

不，这不起作用，即使我使用ATOL，它也会给我一个没有.000值的值。



      以下为原文

   


No, that doesn't work, even if I use atol it will give me the value without the .000 values.

他从浮点切换到双平均值，而用双倍的时间进行计算听起来很奇怪。路易斯，你没有回复POST的3IFIFUDD＝ATOF（“3.14”）；不工作，那么你必须对谷歌进行一点。



      以下为原文

    He switched from float to double meanwhile
Time calculations with double still sounds weird.
 
Luis, you did not respond to post #3
If
double d = atof("3.14"); 
does not work then you have to google a bit ...  
http://www.microchip.com/forums/m971521.aspx
 

不，这不起作用，即使我使用ATOL，它也会给我一个没有.0值的值。你仍然可以使用隆隆，并且删除简单的比较中的“。”（隐式乘以1000）。



      以下为原文

    No, that doesn't work, even if I use atol it will give me the value without the .000 values.


You still could use longlong and remove the '.'  (implicitly multiply by 1000)
For simple comparisons < or > this should work.
 

YSoudD= ATF（“3.14”）；不工作，它给出ME1520340100000 000万日元0.00万，我将检查这些帖子，看看我是否找到了一些东西。谢谢：



      以下为原文

   
Yes 
double d = atof("3.14");  
doesn't work it gives me 1520345100000000000000000.000000 
 
I will check those posts to see if I find something. Thank you :)  

不，这不起作用，即使我使用ATOL，它也会给我一个没有000个值的值。你仍然可以使用龙隆，并将“。”（隐式乘以1000）用于简单的比较。我不确定Ato（）会给你很长的时间，所以也许需要定制功能。不知道为什么AOF（“3.14”）不起作用…



      以下为原文

    No, that doesn't work, even if I use atol it will give me the value without the .000 values.


You still could use longlong and remove the '.'  (implicitly multiply by 1000)
For simple comparisons < or > this should work.
 




Yep, I meant that. And I am not sure atol() would give you a long-long so maybe a custom functions will be needed.
 
Not sure why atof ("3.14") is not working...
 

这里只是一个明智的检查。你使用C32还是XC32？（你已经发表在C32论坛）我回忆的问题是XC32。请参见：HTTP://www. McCHIP.COM/FUMMS/FUNDSPE/970228



      以下为原文

    Just a sanity check here.
Are you using C32, or XC32?
(You have posted in the C32 forum)
 
The problem I recalled was with XC32. See: http://www.microchip.com/forums/FindPost/970285