[MUSIC] Hello, I am glad to see you back for this lesson. In previous modules, we explored different types of embedded IoT operating systems. Now we will look into the details of Contiki and discover certain detailed behaviors. At the end of the lesson, you will be able to understand some of the challenges in developing IoT applications for Contiki. First of all, let's elaborate the title of today's lesson, Contiki, a hybrid operating system. Remember our discussion in previous module on operating system kernel designs? We discussed contiki as an example of a modular kernel design, combining features from monolithic and microkernel. This allows it to inherit some advantages of both systems. Contiki implements a hybrid model through an event driven kernel. In Contiki, preemptive multi-threading is implemented as an application library. This is optionally linked with the program, if the program requires multi-threading features. There are two key benefits when building a system like this. First, concurrency can be provided without the need of per-thread stacks or locking mechanisms. This benefit is evident by looking at why per-thread stacks are not suitable for embedded devices. Per-thread stack approach allocates a stack for each thread. It is hard to specify how much a thread requires. In addition, when a thread is created the memory for stack must be assign or allocated. This creates a problem, because memory assigned for specific task cannot be use by other concurrent test. The second benefit is that event driven model with the state driven programming are difficult for programmers to manage. In addition, not all programs can be expressed as state machines. Let's take an example of a purely event driven operating system. In such a system, a task could consume the full CPU time completely. When the task is complex and require a long CPU time, the system cannot respond to external events sometime. A preemptive multi-threaded system overcomes the problem in such situation. Hence, a hybrid system can be considered as the most suitable for such kind of problems. As I mentioned earlier, Contiki inheritance advantages from microperable design, and hence separates from the kernel from processors. This helps to reduce the kernel size as small as possible and consequently the probability of bulks can be dramatically reduce. Similar to microkernel design, Contiki also uses messaging mechanism for communication between services and the kernel. However, instead of using the peer messages discussed in micro kernel lesson, Contiki uses posting events. The only difference between pure messages and event posting is formatting. There is no hardware abstraction layer or HAL in Contiki. Therefore, the bias drivers and applications communicate directly with the hardware. In order to give you a better understanding of the pros and cons of removing hardware obstruction layer in Contiki, I will first discuss about the hardware obstruction layer. The hardware abstraction layer is a layer between application, component code, and hardware. In other words, HAL allows operating systems to interact with devices at an abstract level rather than a detailed hardware level. The main purposes of halt is to help the OS access hardware simply and portably via abstract API's regardless of the type of underlying hardware. Therefore, HAL has many advantages. For example, first it enables switching hardware. It is possible to switch to another hardware, such as a different microcontroller during development. As a result, there is less of a risk due to choosing suitable tools. Second, it allows cross development. It is not possible to develop application and components more conveniently. As a result, the development speed can be fast. In addition, a large-scale simulation environment can be built. Third, it results in less effort and less bugs. This enables a significant reduction in lines of code, which leads to less bugs. The final benefit is for automated unit testing. It is possible to run embedded software on a computer platform, extending the concept of continuous integration with automated unit tests. Although HAL has many advantages, it also has several drawbacks. Let's look at some of them. First, HAL cannot completely cover all available features of a particular hardware, such as a microcontroller. As a result, it limits some functionalities of the hardware. Possible conflict with other frameworks, libraries and components is the second drawback of HAL. The third problem is that it is hard or even possible to maintain the hold, especially in cleaning HALs mess. Finally, a number of lines of code increase dramatically when integrated into the OS. Currently, HAL is deprecated in different Linux distributions. Since Contiki is built for wireless sensor networks and embedded IoT devices, it is better off without HAL. Because of this, device drivers and applications communicate directly with the hardware. Based on a modular kernel approach, Contiki has the ability to load and unload models at run time. This allows Contiki to load only the necessary services, consequently allowing it to have a reduced kernel size. Almost all abstractions are implemented as libraries and services, except for CPU multiplexing, which is the only obstruction provided by the core system. The implementation is almost similar to a scheduler of microkernel. Looking at this implementation, Contiki is developed in C language, and it's applications are also written in C. Therefore, its is easy to develop application, reprogram, and replace services. Last but not least, Contiki is easily portable. This implies that it possible to run it on various microcontroller architectures such as the CC2538, CC2650, SensorTek, AdmilABR, and the MSP430, and so on. It is easy to add support for new microcontrollers using the built-in libraries and existing Contiki platform. For example, a programmer can easily port Contiki to their own board by creating configuration files for the specific microcontroller and edit existing general configuration files of Contiki. However, it is rare for a programmer to add a new microcontroller to the Contiki platform. As Contiki supports all popular micro controllers and embedded devices. This is all for the lesson about Contiki, a hybrid system. I hope that you got the important features of Contiki's kernel, and the hybrid model. We also discussed unique characteristics of Contiki, and its kernel. I hope to see you in the next video, which will further explain many advanced features of Contiki.
