Uncommenting the fnltm line properly passes across the hardcoded hex value but otherwise it seems like either:
a. casting makeTime(tm) as a uint32_t messes things up
b. makeTime(tm) doesn't work the way I understand
c. the tm.xxx functions aren't working they way I understand
Any hints or suggestions will be greatly appreciated!
Tomorrow I'm going to try (again) hard coding the Wire.read() values and confirm they are what I expect.
When I scope the I2C lines things look as expected but somewhere when converting the time_t tm to an uint32_t things go awry.
According to the code, tm is not a time_t. So, this statement contains some errors that need correcting.
Uncommenting the fnltm line properly passes across the hardcoded hex value but otherwise it seems like either:
a. casting makeTime(tm) as a uint32_t messes things up
b. makeTime(tm) doesn't work the way I understand
c. the tm.xxx functions aren't working they way I understand
I'd say that those are reasonable assumptions. Without knowing which makeTime() function you are calling, we can't know what it's return type is, so we can't determine the reasonableness of casting it to a uint32_t.
We don't know how you understand makeTime() to be working. so it is hard to comment on that statement.
tm is a struct, with fields, not functions. So, there is nothing to work, or not work, about the fields.
So, where is the makeTime() function that you are using implemented?
I expect to get back 55A64639 but I keep getting 56 05 A9 A9.
There is NO way that the function returns a 32 bit number that has spaces. You need to explain this statement, and show the code that displays the value.
I took the liberty in fixing the name to something more descriptive of what it actually does. It doesn't return a "decimal" (as implied by the "DEC" part of the name). It returns an integer which has no base. You could argue that it returns a "binary" since that's how the computer stores it, but even that would be incorrect.