I get the unix time (in s) but because I take many samples per second I convert this to ms then add millis() to it. This works fine as far as getting a unique timestamp goes, but it needs to be converted into a string for MQTT to handle.
I have tried some of the solutions in the linked thread such as this
and get the complie error - error: request for member 'toCharArray' in 'measurement_time', which is of non-class type 'uint64_t {aka long long unsigned int}' measurement_time.toCharArray(buffer, 13);
my original error is:
Compilation error: call of overloaded 'String(uint64_t)' is ambiguous
uint64_t val = measurement_time;
char buffer[15];
uint8_t ndx = 15;
while (ndx) {
ndx--;
uint8_t v = val % 10;
val = val / 10;
buffer[ndx] = v + '0';
}
Be careful to include the terminating null at the end of the buffer, variables declared inside a function will not be automatically initialized to all zeros.
uint64_t val = measurement_time;
char buffer[15];
uint8_t ndx = 14;
buffer[ndx] = '\0';
while (ndx) {
ndx--;
uint8_t v = val % 10;
val = val / 10;
buffer[ndx] = v + '0';
}
Need to be careful of the buffer size, and allow for the number of digits being less than the full buffer. Safer to use a buffer that will fix the maximum size of a uint64_t.
uint64_t val = measurement_time;
char buffer[21];
char* ndx = &buffer[sizeof(buffer) - 1];
*ndx = '\0';
do {
*--ndx = val % 10 + '0';
val = val / 10;
} while (val != 0);
Serial.println(ndx);
This is a reduced form of the code used by Print for uint32_t
size_t Print::printNumber(unsigned long n, uint8_t base)
{
char buf[8 * sizeof(long) + 1]; // Assumes 8-bit chars plus zero byte.
char *str = &buf[sizeof(buf) - 1];
*str = '\0';
// prevent crash if called with base == 1
if (base < 2) base = 10;
do {
char c = n % base;
n /= base;
*--str = c < 10 ? c + '0' : c + 'A' - 10;
} while(n);
return write(str);
}
@trap-fish, if the code in Post #8 doesn't work on your platform, then you can use one of the roll-your-own solutions presented above to get a character string decimal representation.
There's also a more efficient option if you're OK with time stamps presented as a character string HEX representation:
However, I think I've seen some posts that say AVR-based platforms have a problem shifting 64-bit integers. If you run across that, then you could go with: