I had a deeper look in your code and find the reason and a solution.
During reading your code I also find a few points which I tried to enhance. And I add some github actions.
Finally, I found the bug.
Using the test scripts provided in #20 leads with the code from this pull request to:
set value
uTimerLib v1.7.1
fast_samd21_tc v0.2.3
uTimerLib v[new]
1000000 us / 1 s
1000021.33 us
1000000.00 us
1000000.00 us
100000 us
100011.22 us
100000.00 us
100001.30 us
10000 us
10002.66 us
10000.00 us
10000.00 us
1000 us
1002.69 us
1000.00 us
1000.00 us
10 us
12.66 us
10.00 us
10.00 us
The calculation of the base delay was rounded. But it is not necessary to calculate with these rounded values. Using the precise values may enhance the result.
Some of the floating point calculation can be done as integer calculation without any need for rounding. This should enhance precision.
Using TC_CTRLA_WAVEGEN_MFRQ instead of TC_CTRLA_WAVEGEN_NFRQ makes setting _TC->COUNT.reg = 0; unnecessary and fixed the imprecise timing.
Are the github actions OK? Or do you want to stay on travis only?
fixed #20
I had a deeper look in your code and find the reason and a solution. During reading your code I also find a few points which I tried to enhance. And I add some github actions. Finally, I found the bug.
Using the test scripts provided in #20 leads with the code from this pull request to:
The calculation of the base delay was rounded. But it is not necessary to calculate with these rounded values. Using the precise values may enhance the result.
Some of the floating point calculation can be done as integer calculation without any need for rounding. This should enhance precision.
Using
TC_CTRLA_WAVEGEN_MFRQinstead ofTC_CTRLA_WAVEGEN_NFRQmakes setting_TC->COUNT.reg = 0;unnecessary and fixed the imprecise timing.