The usual atof(), strtof(), most of libc is available.
You're really converting strings to floats on a Cortex-M0 with very little memory and a 16MHz processor however? I try not even to use floating point on these chips if at all possible, it's slow and thus power inefficient and bloats the code. atof() for instance is 300 bytes, strtof is 500 bytes. That's running near 1% of your available flash with a softdevice, adds up quickly.
Other options often include using scaled integers and converting things before you send them to the device, if whatever sending the value is more powerful.
.. correcting the memory usage ..
atof() itself is 300 bytes but also needs a other functions from the float/double/other libraries linked in. If you're already doing some float arithmetic you may already have some of them linked, if you don't the total code pulled in by one atof() from a base case with no other float requirements is 3Kb. strtof(), although that routine is larger at 500 bytes, requires a total of 2.4Kb of code to work.
I didn't measure how long it takes to do one conversion, I don't think it's terribly quick.
Mmm OK. 143K flash and 6K ram is still a lot more than I am used to working with so I am not too worried about that. The speeed of conversion may be an issue.
The format of the string is always the same - GPS data (ddmm.mmmmm).
Maybe I can unpack the ddmm and mmmmm bits seperately into uints and ulongs then multiply/add into a float and then divide.
Mmm OK. 143K flash and 6K ram is still a lot more than I am used to working with so I am not too worried about that. The speeed of conversion may be an issue.
The format of the string is always the same - GPS data (ddmm.mmmmm).
Maybe I can unpack the ddmm and mmmmm bits seperately into uints and ulongs then multiply/add into a float and then divide.
