OS  v7.3.3
Documentation
Overview

About the OS

QuarkTS is an open-source operating system that is built on top of a RTC cooperative quasistatic scheduler. Its simplified kernel implements a specialized round-robin scheme using a linked-chain approach and an event-queue to provide true FIFO priority scheduling.

Why cooperative?

Rather than having preemption, tasks manage their own life-cycle. This bring significant benefits, fewer re-entrance problems are encountered, because tasks cannot be interrupted arbitrarily by other tasks, but only at positions permitted by the programmer, so you mostly do not need to worry about pitfalls of the concurrent approach(resource sharing, races, deadlocks, etc...).

What is it made for?

The design goal of QuarkTS is to achieve its stated functionality using a small, simple, and (most importantly) robust implementation to make it suitable on resource-constrained microcontrollers, where a full-preemptive RTOS is an overkill and their inclusion adds unnecessary complexity to the firmware development. In addition with a Finite State Machines (FSM) support, Co-Routines, time control and the inter-task communication primitives, QuarkTS provides a modern environment to build stable and predictable event-driven multitasking embedded software. Their modularity and reliability make this OS a great choice to develop efficiently a wide range of applications in low-cost devices, including automotive controls, monitoring and Internet of Things

Why should I choose it?

QuarkTS is not intended to replace o compete with other great and proven RTOS options already available today, for example, FreeRTOS or MicroC/OS-II, in fact, you should check these options first. However, due to its size and features, is intended to play in the space between RTOSes and bare metal. QuarkTS was written for embedded developers who want more functionality than what existing task schedulers offer, but want to avoid the space and complexity of a full RTOS, while keeping the taste of a robust and safe one.

License

QuarkTS is licensed under the MIT License. You may copy, distribute and modify the software without any restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the OS, and to permit persons to whom the OS is furnished to do so. This OS is provided as is in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

For more details, see the MIT License line by line.

Hardware compatibility

QuarkTS has no direct hardware dependencies, so it is portable to many platforms and C compilers.

The following cores have been powered with QuarkTS successfully:

  • ARM cores(ATMEL, STM32, LPC, Kinetis, Nordic and others)
  • 8Bit AVR, 8051, STM8
  • HCS12, ColdFire, MSP430
  • PIC (PIC24, dsPIC, 32MX, 32MZ)

Development process and coding standard

QuarkTS is developed using a formal and rigorous process framed in compliance of the MISRA C 2012 and SEI CERT coding standard guidelines and complemented with multiple static-analysis checks targeted to safe critical applications.

Simply using QuarkTS in an application, does not mean developers can make a claim related to the development process and compliance of the OS to any requirements or product specification, without first, following a recognized system-wide conformance verification process. Conformance evidence must then be presented, audited and accepted by a recognized and relevant independent assessment organization. Without undergoing this process of due diligence, no claim can be made as to the suitability of QuarkTS to be used in any safety or otherwise commercially critical application.

Besides the previous information, the OS sets the following clarifications regarding coding policies and naming conventions:

  • All the QuarkTS implementation follows the ANSI C99 standard strictly.
  • Dynamic memory allocation is banned to conform the industry standards for safety-critical software: MISRA-C, DO178B, IEC-61508, ISO-26262 and so on.
  • Because errors in string manipulation have long been recognized as a leading source of buffer overflows in C, several mitigation strategies have been devised. These include mitigation strategies designed to prevent buffer overflows from occurring and strategies designed to detect buffer overflows and securely recover without allowing the failure to be exploited.
  • In line with MISRA guides and for portability between platforms, we use the stdint.h with typedefs that indicate size and signedness in place of the basic types.
  • In line with MISRA guides, unqualified standard char and char* types are only permitted to hold ASCII characters and strings respectively.
  • The _t suffix is used to denote a type definition (i.e qBool_t , qTask_t , size_t, ...).
  • Functions, macros, enum values and data types are prefixed q. (i.e. qFunction, qEnumValue, QCONSTANT, qType_t, ...)
  • Other than the pre-fix, most macros used for constants are written in all upper case.
  • Almost all functions returns a boolean value of type qBool_t, where a qTrue - 1u value indicates a successful procedure and qFalse - 0u, the failure of the procedure

Memory usage

As a quasi-static scheduler is implemented here, dynamic scheduling is not required and the assignment of tasks must be done before program execution begins. The kernel is designed to allow unlimited tasks and kernel objects, but of course, the whole application will be constrained by the memory specifications of the embedded system.

The kernel's memory footprint can be scaled down to contain only the features required for your application, typically 3.7Kb of code space and less than 1Kb of data space.

OS Memory footprint (Measured in a 32-bit MCU)
Functionality Size(bytes)
Kernel, scheduler and task management 2637
A task node qTask_t 68
Finite State machines(FSM) handling and related APIs 314
A FSM object qSM_t 100
A state object qSM_State_t 36
STimers handling and related APIs 258
A STimer object qSTimer_t 8
Queues handling and related APIs 544
A queue object qQueue_t 28
Memory management 407
A memory pool 28
The AT Command Line Interface 1724
An AT-CLI instance qATCLI_t 112
An AT-CLI command instance qATCLI_Command_t 24
Remaining utilities 2980