Issues with converting float to string with sprintf

@dan, this is temporary until @mdma makes minor fixes. The end state is to have sprintf part of the system firmware. :smiley:

Sorry to bother you about this @mdma, but I can’t find ANY documentation on dtoa anywhere. Particle Dev’s declaration of dtoa is in the form of a compile error:
too few arguments to function 'char* dtoa(double, int, int, int*, int*, char **)

I also get a bunch of bogus compiler errors from subroutines related only by a function call to the function containing dtoa, as in: “jump to label ‘DbgFinish’” {next error} “from here [-fpermissive]” {next error} “crosses initialization of ‘float FMath’”. That’s not possible, as the label jump is entirely in the loop() system function.

Is dtoa still a viable choice? I’m looking for a function to convert a FLOAT to a char* with 0 or 1 digits of precision (specified by another calculation).

EDIT: This is for a Core.

Any reason to not use sprintf(buf, "%.1f", myFloat) rather than digging into dtof?

Yes. Because then I have to formulate a format string ("%.1f" for a single decimal place, and ??? for no decimal places) realtime in the code. Besides, I thought I’d save a couple of kilobytes by not using sprintf. I’m currently at 96K binary size…not much room left!

Did a little research, finding that the Arduino supports dtostrf…but there may not be an elegant way out of this.

Welllllll…sprintf DOES work. I guess I have to take that, 'cause I wasn’t going to get anywhere with DTOF (bad definition) or DTOSTRF (not defined). Thanks for the code snippit–I used it religiously :stuck_out_tongue_winking_eye:. Now at 98K binary size…the good news is that I’m almost finished.


Right now Core has dtostrf() (in spark_wiring_string.cpp, you can extern it) and Photon has dtoa() so you would need a macro to even out that little speed bump in portable code.

But dtostrf uses sprint() so you might as well just do that instead!

1 Like

I am running 0.4.3 on my photon but sprintf still doesn’t work for me. Wasn’t this supposed to be in this firmware update?


1 Like

The system firmware indeed should be fixed. The user-firmware, that’s flashed over the IDE, still needs to be updated to 0.4.3 Once that’s done, it should work. For now, you can either try compiling locally, or wait until the IDE catches up, which hopefully doesn’t take long. Any thoughts @dave?


We’re still doing lots of testing on the IDE updates, and we’ll release as soon as we feel good about those updates being stable. Hopefully early next week! (I know I’ve been saying that for a while now, but I mean it! :slight_smile: )



when it’s updated, is it going to be usable from the IDE as well? i’m currently using String and am intermittently having my photon stop ‘breathing’, necessitating a power cycle; not sure if this is the manifestation of too much heap fragmentation or not.

@Jangie, the answer is yes, it will be usable from the web IDE. In the interim, you could allocate your Strings statically and with pre-set size (globally allocated and use string.reserve(numbytes)) to limit the dynamic allocation shenanigans.


As mentioned near the beginning of the thread… %f has been removed from current [s]printf functionality in the currently available library due to causing crashes and insufficient time to debug before shoving the code out the door.

Currently, a %f conversion will silently ignore its corresponding datum producing “” in its place.

@owendelong, the floating point support in sprintf() will be present in the impending new firmware release. :smile:

Sure, but MDMA asked if there was any reason not to use it… If you need code to run today, then I think that’s a perfectly valid answer to his question.


How impending ? A week / a day ?

Might be a topic of todays feature:
Particle Interactions: Interview with Zach Supalla 7/29 at 4pm PST

There are loads of fixes in the current develop branch which I can’t wait to use :smile:

How is this a C/C++ question? This works in C/C++ but not on the photon. :wink:

It’s been removed due to high memory usage. It’s not in the current Develop or Latest firmware branch either. I’ve made a work around for now.

So how little memory and program space do we actually have for user code, if something as basic as float support is deemed too much ?