/*! @page q_background Overview
* @tableofcontents
*
* @section q_about About the OS
* QuarkTS++ (the C++ port of <a style="font-weight:bold" href="https://github.com/kmilo17pet/QuarkTS">QuarkTS</a>)
* is an open-source operating system that is built on top of a
* <em>RTC cooperative quasistatic scheduler</em>. Its simplified kernel
* implements a specialized round-robin scheme using a  linked-chain approach and
* an event-queue to provide true FIFO priority scheduling.
*
* <b> Why cooperative? </b>
*
* 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...).
*
* <b> What is it made for? </b>

* 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 @ref q_fsm support, @ref q_qcoroutines, 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
*
* <b>Why should I choose it?</b>
*
* QuarkTS++ is not intended to replace o compete with other great and proven
* RTOS options already available today, for example, FreeRTOS, Zephyr 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.
*
* @section q_license 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 <a style="font-weight:bold" href="https://writing.kemitchell.com/2016/09/21/MIT-License-Line-by-Line.html">MIT License</a> line by line.
*
*
* @section q_hardwarecompatibility 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, RL78/Gxx
* - HCS12, ColdFire, MSP430
* - PIC (PIC24, dsPIC, 32MX, 32MZ)
* - Arduino support for all architectures (available from the <a style="font-weight:bold" href="https://www.ardu-badge.com/QuarkTS">Library Manager</a>)
*
* @section q_codstandard Development process and coding standard
* QuarkTS is developed using a formal and rigorous process framed in compliance
* of the <a style="font-weight:bold" href="https://www.misra.org.uk/">MISRA C++ 2008</a>
* and <a style="font-weight:bold" href="https://wiki.sei.cmu.edu/confluence/display/c/SEI+CERT+C+Coding+Standard">SEI CERT coding standard</a>
* 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 <b>C++11</b> standard strictly.
* - Dynamic memory allocation is banned to conform the industry standards for
* safety-critical software: @b MISRA-C++, @b DO178B, @b IEC-61508, @b ISO-26262
* and so on.
* - Because errors in raw-string manipulation have long been recognized as a leading
* source of buffer overflows in C/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
* @c stdint.h with typedefs that indicate size and signedness in place of the basic
* types.
* - In line with @b MISRA guides, unqualified standard @c char and @c char* types
* are only permitted to hold ASCII characters and strings respectively.
* - The @c _t suffix is used to denote a type definition (i.e @c base_t ,
* @c signal_t , @c cycles_t, ...).
* - Enum values and constants are written in all upper case.
* - Almost all functions returns a boolean value of type @c bool, where a
* @c true - @c 1u value indicates a successful procedure and @c false - @c 0u,
* the failure of the procedure
*
* @section q_memusage 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 @c 3.7Kb of code space and less
* than @c 1Kb of data space.
*
* <center>
* <table>
* <caption id="multi_row">OS Memory footprint (Measured in a 32-bit MCU)</caption>
* <tr><th>Functionality  <th>Size(bytes)
* <tr><td> Kernel, scheduler and task management <td>2637
* <tr><td> A task node @c qOS::task <td>68
* <tr><td> Finite State machines(FSM) handling and related APIs <td>314
* <tr><td> A FSM object @c qOS::stateMachine <td> 100
* <tr><td> A state object @c qOS::sm::state <td> 36
* <tr><td> Timers handling and related APIs <td> 258
* <tr><td> A Timer object @c qOS::timer <td> 8
* <tr><td> Queues handling and related APIs <td> 544
* <tr><td> A queue object @c qOS::queue <td> 28
* <tr><td> Memory management <td> 407
* <tr><td> A memory pool <td> 28
* <tr><td> The AT Command Line Interface <td> 1724
* <tr><td> An AT-CLI instance @c qOS::commandLineInterface <td> 112
* <tr><td> An AT-CLI command instance @c qOS::cli::command <td> 24
* <tr><td> Remaining utilities <td> 2980
* </table>
* </center>
*
*/
