Ardunio IDE 1.8.19
RP2040 core v2.5.2
RPI_PICO_TimerInterrupt 1.2.0
Adafruit Feather
Windows
Issue
I struggled to get a precise timing for repeating timer interrupts (using RPI_PICO_Timer X and X.setFrequency(.....) )
Eg. instead of expected 5000 hz, I get 4950 Hz, always little slower than intended (measured with Oszi)
Proposal
In the PICO SDK the function 4.2.14.4.2. add_repeating_timer_us has the option to pass the variable delay_us in positive and negative form. If positive values are passed and this leads to exact timing btw. end of timer interrupt call and the next timer interrupt call ( The way the libary is implemented (at least in setFrequency)
If negativ values are passed this leads to same intervalls btw. start of timer interrupt.
At least for me the passing negativ values to function add_repeating_timer_us solved the issue and the timer interrupt frequency is as expected.
Maybe you can give both options to set timers.
Many Thanks for your great work !
Andreas
Ardunio IDE 1.8.19
RP2040 core v2.5.2
RPI_PICO_TimerInterrupt 1.2.0
Adafruit Feather
Windows
### Issue
I struggled to get a precise timing for repeating timer interrupts (using RPI_PICO_Timer X and X.setFrequency(.....) )
Eg. instead of expected 5000 hz, I get 4950 Hz, always little slower than intended (measured with Oszi)
### Proposal
In the PICO SDK the function 4.2.14.4.2. **add_repeating_timer_us** has the option to pass the variable **delay_us** in positive and negative form. If positive values are passed and this leads to exact timing btw. end of timer interrupt call and the next timer interrupt call ( The way the libary is implemented (at least in setFrequency)
If negativ values are passed this leads to same intervalls btw. start of timer interrupt.
At least for me the passing negativ values to function **add_repeating_timer_us** solved the issue and the timer interrupt frequency is as expected.
Maybe you can give both options to set timers.
Many Thanks for your great work !
Andreas
Please follow the instructions in Issue: Bug report, such as adding MRE, your special use-case, terminal debug messages, etc. to illustrate your points.
It's really hard and time-consuming to read thru the tea-leaves or have a good crystal ball to guess what you meant and to have actionable ideas.
I'm closing the issue now, and will reopen when you post the better enhancement request !!!
Hi @AndreasOKircher
Please follow the instructions in [**Issue: Bug report**](https://github.com/khoih-prog/RPI_PICO_TimerInterrupt/issues/new?assignees=&labels=&template=bug_report.md&title=), such as adding [**MRE**](https://stackoverflow.com/help/minimal-reproducible-example), your special use-case, terminal debug messages, etc. to illustrate your points.
It's really hard and `time-consuming` to read thru the tea-leaves or have a good crystal ball to guess what you meant and to have actionable ideas.
I'm closing the issue now, and will reopen when you post the better enhancement request !!!
Hi,
there are two approached how reocurring events can be defined in regards of timing (and accordingly when the corrosponding timer function starts) :
The Pico SDK offers both options. Please refer to the Pico SDK (https://datasheets.raspberrypi.com/pico/raspberry-pi-pico-c-sdk.pdf).
Both functions 4.2.14.4.1. add_repeating_timer_ms and 4.2.14.4.2. add_repeating_timer_us offer these option.
For option "end to start" you pass the variable delay_us / delay_ms in positive number, for option "start to start" you pass the argument in negativ numbers.
(I think the different behavior is not very good explained...)
In the implementation of RPI_PIC_TimerInterrupt option "start to end" is used, for some users "start to start" is usefull, therefore would be nice to have both options.
If your timer events are "low frequency" type option "start to end" and "start to start" behave similar, but the higher the event rate gets and the duration of timer function makes a difference.
Hope this explains better
Andreas
Addendum :
In case of the setFrequency functions this would look like this :
bool setFrequency(const float& frequency, pico_timer_callback callback)
{
_frequency = frequency;
_timerCount = (int64_t) TIM_CLOCK_FREQ / frequency; // changed uint_64t to int64_t -> than you can pass negativ values !
_callback = callback;
cancel_repeating_timer(&_timer);
add_repeating_timer_us(_timerCount, _callback, NULL, &_timer);
return true;
}
Hi,
there are two approached how reocurring events can be defined in regards of timing (and accordingly when the corrosponding timer function starts) :
The Pico SDK offers both options. Please refer to the Pico SDK (https://datasheets.raspberrypi.com/pico/raspberry-pi-pico-c-sdk.pdf).
Both functions 4.2.14.4.1. **add_repeating_timer_ms** and 4.2.14.4.2. **add_repeating_timer_us** offer these option.
For option "end to start" you pass the variable delay_us / delay_ms in positive number, for option "start to start" you pass the argument in negativ numbers.
(I think the different behavior is not very good explained...)
In the implementation of RPI_PIC_TimerInterrupt option "start to end" is used, for some users "start to start" is usefull, therefore would be nice to have both options.
If your timer events are "low frequency" type option "start to end" and "start to start" behave similar, but the higher the event rate gets and the duration of timer function makes a difference.
Hope this explains better
Andreas
Addendum :
In case of the setFrequency functions this would look like this :
```
bool setFrequency(const float& frequency, pico_timer_callback callback)
{
_frequency = frequency;
_timerCount = (int64_t) TIM_CLOCK_FREQ / frequency; // changed uint_64t to int64_t -> than you can pass negativ values !
_callback = callback;
cancel_repeating_timer(&_timer);
add_repeating_timer_us(_timerCount, _callback, NULL, &_timer);
return true;
}
Thanks so much for your detailed research and explanation, which led me to recheck the document and aware of my severe mistake. There is so much a guy can do, if not relying on the help of other people.
delay_ms the repeat delay in milliseconds; if >0 then this is the delay between one callback ending and the next
starting; if <0 then this is the negative of the time between the starts of the callbacks. The value of 0 is treated as 1
microsecond
I'll fix the severe bug to let users to set fixed timing between timer calls by using the negative delay
Just wonder, in your valuable opinion, if it's necessary to permit users to use both positive and negative delay options as it seems confusing, difficult to use and not popular (delay between one callback ending and the next starting)
Best Regards,
Hi @AndreasOKircher
Thanks so much for your detailed research and explanation, which led me to recheck the document and aware of my **severe mistake**. There is so much a guy can do, if not relying on the help of other people.
> delay_ms the repeat delay in milliseconds; if >0 then this is the delay between one callback ending and the next
> starting; if <0 then this is the negative of the time between the starts of the callbacks. The value of 0 is treated as 1
> microsecond
I'll fix the severe bug to let users to set `fixed timing between timer calls` by using the `negative` delay
Just wonder, in your valuable opinion, if it's necessary to permit users to use both `positive` and `negative` delay options as it seems confusing, difficult to use and not popular (`delay between one callback ending and the next starting`)
Best Regards,
Hi @AndreasOKircher
I'm in the middle of doing something else, but couldn't wait and have fixed / released the new [**RPI_PICO_TimerInterrupt** v1.3.0](https://github.com/khoih-prog/RPI_PICO_TimerInterrupt/releases/tag/v1.3.0)
Your contribution is noted at [**Contributions and Thanks**](https://github.com/khoih-prog/RPI_PICO_TimerInterrupt#contributions-and-thanks)
Please test and inform if it's OK now.
Regards,
---
### Releases v1.3.0
1. Fix severe bug affecting time between the starts. Check [**Enable fixed timing between timer calls (vs fixed time btw. end of timer call and next call as implemented)** #3](https://github.com/khoih-prog/RPI_PICO_TimerInterrupt/issues/3)
And if you ask me about if both implementations are needed, my feeling
is that most needed is start-to-start option and the other end-to-start
is a nice to have.
I never new this different timing is anywhere existing until recently,
but the Raspberryy colleagues had for shure reasons for implementing I
am not aware of.
But it should be clearly stated or even better with a different
interface realized, else I assume other would run in similar issues just
by overlooking this small but important difference.
Regards Andreas
Hi Khoi Hoang,
I will test your release during this week.
And if you ask me about if both implementations are needed, my feeling
is that most needed is start-to-start option and the other end-to-start
is a nice to have.
I never new this different timing is anywhere existing until recently,
but the Raspberryy colleagues had for shure reasons for implementing I
am not aware of.
But it should be clearly stated or even better with a different
interface realized, else I assume other would run in similar issues just
by overlooking this small but important difference.
Regards Andreas
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Ardunio IDE 1.8.19
RP2040 core v2.5.2
RPI_PICO_TimerInterrupt 1.2.0
Adafruit Feather
Windows
Issue
I struggled to get a precise timing for repeating timer interrupts (using RPI_PICO_Timer X and X.setFrequency(.....) )
Eg. instead of expected 5000 hz, I get 4950 Hz, always little slower than intended (measured with Oszi)
Proposal
In the PICO SDK the function 4.2.14.4.2. add_repeating_timer_us has the option to pass the variable delay_us in positive and negative form. If positive values are passed and this leads to exact timing btw. end of timer interrupt call and the next timer interrupt call ( The way the libary is implemented (at least in setFrequency)
If negativ values are passed this leads to same intervalls btw. start of timer interrupt.
At least for me the passing negativ values to function add_repeating_timer_us solved the issue and the timer interrupt frequency is as expected.
Maybe you can give both options to set timers.
Many Thanks for your great work !
Andreas
Hi @AndreasOKircher
Please follow the instructions in Issue: Bug report, such as adding MRE, your special use-case, terminal debug messages, etc. to illustrate your points.
It's really hard and
time-consumingto read thru the tea-leaves or have a good crystal ball to guess what you meant and to have actionable ideas.I'm closing the issue now, and will reopen when you post the better enhancement request !!!
Hi,
there are two approached how reocurring events can be defined in regards of timing (and accordingly when the corrosponding timer function starts) :
The Pico SDK offers both options. Please refer to the Pico SDK (https://datasheets.raspberrypi.com/pico/raspberry-pi-pico-c-sdk.pdf).
Both functions 4.2.14.4.1. add_repeating_timer_ms and 4.2.14.4.2. add_repeating_timer_us offer these option.
For option "end to start" you pass the variable delay_us / delay_ms in positive number, for option "start to start" you pass the argument in negativ numbers.
(I think the different behavior is not very good explained...)
In the implementation of RPI_PIC_TimerInterrupt option "start to end" is used, for some users "start to start" is usefull, therefore would be nice to have both options.
If your timer events are "low frequency" type option "start to end" and "start to start" behave similar, but the higher the event rate gets and the duration of timer function makes a difference.
Hope this explains better
Andreas
Addendum :
In case of the setFrequency functions this would look like this :
Hi @AndreasOKircher
Thanks so much for your detailed research and explanation, which led me to recheck the document and aware of my severe mistake. There is so much a guy can do, if not relying on the help of other people.
I'll fix the severe bug to let users to set
fixed timing between timer callsby using thenegativedelayJust wonder, in your valuable opinion, if it's necessary to permit users to use both
positiveandnegativedelay options as it seems confusing, difficult to use and not popular (delay between one callback ending and the next starting)Best Regards,
Hi @AndreasOKircher
I'm in the middle of doing something else, but couldn't wait and have fixed / released the new RPI_PICO_TimerInterrupt v1.3.0
Your contribution is noted at Contributions and Thanks
Please test and inform if it's OK now.
Regards,
Releases v1.3.0
Hi Khoi Hoang,
I will test your release during this week.
And if you ask me about if both implementations are needed, my feeling
is that most needed is start-to-start option and the other end-to-start
is a nice to have.
I never new this different timing is anywhere existing until recently,
but the Raspberryy colleagues had for shure reasons for implementing I
am not aware of.
But it should be clearly stated or even better with a different
interface realized, else I assume other would run in similar issues just
by overlooking this small but important difference.
Regards Andreas
Hi Khoi Hoang,
finaly I tested the v1.3.1. It works fine !
Thanks Andreas
Good to know. Waiting to receive more bug reports from you.
Thanks and Regards,