TheBackShed.com

Forum Index : Microcontroller and PC projects : Latency on pin interrupts on WebMite

Author

Message

OomNiel
Newbie

Joined: 06/11/2024
Location: South Africa
Posts: 3

Posted: 02:05pm 07 Nov 2024

Copy link to clipboard

Print this post

Good day all,
I was wondering if someone here can cast some light on the expected latency for pin interrupts using the Setpin function (e.g. Setpin GP2, intl, buttonIntHandler, pullup) in WebMite.

When running a simple program like:

option colourcode on
OPTION EXPLICIT
OPTION DEFAULT NONE
option autorun on

Setpin GP2, intl, buttonIntHandler, pullup
setpin GP3, dout
pin(GP3) = 0 'for testing int latency

'Main Loop
do
Timer = 0
Do while Timer < 2000:loop
pin(GP3) = 0
loop

'Interrupt handler for GP2 going low
sub buttonIntHandler
pin(GP3) = 1 'for testing latency
end sub

I get latency of between 57 to 87 micro-Seconds as shown in this image:

The blue trace is a simple button press and the yellow trace is the interrupt service routine toggling a pin high.

When a more substantial program is running, like pulling data from an MQTT broker the latency increases to about 10 mS and it can vary greatly (as much as 300 mS).

So my questions are:
1) What is the priority of pin interrupts using WebMite?
2) Why is the latency varying greatly depending on the complexity of the code?
3) Is there another route to follow in order to get constant uS latency on pin interrupts? (Using the PIO state machines perhaps?)
4) Are these varying latencies due to the nature of interpreted languages?

I have searched the forum but could not really find a conclusive answer.

Greetings,
Niel.

Mixtel90

Guru

Joined: 05/10/2019
Location: United Kingdom
Posts: 6761

Posted: 02:45pm 07 Nov 2024

Copy link to clipboard

Print this post

From the Webmite manual version 5.08.00

Quote Because interrupts run in the background they can cause difficult to diagnose bugs. Keep in mind the following
factors when using interrupts:

Interrupts are only checked by MMBasic at the completion of each command, and they are not latched by
the hardware. This means that an interrupt that lasts for a short time can be missed, especially when the
program is executing commands that take some time to execute. Most commands will execute in under
15µs however some commands such as the TEMPR() function can take up to 200ms so it is possible for
an interrupt to occur and vanish within this window and thus not be recognised.

When inside an interrupt all other interrupts are blocked so your interrupts should be short and exit as
soon as possible. For example, never use PAUSE inside an interrupt. If you have some lengthy
processing to do you should simply set a flag and immediately exit the interrupt, then your main program
loop can detect the flag and do whatever is required.

The subroutine that the interrupt calls (and any other subroutines or functions called by it) should always
be exclusive to the interrupt. If you must call a subroutine that is also used by an interrupt you must
disable the interrupt first (you can reinstate it after you have finished with the subroutine).

Remember to disable an interrupt when you have finished needing it – background interrupts can cause
strange and non-intuitive bugs.
In addition to interrupts generated by the change in state of an I/O pin, an interrupt can also be generated by
other sections of MMBasic including timers and communications ports and the above notes also apply to them.
The list of all these interrupts (in high to low priority ranking) is:
1. ON KEY individual
2. ON KEY general
3. PIO RX FIFO
4. PIO TX FIFO
5. PIO RX DMA completion
6. PIO TX DMA completion
7. Sprite Collisions
8. ADC completion
9. I2C Slave Rx
10. I2C Slave Tx
11. I2C2 Slave Rx
12. I2C2 Slave Tx
13. WAV Finished
14. COM1: Serial Port
15. COM2: Serial Port
16. IR Receive
17. Keypad
18. Interrupt command/CSub Interrupt
19. I/O Pin Interrupts in order of definition
20. Tick Interrupts (1 to 4 in that order)
As an example: If an ON KEY interrupt occurred at the same time as a COM1: interrupt the ON KEY interrupt
subroutine would be executed first and then, when the interrupt subroutine finished, the COM1: interrupt
subroutine would then be executed.

The exception is when SETPIN is used to set up COUNT pins. These use a hardware interrupt so override the above.

Mick

Zilog Inside! nascom.info for Nascom & Gemini
Preliminary MMBasic docs & my PCB designs

Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3194

Posted: 03:11pm 07 Nov 2024

Copy link to clipboard

Print this post

Due to the nature of the BASIC language and being an interpreter, interrupts are only checked when a command has completed (the one exception is the PAUSE command). Most commands complete quickly but some can take a long time (for example, the TEMP() function).

MMBasic was never intended for demanding applications that require fast and repeatable interrupts. For that the only way to go is to write your program in a compiler such as C/C++.

1) What is the priority of pin interrupts using WebMite?
These are listed in the manual (page 44).

2) Why is the latency varying greatly depending on the complexity of the code?
It all depends on how long a command will take to complete, especially on the WebMite with its Internet capability, that can be very variable.

3) Is there another route to follow in order to get constant uS latency on pin interrupts? (Using the PIO state machines perhaps?)
Not really, you are asking the BASIC interpreter to halt interpreting a command and start interpreting another set of commands. That has all sorts of complications including an enormous stack to hold the full context of the command being executed at the time of the interrupt. This applies to both PIO routines and embedded C routines.

4) Are these varying latencies due to the nature of interpreted languages?
In a nutshell, yes.

Geoff

Geoff Graham - http://geoffg.net

OomNiel
Newbie

Joined: 06/11/2024
Location: South Africa
Posts: 3

Posted: 08:59am 08 Nov 2024

Copy link to clipboard

Print this post

Thank you for sharing your expertise regarding this issue...much appreciated.
Regards,
Niel.

Print this page

To reply to this topic, you need to log in.