@dan, this is temporary until @mdma makes minor fixes. The end state is to have sprintf part of the system firmware. 
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 
. Now at 98K binary sizeā¦the good news is that Iām almost finished.
2 Likes
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?
Thanks.
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?
Heya!
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! 
)
Thanks,
David
3 Likes
when itās updated, is it going to be usable from the build.particle.io 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.
2 Likes
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. 
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.
2 Likes
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
How is this a C/C++ question? This works in C/C++ but not on the photon. 
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 ?