Skip to content

st rtc api: remove usage of mktime/localtime in favor of dedicated functions #4479

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 3 commits into from

Conversation

pan-
Copy link
Member

@pan- pan- commented Jun 6, 2017

Description

The use of mktime was causing a fault when called in interrupt handler because on GCC it lock the mutex protecting the environment, To overcome this issue, this patch add dedicated routine to convert a time_t into a tm and vice versa.
In the process mktime has been optimized and is now an order of magnitude faster than the routines present in the C library. It should increase the accuracy of the low power timer.

Status

READY

Migrations

NO

Related PRs

partially solve #4369

…nctions.

The use of mktime was causing a fault when called in interrupt handler because on GCC it lock the mutex protecting the environment, To overcome this issue, this patch add dedicated routine to convert a time_t into a tm and vice versa.
In the process mktime has been optimized and is now an order of magnitude faster than the routines present in the C library. It should increase the accuracy of the low power timer.
@sg-
Copy link
Contributor

sg- commented Jun 7, 2017

@pan- should the test and time functions be in mbed platform/* directories so other rtc peripherals can use it or are they ST specific?

@sg- sg- added the needs: CI label Jun 7, 2017
@sg- sg- requested a review from c1728p9 June 7, 2017 00:57
@pan-
Copy link
Member Author

pan- commented Jun 7, 2017

Yes, it just fulfill the needs of the ST RTC in that given context:

  • Fields tm_wday, tm_yday and tm_isdst are ignored
  • Less precondition check over the input of mktime because values are coming directly from the RTC
  • No value normalization
  • Environment not used

Nonetheless it wouldn't be difficult to turn functions in this PR into full fledged versions of mktime and localtime. However, the implications are broader than just implementing time conversion function, for instance a well defined replacement for time_t would be needed because at the moment it is compiler specific. What is the policy around locals is also a question which has to be answered. Last but not least time related functions in the C library are poorly designed for instance localtime and gmtime returns a global state which makes those functions not thread safe by design. This part of library is also under specified, for instance the unit of time_t is not defined!

pan- added 2 commits June 7, 2017 11:51
This field was not filled by the previous implementation while being used in rtc_write.
@sg-
Copy link
Contributor

sg- commented Jun 7, 2017

/morph test

@mbed-bot
Copy link

mbed-bot commented Jun 8, 2017

Result: FAILURE

Your command has finished executing! Here's what you wrote!

/morph test

Output

mbed Build Number: 483

Build failed!

void test_is_leap_year() {
for (int i = 70; i < 138; ++i) {
bool expected = is_leap_year(i);
bool actual_value = is_leap_year(i);
Copy link
Contributor

Choose a reason for hiding this comment

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

Actual and expected are using the same function

Copy link
Member Author

Choose a reason for hiding this comment

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

That's embarrassing 😅

@pan-
Copy link
Member Author

pan- commented Jun 8, 2017

superseded by #4499 .

@pan- pan- closed this Jun 8, 2017
@sg- sg- removed the needs: CI label Jun 8, 2017
@pan- pan- deleted the fix_st_rtc_api_time_conversion branch November 14, 2018 10:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants