FAQs

FAQs

Dual Mode | Low Power | Interrupt | License | Performance

Dual Mode FAQ

What is a dual mode RTOS?

A Dual Mode Real Time Operating System is also called a convergent RTOS because it combines the traditional thread-based architecture with specialized fibers for DSP and dataflow operations. This unified kernel solution enables both types of application code to run fully optimized on a single processor.

What is the overhead of a dual mode RTOS?

There is no overhead. Q▪Kernel can be used for traditional thread based systems and high data-load systems only. Most developers start with the traditional thread based system and recognize later that there application need high performance fibers for data processing.

How fast is a dual mode RTOS compared to a traditional system?

Look for performance here. You will see that the system excels in cooperative scheduling. That is exactly what is done in high data-load applications.

Why don’t other systems implement dual mode?

A dual mode RTOS requires a completely different architecture and a complete re-write of the system.

Is investing in a dual mode RTOS expensive?

No, Q▪Kernel is just as expensive as or less expensive than a thread–only competitive RTOS. Q▪Kernel gives you best of both worlds.

How do fibers save RAM?

Fibers save RAM because they don’t need a stack like threads.

Can I use fibers instead of threads?

Yes, but not always. Fibers can not wait on an event, but in many cases that is not an issue because they can use non-blocking services. See the User Guide for examples which threads can be converted to fibers.

Top

Low Power FAQ

Does your RTOS support power management?

An application that has power restrictions can benefit from an RTOS. Q▪Kernel has integrated power management that helps the developer minimize power consumption. Applications and drivers are prompted by Q▪Kernel with the lowest possible power mode.

What is a tick-less RTOS and how does it decrease power consumption?

A tick specifies the smallest amount of time in which the RTOS can operate. With a tick-less RTOS, the smallest division of time is determined by one processor cycle, not the RTOS. Most RTOSes require a tick for time management and this causes the system to be frequently activated and drain power. Q▪Kernel is tick-less and thereby, completely eliminates looping and polling.

Top

Interrupt FAQ

It is impossible to never disable interrupts!

This is an incorrect statement. It is possible if there is hardware support for atomic test and set instructions and the implementation is based on the “Segmented Interrupt” architecture.

How important is it to not disable interrupts?

This is a very good question. Most competitive systems need to disable interrupts. The internal data structures need to be manipulated by system functions and interrupts are disabled to prevent these structures from getting corrupted. Most RTOSes disables interrupts for hundreds of machine cycles. Q▪Kernel never disables interrupts and still offers complete integration between the interrupt handling software, threads and fibers.

What is the interrupt latency?

It is zero. This means that the Q▪Kernel does not influence the interrupt response time. The 16-bit Microchip processors have a fixed 5 cycle hardware latency.

Is a “Segmented Interrupt” architecture slower?

The alternative of a “Segmented Interrupt” architecture is a unified interrupt architecture. Both architectures need the same time to complete all interrupt processing, but the difference is that the unified structure is not deterministic. If an interrupt need to be processed immediately it can sometimes take only 5 cycles to react but when a context switch is happening it takes 100 cycles. This is not deterministic.

Some big companies provide graphs that show that the “Segmented Interrupt” architecture is slower. What’s your comment?

We have seen those too. They manipulate the scale so it looks like the “Segmented Interrupt” architecture is slower. Don’t forget that all new embedded kernels are built with the “Segmented Interrupt” architecture. The big companies have too much interest in there current solution.

Top

License FAQ

Is the Basic distribution with its 12 threads useful in real life?
Yes. Don’t forget that Q▪Kernel is a dual mode RTOS so you can use threads and fibers. You can built an impressive system with 12 threads, 6 event sets, 6 mutexes, 6 semaphores, 6 queues, 4 pipes, 4 timers and an unlimited number of fibers.

Why do I have to specify a license key?

The 16 byte key specifies the customer number, customer name and license information. This information (16 bytes) is loaded in flash and we hope that it helps to prevent unauthorized copying.

Are there any advantages of a license key for me?

Yes, we distribute only one version of Q▪Kernel and the license is determined through the license key. We guarantee that all versions are exactly the same from demo to the site license. This means that the customer can download the latest version without having to wait on a specific customer version. It is also possible to upgrade the license without re-installing.

When do I need new license keys?

Never. The supplied license key never changes and can be used for all versions. The demo key is related to the release of Q▪Kernel. Every new version requires a new key.

How do you supply the license key?

We will send an Email that looks like the picture below:

This specifies the name of the customer, license number, license information and the license keys.

Does the license key slow down the application?

It slows down the initialization call qInit(). After the initialization there is no delay.

Top

Performance FAQ

Why is the interrupt processing so much faster than the competition?

The “Segmented Interrupt” architecture and the micro-kernel architecture provide the fast interrupt processing. The system just uses less cycles.

Why is the message processing so fast compare to the competition?

Q▪Kernel uses a micro-kernel architecture so sending and receiving of messages is fast because they don’t go deep in the kernel itself.

Why is cooperative so much faster compared to the competition?

This is because we do cooperative scheduling with fibers. Now some people will say that this is not fair, because traditional kernels have to do a full context switch and Q▪Kernel does not do that. Our reaction is that we can use our architecture to the fullest. We have to get the work done, in this case cooperative scheduling and it does not matter how we do it. Think outside the box.

Why is there so little performance difference in scheduling with the competition?

Most of the work in a context switch is saving and restoring the context (40 bytes for a PIC24). So it is not simple to make that process much faster. Q▪Kernel still performs the best and don’t forget that a system built with Q▪Kernel contains less threads because some of the threads can be handled as fibers.

Q▪Kernel wins all performance aspects sometimes with a big difference sometimes with a smaller difference. Why is that?

Q▪Kernel wins big if the architecture gives it specific advantages. The changes are smaller if there is no architecture advantage. We perform better in most categories because a big part of the kernel is written in assembler.

Top