Skip to content
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

Improve adjtime() functionality #10827

Merged
merged 2 commits into from
Sep 29, 2023
Merged

Conversation

PetteriAimonen
Copy link
Contributor

Summary

Prior pull request #9084 and issue #8858 added basic adjtime() support for the SAMv7 platform.

This pull request adds support for STM32 platform.

In addition I have made a few changes to the adjtime() configuration options:

1) Previously adjustments less than 1 microsecond per tick would be
   completely ignored. Now they are applied over a shorter period at
   a rate of 1 us per tick.

2) Previously CLOCK_ADJTIME_PERIOD was in units of 1/100th of second.
   Change to milliseconds to be more generally useful unit.
   Change setting name to CLOCK_ADJTIME_PERIOD_MS to make the unit change
   easier to notice.

3) Previously CLOCK_ADJTIME_SLEWLIMIT was in percentage.
   Most clock crystals have better accuracy than 1%, so the minimum slew
   rate was excessive. Change to CLOCK_ADJTIME_SLEWLIMIT_PPM with setting
   value in parts per million.

4) No need to use floating point math in clock_adjtime.c.

Impact

Users who have used CLOCK_ADJTIME_PERIOD and CLOCK_ADJTIME_SLEWLIMIT settings should update their configuration. New CLOCK_ADJTIME_PERIOD_MS is 10x the old period value, and new CLOCK_ADJTIME_SLEWLIMIT_PPM is 10000 times the old slewlimit.

Testing

Tested on custom STM32 board with the adjtime example program.

Questions

@michallenc I couldn't find the significance of the Should be between 0.95 and 0.99. comment that was previously in help text for CLOCK_ADJTIME_PERIOD. To me it appears that the desirable value for this setting will depend entirely on what code will be calling adjtime() and how often.

Based on the samv7 implementation, adjusts systick period.
sched/Kconfig Outdated Show resolved Hide resolved
1) Previously adjustments less than 1 microsecond per tick would be
   completely ignored. Now they are applied over a shorter period at
   a rate of 1 us per tick.

2) Previously CLOCK_ADJTIME_PERIOD was in units of 1/100th of second.
   Change to milliseconds to be more generally useful unit.
   Change setting name to CLOCK_ADJTIME_PERIOD_MS to make the unit change
   easier to notice.

3) Previously CLOCK_ADJTIME_SLEWLIMIT was in percentage.
   Most clock crystals have better accuracy than 1%, so the minimum slew
   rate was excessive. Change to CLOCK_ADJTIME_SLEWLIMIT_PPM with setting
   value in parts per million.

4) No need to use floating point math in clock_adjtime.c.
@xiaoxiang781216 xiaoxiang781216 merged commit 0611f39 into apache:master Sep 29, 2023
26 checks passed
@davids5 davids5 added the breaking change This change requires a mitigation entry in the release notes. label Sep 29, 2023
@jerpelea jerpelea added this to To-Add in Release Notes - 12.4.0 Dec 27, 2023
@jerpelea jerpelea moved this from To-Add to core in Release Notes - 12.4.0 Jan 8, 2024
@jerpelea jerpelea moved this from core to Not Applicable in Release Notes - 12.4.0 Jan 8, 2024
@jerpelea jerpelea moved this from Not Applicable to breaking in Release Notes - 12.4.0 Jan 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking change This change requires a mitigation entry in the release notes.
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

None yet

3 participants