Skip to content
This repository was archived by the owner on Aug 4, 2020. It is now read-only.

Conversation

@bszekely
Copy link

The fix is calculating in the elapsed ticks at the init time to remove the problematic offset.
Details:
The HAL tick counter is reflecting the elapsed time since the startup of the MCU. When the xi_bsp_time_init() is called the tick counter is already containing the elapsed time (it is non-zero). This distorts the result of the xi_bsp_time_getcurrenttime_seconds() function as a problematic offset will appear. This is even more significant in case the xi_bsp_time_init() is called repeatedly or with a delay.

{
xi_bsp_time_sntp_init( NULL );
if (xi_bsp_time_sntp_getseconds_posix() != 0)
{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this condition necessary?
If the getseconds equals zero, then isn't it a failure? Failure during getting the time from SNTP server? Also means the HAL_GetTick() returns zero, right?

If time isn't received from SNTP service the connection to broker should fail anyway. So, I would stick to a simple:

ticks_at_start = HAL_GetTick(); without a condition.

@atigyi
Copy link
Contributor

atigyi commented Mar 6, 2018

Good catch!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants