MSP430G2553: convert float to hex
This is something worth an answer, as it's too complex otherwise.

The code sample you happened to find may, or may not, be what you want. You found something. But it is obvious you don't really understand it. So it is hard to know if the equivalent in C is really going to do what you need. But let's just assume... for now.

C++ strings use the heap. I don't think you actually want to use the heap for these results because, quite frankly, I don't think you know how to use it. So I'll avoid attempting anything directly similar to C++ on this point and simply direct you to supply a character string buffer that is at least 9 chars long. Also, since the float is 4 bytes, I'll just assume that you pass it, in its entirety, rather than pass a pointer. Finally, I'll assume you are okay using unsafe library functions like sprintf() and don't care about the possible "code-bloat" that hauling in sprintf() may also entail.

char * toHex( float fv, char * buf ) {
    return sprintf( buf, "%08X", *(unsigned long int *) &amp;fv );
}


All this does is "lie to the C compiler." It first asks for a pointer to the passed floating point value (which may force the C compiler to use memory rather than a register to hold it... but that's a compiler detail you don't care about.) It then "casts" that pointer to a different kind of pointer, so that the C compiler thinks it is now something else (a pointer to an unsigned long int, which I suspect is the right size.) Then it "de-references" that pointer, fetching the value there. But now, the C compiler "thinks" that it is an unsigned long int. So that's what it grabs and hands off to sprintf() without doing any conversion. Sprintf() then treats it as an integer and goes off reading the format string to figure out what to do with it.

The one caveat here is that you may require a specific "order" to these ASCII bytes when you talk to your external device. But that is left as a detail for you to worry about.

Just call it like:

\* some code here to compute your float value, 'myFloat' */
{
    char hexBuf[9];
    toHex( myFloat, hexBuf );
    /* some code you must write that uses hexBuf */
    /* and may or may not need to re-order the buffer as it does so */
}
\* other code after all is said and done */


That's about it. It's unsafe to use if you aren't careful with the buffer size, because toHex() doesn't have a way to find out if the given buffer is long enough. If it isn't, then bad things will happen. Also, sprintf() doesn't know about the length of its buffer, either. So it can write over unintended memory, too. The example I provided that uses toHex() provides a buffer that is long enough for the 8 ASCII characters needed, plus one for the string's ending null byte (needed.) Longer is okay. Shorter is NOT okay.

The message length will always have 8 ASCII characters in it. If you wanted shorter when possible, then that's your fault for not saying so.



Try to avoid using floating point numbers in your internal calculations.

Even when there are many orders of magnitude going on, it's often better to do things in the integer domain. For example, one of my commercial applications deals with currents spanning from \$100\:\textrm{fA}\$ all the way up to about \$10\:\mu\textrm{A}\$. That's 8 orders of magnitude!! Seems like a perfect fit for floating point, right? No. I used integers the entire way. My ADCs provided integers. My gain control used integers. My DACs used integers. Everything coming into the system and everything going out of the system was in integer form. Although there was a temptation present, here, I completely avoided the use of floats.

There are some reasons. In floating point, you cannot assume that \$A\cdot\left(B+C\right)== A\cdot B+A\cdot C\$. The distributive property is shot to pieces. Also, you can lose important precision when performing sums. For example, to do things right when working with many orders of magnitude, you almost certainly need to sort the numbers first. But how many times do people really do that? Yet, ignorantly performing \$avg = \frac{1}{N}\sum x_i\$ can get you into trouble (especially if you accidentally start with the largest value.) It gets worse when you are taking the differences of two sums, as you very well might do if and when computing a variance or standard deviation, as the difference might depend heavily on your ability to retain precision in the least significant bits of your sums.

Floating point, useful and powerful as it often is, also is dangerous. Good use often requires serious knowledge about rounding and truncation errors and the skill with numerical methods associated with the use of floating point. Far too few have the training or experience to use floating point wisely. So the basic rule I suggest, until and unless you know what you are doing with it, is to NEVER use float or double for any commercial instrumentation purpose.



Of course, if you are working with instrumentation that requires it and also requires communications using ASCII representations of engineering or scientific notation, or specifies ASCII hex representations, then do that conversion only at the very last possible moment. But all of the internal computation should avoid it, if possible.