I would do this using strconv.FormatUint:

import "strconv"

var u uint32 = 17
var s = strconv.FormatUint(uint64(u), 10)
// "17"

Note that the expected parameter is uint64, so you have to cast your uint32 first. There is no specific FormatUint32 function.

Another option is to use a solution from Oraclize https://github.com/oraclize/ethereum-api/blob/master/oraclizeAPI_0.5.sol, it suits best for me:

0.5 Compiler Version:

    function uint2str(uint _i) internal pure returns (string memory _uintAsString) {
    if (_i == 0) {
        return "0";
    }
    uint j = _i;
    uint len;
    while (j != 0) {
        len++;
        j /= 10;
    }
    bytes memory bstr = new bytes(len);
    uint k = len - 1;
    while (_i != 0) {
        bstr[k--] = byte(uint8(48 + _i % 10));
        _i /= 10;
    }
    return string(bstr);
}

Pre 0.5 Compiler Version:

function uint2str(uint i) internal pure returns (string){
    if (i == 0) return "0";
    uint j = i;
    uint length;
    while (j != 0){
        length++;
        j /= 10;
    }
    bytes memory bstr = new bytes(length);
    uint k = length - 1;
    while (i != 0){
        bstr[k--] = byte(48 + i % 10);
        i /= 10;
    }
    return string(bstr);
}

Your code with sendBinary is probably fine, as long as on the other side you also use a function that expects to receive exactly 32 bits of binary data (in little-endian format).

Trying to print (char*)&some_32bit_int on the other hand will not do anything useful.

The short version is this:

• if you want to send (or receive) binary data, use functions made for binary data - they will usually take a pointer to char (or uint8_t or something like that) and a length.
• if you want to send (or receive) strings, use functions meant for strings. They'll sometimes take String, or std::string or, unfortunately perhaps, char * for C strings.

Never mix both.

Functions that expect a (C) string expect it to actually be a C string, i.e. a sequence of chars ending with a null byte (0x00). The chars are expected to be mostly ASCII printable characters. If you give them just plain raw data like the memory address of an int, you won't get what you want.

Trying to print raw data using a function that expects a C string will result in garbage (or nothing at all, or a lot more garbage than you expected!). (Details in the second part.)

If you want to format your data into a string for sending (using a string/text protocol), then use functions like sprintf to do the conversion. (Or use a library that does JSON if your receiver is a web thing - that's pretty handy.)

e.g.

char buffer[32];
sprintf(buffer, "{data:%d}", payload);

Then send buffer via a function that expects a C string.

Consider this:

uint32_t payload = 0x00323130;

The first line initializes a 32 bit int to a specific value, 0x00323130 in hex. Now let's assume that payload was stored in memory at address 0x0100. The memory after that assignment would look like this:

Addr.  Val
0x0100 0x30  // our same number 0x00323130 stored in little-endian format
0x0101 0x31
0x0102 0x32
0x0103 0x00

When you do:

client.sendBinary(&payload, 4);

Those four bytes get send over the wire (or the air) exactly as they are. Nothing more, nothing less. If that's what the receiver expects you're golden.

Now if you do:

Serial.println((char *) &payload);

Serial.println is an overloaded function. When you give it a char *, it expects a C-string, which is a series of characters terminated by a "null byte", i.e. a byte value of zero. Serial.println will then look at the first byte pointed to by the argument. If it's zero, it stops. Otherwise it outputs that char to the serial line, and moves on to the next character. Repeat until a zero byte is found.

In the specially crafted case here with that specific value of payload, Serial.println would receive address 0x0100 and:

• Look at the value at 0x0100, get 0x30, check that it's not zero, and pass it on to the serial line. Serial monitor would receive 0x30 and display that. By lucky coincidence this is the ASCII character code for the digit "0".
• Look at the value at 0x0101, get 0x31, check that it's not zero, and pass it on to the serial line. Serial monitor would receive 0x31 and display that. By lucky coincidence this is the ASCII character code for the digit "1".
• Look at the value at 0x0102, get 0x32, ... serial monitor displays "2".
• Loot at the value at 0x0103, get 0x00. That is a null byte, so it stops there, and sends a newline sequence to the serial.

So in this fabricated scenario the output on the serial monitor would be "123".

Try it with payload = 0x00616263; - serial monitor will display "cba".

In short, Serial.println will output exactly the bytes it finds in memory to the serial, until it encounters a zero byte. The serial monitor will try to display those bytes. But, unless you've crafted those values very carefully, all you'll get out of it is garbage - relatively few 8bit values map to printable characters, and even when they do they won't "look" anything like the raw data you had.

If your number happens to start with a zero byte in its binary little-endian representation, Serial.println won't print anything - like if you had given it an empty string.

If your number doesn't contain a zero byte, it will keep on reading memory past the storage allocated for payload until it finds one - possibly outputing much more "junk" than a 32bit variable could ever contain.