With IoT booming in recent years, more and more IoT applications come into the world. On “Things” level, software runs on resource constrained devices to collect sensor data and send it to cloud, for which different companies and hardware vendors provide various solutions. Eclipse Kiso is one of the solutions, but designed in a way that it can run on any RTOS or even without RTOS.
Eclipse Kiso was designed from scratch as a software development kit for IoT devices and has already been used and verified on a handful of existing products in the market. Eclipse Kiso’s reusability, robustness and portability is a key factor which enables fast development and quick time to market for almost all kinds of IoT “Things” product development.
The Eclipse Kiso software stack is mainly developed in C, including a core component “essentials” and HAL, device drivers, network support, FOTA etc.
-
Essentials comes to serve the needs for agility in software and hardware development, where changing the underlying OS and hardware does not necessarily mean scrapping all the already developed code. It defines HAL APIs and includes an OS adaption layer.
-
HAL (Hardware Abstraction Layer) which consists of two sub-components: BSP (Board Support Package) and MCU (Micro Controller Unit). If an application needs to migrate from a hardware A to hardware B it needs to have the BSP/MCU for the B hardware without the need to port the entire application.
-
Device drivers are provided for common devices normally available for IoT application, and more drivers will be added in the roadmap as more hardware platforms are supported.
-
Network support is also in place. Kiso includes a generic network stack itself and at the same time adapts third party solutions for supporting BLE, Wlan, LoRa and popular cellular network features.
-
FOTA (Firmware Over-the-Air) is also an important feature in Kiso for IoT devices. It is an efficient and automatic way of distributing software update, configuration and also a way of device management.
In addition to the software stack, the Eclipse Kiso provides hardware reference designs including schematics, block diagrams, and datasheets. This is not necessary for using Eclipse Kiso software part, but could be interested when developers want to develop their own hardware. Kiso will run and test on the hardware reference designs before they are published.
Moreover, relevant environment regarding toolchains, continuous integration setup, test framework and documentation will also be available.
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:
-
How are the components routed (CONNECTED) to the microcontroller?
-
What is to be done in order to bring a component to the operational state (ENABLED) ?
-
What is to be done in order to bring a component to OFF state (DISABLED) ?
-
Once the Component is disabled what GPIO configurations do we need to maintain in order to achieve the lowest power consumption safest state(DISCONNECTED) ?
-
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.
As part of IoT ecosystem, Kiso can enrich the projects in Eclipse community, especially in IoT area. For example, the Elipse Mita project was originated and works well alongside with Kiso. The Kiso team has good experience writing application for Kiso with Mita and vice versa. In the same way, it can make Kiso a plus for many other IoT projects. With Kiso going public, it is going to be definitely a contribution in open source community.
Kiso is mainly developed in house with only one copyright owner and does not depend on GPL/LGPL libs, we do not see obvious legal issue here.
- 15 April, 2019, the first code drop should be ready
- 6 May, 2019, first build running on reference hardware
More drivers
network stack
New MCU support
BT stack
New IoT connectivities
Toolchain update
CI (continues intigration)