UNIX Time

[abilio]

I've been doing some tests, and found this to be related to the Espressif tools. I created this simple test:

void check_this_float_passing(float f) {
    printf("this is a float: %f\n", f - 16777215.0); // the constant is there to prove that is not fault of the printf */
}

void test_float(void) {
    check_this_float_passing(16777215.0);
    check_this_float_passing(16777216.0);
    check_this_float_passing(16777216.1); // buggy from now on
    check_this_float_passing(16777217.0);
    printf("this is a big float showing it works: %f\n", 16777217.0); // this works
}

Expected result:

this is a float: 0.000000
this is a float: 1.000000
this is a float: 1.100000
this is a float: 2.000000
this is a big float showing it works: 16777217.000000

Obtained:

this is a float: 0.000000
this is a float: 1.000000
this is a float: 1.000000
this is a float: 1.000000
this is a big float showing it works: 16777217.000000

As you see, there is a problem with passing floats as a parameter of a function for numbers higher than 2^24. I'm going to investigate further.

Note: this is not related to the previous floating point bug (80000000.0 / 1000000.0 != 80).

[jmarcelino]

Thank you so much for posting your thoughts and debugging steps @abilio
This is really excellent for us entering the world of μpython internals debugging - and do I love a good mystery to apply some detective work ;-)

That the problem appears at 24 bits is interesting and I remember floats (when stored as 32 bit) only have 23 bits for the significant digits so maybe that explains it.

I think printf("%lld %f\n" ...) uses doubles so that's probably why you didn't see it there.

Just a theory at least. I'll look into it a bit more later if we're still stuck.

[abilio]

@jmarcelino, actually in the line:

printf("%lld %f\n", mach_rtc_get_us_since_epoch(), mach_rtc_get_us_since_epoch() / 1000000.0);

I wanted to print the us value after epoch, which is internally kept as a 64 bit integer (to go beyond the 2K38 problem), hence the %lld. Then at the same line I wanted to test that it was not an issue with converting it to a float seconds value (which proved not to be the case).

[jmarcelino]

@abilio

I meant that %f in the printf is usually a double not a float

[abilio]

@dchappel, @jmarcelino, and everyone else that reads this. I hope you guys all accept my humble apology. @jmarcelino made me realize of a mistake I made while coming into this conclusions (and in the original software too).

I had forgotten that single floating point values are 32 bit (so only 23 bits represent the fraction). The results are then correct. I'll check into the reported bug and look for a way to fix it ASAP. Probably it won't be included in today's release, as I want to test it properly this time.

[abilio]

After thinking it through and discussing it with my fellow workers, the only posible solution is to go back to integers. The reason is that at present time mp_float_t is now a C float, that only has 23 bit to represent the mantissa. This could be changed, but needs proper testing. Perhaps in the future this will change, but until then, time.time() will return an integer.

[soren]

This post is deleted!

[Devang Sharma]

@abilio, how can I sync/set RTC to UNIX time?

[jmarcelino]

@devang-sharma

Do you mean over NTP?

You can now use rtc.ntp_sync("pool.ntp.org")

Check the RTC docs: https://docs.pycom.io/chapter/firmwareapi/pycom/machine/RTC.html

[Devang Sharma]

@jmarcelino, I want to sync RTC to current time(UTC) and after that, I can use time.time() function to calculate time elapsed since Epoch and then use it as a timestamp.

[livius]

@devang-sharma
I do not know if i understand you corectly
but you can set timezone

utime.timezone([secs])

and then use

utime.localtime()

[Devang Sharma]

@jmarcelino It works for me now! I had to enable NTP client using the command line in Windows. Before that, "rtc.synced()" was returning False. Thanks.