This course is intended for the Bachelor and Master's students, who like practical programming and making IoTs applications!
In this course we will talk about two components of a cyber physical system, namely hardware and operating systems.
After completing this course, you will have the knowledge of both hardware components and operating systems. You are able to plan and use embedded operating systems in resource-constraint devices for Internet-of-Things (cyber physical system) applications. In addition, you can use Cooja simulation for designing and simulating wireless sensor network applications.
We have 4 modules, each with a graded quiz in the end and finally we have one peer reviewed programming assignment
In case you have no experience with C programming, please check you a practical course like:
https://www.coursera.org/learn/arduino-platform.
The course is actually quite fun at the end when you are playing around with Cooja simulation for IoTs applications. So you can create and simulate your own design for sensor network applications. A lot of features and examples of Contiki and Cooja can be explored via assignments. There are some optional assignments of wireless sensor network applications for students who want to explore more about embedded OS in IoTs applications.
- Marco Ramirez /University of Turku
- Igor Tcarenko/ University of Turku
- Nguyen Gia Tuan /University of Turku
Check out our whole curriculum: http://iot4health.utu.fi/

RA

it was very good introduction about ES hardware and good information about IOT Operating system

TP

Sep 16, 2018

Filled StarFilled StarFilled StarFilled StarFilled Star

Excellent resources provided by the instructor and emphasizes in gaining practical knowledge

從本節課中

Contiki OS and Cooja simulation

In this week, we start to explore the Contiki Os in detail. First we discuss about the Contiki system and its kernel architecture. Furthermore, we explore how loadable programs are actually implemented in Contiki. Second, we go through services and libraries in Contiki to see how they are built and when they can be invoked. Third, we discuss communication in Contiki via details of uIp and Rime communication stacks in Contiki. Next, prototheads are discussed to describe how application code is processed in Contiki. Furthermore, APIs of multi-threading is discussed. Last but not least, the Cooja simulator - a simulator for wireless sensor networks based on Contiki is introduced. All steps of installing and applying Cooja for a wireless sensor network applications are presented in detailed via an example application. Concretely, after attending this week, you will able to (1) describe how Contiki system and its kernel architecture are built. (2) Distinguish Contiki services and libraries in terms of how they are built, when they are invoked and why they are used. (3) Describe how communication is implemented and supported in Contiki and what protocols Contiki can support. (4) Explore how application's code is processed in Contiki and important functions of API for multithreading in Contiki (5) use Cooja for simulating wireless sensor networks applications.

教學方

Nguyen Gia Tuan

PhD

腳本

[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.