Enable fixed timing between timer calls (vs fixed time btw. end of timer call and next call as implemented)

[AndreasOKircher]

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

[khoih-prog]

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-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 !!!

[AndreasOKircher]

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;

    }

[khoih-prog]

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,

[khoih-prog]

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

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

[AndreasOKircher]

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

[AndreasOKircher]

Hi Khoi Hoang,
finaly I tested the v1.3.1. It works fine !
Thanks Andreas

[khoih-prog]

Good to know. Waiting to receive more bug reports from you.

Thanks and Regards,