Eclipse Kiso

With the insight of software solutions used in IoT devices, it is not hard to find out that the need for an OS independent IoT device software is indeed there. There are plenty of software products out there, and some of them are full stack including RTOS, drivers, network stack and almost everything; some of them are pure RTOS. Eclipse Kiso is not locked in by any RTOS and is designed with the idea of being RTOS neutral. It comes out of the box working on top of FreeRTOS, which is one of the market leaders, but it can be easily adapted to any other RTOS.

Eclipse Kiso appears here more as a friendly value add-on than as a competitor. For instance, if developers do not want to be locked into any specified RTOS, they can choose Kiso and then take whatever RTOS based on their personal needs. Even when comparing Kiso and Zephyr (full software stack including RTOS), Kiso still has the potential of being adapted on Zephyr’s kernel to fulfill certain needs.

Kiso BSP brings huge benefits for the end product. The splitting of the hardware abstraction layer into two sub-components MCU and BSP is the natural consequence of a translation of the circuit board of an embedded product into code, where the BSP takes care of the Board representation and peripherals configuration, and the MCU implements the core assets of a micro-controller's resources without the burden of configuration, which makes code portability to different microcontrollers a seamless task.

For constrained embedded systems, during handover from hardware developer to the software developer five major questions are  to be answered:

1. How are the components routed (CONNECTED) to the microcontroller?

2. What is to be done in order to bring a component to the operational state (ENABLED) ?

3. What is to be done in order to bring a component to OFF state (DISABLED) ?

4. Once the Component is disabled what GPIO configurations do we need to maintain in order to achieve the lowest power consumption safest state(DISCONNECTED) ?

5. What special considerations need to be taken to keep the whole system in operational state ?

Those questions are the core of the Kiso BSP concept, and their answer is directly translated into code in the implementation.

Another point worth a mention here is Kiso’s efficient use of hardware resources. As seen from the chart, for a simple application for BT connected sensors, its footprint is only 114kB on flash and 22kB RAM for operation. When it comes to GSM cellular IP based network with complex algorithms, it uses 633kB flash and 124kB RAM. Comparing to even a bare Linux OS without application, it is quite lightweight and can satisfy most resource constrained IoT user cases.