- Zero Latency -

What is Zero Latency and what advantages does this offer?

AVIX is a Zero Latency RTOS meaning it never disables interrupts. Meanwhile AVIX allows full integration between Interrupt Service Routines (ISR’s) and threads.

AVIX allows interrupt rates as high as 400 kHz on a PIC32 running at
80 MHz with full integration between the ISR and application threads!

An example of this is shown below but let’s first summarize all advantages:

  1. Incredible Performance; AVIX allows very high interrupt rates. Maybe your application does not need this now, but when using AVIX your application is prepared for enhancements without the risk these enhancements hit a performance barrier.
     
  2. Predictable Interrupt Latency; to determine the interrupt latency the figures from the hardware specification can be used. AVIX offers zero added latency, now and in all future versions. Competing products often don’t even specify the interrupt latency which may change with a new version of these RTOSes and break your application when upgrading.
     
  3. Freedom of choice; AVIX functions never disable interrupts so you don’t have to worry if certain functions have an unacceptable effect on your application. You can use all AVIX functions when needed. With competing products, the time interrupts are disabled differs per function. Starting to use a function not used until then can break your application.

 

 

How good is interrupt performance with Zero Latency?

AVIX running on a 80 MHz PIC32 allows an interrupt to occur every 2.5µs or in other words, 400,000 interrupts per second with full communication between the ISR and a thread without losing a single interrupt! No competing product is able to reach this level of performance without loosing a lot of interrupts provided the application will work in the first place.
 

To illustrate this, use is made of a basic demo application. This application consists of a timer based ISR which fires every 2.5µs. The ISR writes an integer to a pipe. The other end of the pipe is read by a thread. This thread is activated every time the pipe contains 50 integers. Meanwhile two other threads, having a higher priority, are sleeping for some time after which they read a single integer from the same pipe. The structure of this application is shown in the figure to the right.

The AVIX tracing mechanism (Thread Activation Tracing) allows realtime monitoring of the activity of this application using a Logic Analyzer. For this purpose, the ISR toggles an I/O port so the activation of the ISR can be monitored also. Finally the idle thread (the active thread when no applications threads are running) is monitored.

The timing diagram of this application is shown in the figure below. Here can be seen that all three threads are running and there is even spare time allowing the idle thread to run. Move your mouse over the picture to zoom in and see the interrupts occur every 2.5µs.

Actual interrupt rates may be lower, based on code complexity

PerformanceDemonstratingApp

 

 

Why do competing products disable interrupts?

An RTOS contains complex internal data structures which are constantly being updated as a result of functions being called from the application. These same functions however are used by ISR’s and to protect these data structures against corruption, while being updated by a function call from a thread the RTOS simply disables interrupts. The effect of this however is that interrupt performance for most RTOSes is average and no RTOS is able to reach the interrupt performance provided by AVIX.

AVIX is based on a unique architecture which differs from that used by competing products. As a result AVIX can update its internal data structures and still allow ISR’s to use AVIX functions concurrently.

 

 

Do other RTOSes also offer this feature?

There are RTOSes also claiming Zero Latency interrupt handling but most of these implementations have a very severe drawback in that the ISR’s are not allowed to use RTOS functions. As a result these ISR’s are ‘stand alone’, they can not communicate with threads and when this is needed a custom mechanism must be constructed. Since one of the reasons to use an RTOS in the first place is integration between ISR’s and threads, this approach is useless and it is misleading to call this Zero Latency. An RTOS only deserves this title when it offers Zero Latency combined with full integration between the ISR and threads.

AVIX-RT © 2006-2010, All Rights Reserved

Legal Disclaimer

Privacy Policy