What timer interrupts are enabled in RP2040 Zeptoforth?

[robzed]

Specifically I'm interested in any timer interrupts used in 'zeptoforth_full-1.0.2.uf2' and 'zeptoforth_full_usb-1.0.2.uf2' - what ones are used for what purposes? I guess there a few vectors just for exception handling, a bunch for serial TX/RX on different devices. But what about other uses, e.g. system timer - is there more than one, and what timers are used to drive this? What frequency does the system timer run at?

Somewhere else you wrote: "you could have to save the zeptoforth interrupt handlers and replace them with non-zeptoforth (or just empty : DO-NOTHING ; ) interrupt handlers and restore them when you were done."

If I wanted to use the system timer to drive some periodic hardware - if there a way to do this, or should I replace the base call then call the standard Zeptoforth timer interrupt? I read this zeptoforth-1.0.2/docs/words/timer.html, and it seems like alarms would allow me to stable timer interrupt at, say 2ms? And replacing the system interrupt sounds very horrid.

Also is the limitations of Forth during interrupt routines documented?

[robzed]

I read this https://github.com/tabemann/zeptoforth/wiki/Pulse-Width-Modulation-and-Hardware-Timers-in-zeptoforth-on-the-Raspberry-Pi-Pico

I assume the multitasking is done on SysTick.

I'm not sure how to get a non-slipping timer with the RP2040 alarm timers, since they are one shot.

[tabemann]

As for jitter, I have not measured that, and it does depend on what you are doing, because for the more time spent in interrupt handlers and the more load the more jitter there will be.

[tabemann]

Well there is one but there - even though the SysTick runs at ~100 us intervals, the scheduler runs at ~1 ms intervals unless pause is being deliberately called, where then it may schedule tasks faster than that. So do not expect scheduling resolution smaller than 1 ms.

[robzed]

So if I have a 2ms task that is higher priority than other tasks, then it should get scheduled every 2ms, but it could be up to 1ms late, except if the lower priority tasks were calling pause more than that?

[robzed]

Is there an example of using task::delay to implement a non-slip loop inside a task?

[tabemann]

Yes, you should note assume that the multitasker schedules tasks with any less than 1 ms resolution, even though in many cases it may be higher resolution (e.g. a blocking operation is effectively a pause).

[tabemann]

An example of a non-slipping loop using task::delay is:

task import
systick import

\ Our delay
2500 constant our-delay-ticks

: non-slip-test
  0 [:
    systick-counter 0 { start-tick counter }
    begin
      our-delay-ticks start-tick current-task delay
      counter .
      1 +to counter
      our-delay-ticks +to start-tick
    again
  ;] 320 128 512 spawn run
;

non-slip-test

This will output the counter once every 250 ms while not slipping.

[robzed]

As for the hardware timers/alarms in the timer module, none of these are allocated out of the box, so you can do with them whatever you wish. Due to how they are implemented in hardware, though, it is hard to implement completely non-slipping timers with them (you can calculate the delays ahead of time, but there will always be some non-precision). On the other hand, they have far greater precision than SysTicks, as they can be triggered on specific microseconds.

Would this act as a non-slipping timer? Effectively we start with a fixed start time, then reset the next alarm count. I did think about alternating between two alarms, but this appears not necessary. Obviously I'll need to set the interrupt priorities up correctly.

0 constant ROBOT-TICK-ALARM
2000 constant ROBOT-TICK-MICROSECS
variable next-robot-tick
variable robot-tick-xt

: set-next-alarm
    \ set the next interrupt time
    ROBOT-TICK-MICROSECS next-robot-tick +!
    next-robot-tick @
    robot-tick-xt @ ROBOT-TICK-ALARM set-alarm
;

: robot-tick
    set-next-alarm

    \ clear this interrupt
    0 clear-alarm-int

    ( do work here )
;

: setup-robot-tick
    ['] robot-tick robot-tick-xt !
    timer::us-counter-lsb next-robot-tick !
    set-next-alarm
;

[robzed]

Updated to correct errors and simplify code.

[tabemann]

The only problem with this setup is when next-robot-tick plus ROBOT-TICK-MICROSECS is in the past ─ then it will have to wrap around the 32-bit time before the timer interrupt is triggered. This is why it is hard to make a non-slipping timer using the timer interrupt.

Here is my attempt at making a non-slipping timer, using your code:

timer import

0 constant ROBOT-TICK-ALARM
2000 constant ROBOT-TICK-MICROSECS
variable next-robot-tick
variable robot-tick-xt

\ DEBUG
variable counter

: set-next-alarm
    \ set the next interrupt time
    begin
      ROBOT-TICK-MICROSECS next-robot-tick +!
      next-robot-tick @ us-counter-lsb - 0> dup not if
        robot-tick-xt @ execute
      then
    until
    next-robot-tick @
    robot-tick-xt @ ROBOT-TICK-ALARM set-alarm
;

: robot-tick
    set-next-alarm

    \ clear this interrupt
    0 clear-alarm-int

    ( do work here )
    
    \ DEBUG
    1 counter +!
;

: setup-robot-tick
    \ DEBUG
    0 counter !

    ['] robot-tick robot-tick-xt !
    timer::us-counter-lsb next-robot-tick !
    set-next-alarm
   
    \ DEBUG 
    0 [: counter @ begin counter @ tuck <> if dup . then again ;] 320 128 512 task::spawn task::run
;

Note that this code is not perfect ─ it may still break for very small values of ROBOT-TICK-MICROSECS. However, for larger values like you are using here, it should be okay in most use cases ─ but it is still not guaranteed to work.