2016 10th International Symposium on Communication Systems, Networks and Digital Signal Processing (CSNDSP)
Application of Real Time Operating System in the Internet of Things
Adam Kaliszan
Poznan University of Technology
Chair of Communication and Computer Networks
pl. M. Skłodowskiej-Curie 5, 60-965 Poznań, Poland
e-mail: adam.kaliszan@put.poznan.pl
Abstract—This article proposes an application of a mini-
malistic Real Time Operating System (RTOS) for a construc-
tion of a device that works in the Internet of Things. The
solution described in the article is an effective and feasible
alternative to minicomputers with the Linux and Python
language interpreter. The application of RTOS reduces
significantly the required hardware resources, which results
in a decrease of the cost of the device and an increase in its
energy saving efficiency and reliability. The paper presents
the design of an access server that makes remote operation
of 16 serial ports possible and that controls 16 power lines
via the Ethernet. The device has been developed on the basis
of an 8-bit micro-controller equipped with 64 kB of external
memory for data and simple power-saving ethernet driver
without dedicated processor. Thanks to the application of
the operating system the software is composed of a number
of tasks running in parallel and being in close communication
with one another. With the approach that is compatible with
the philosophy of the Internet of Things, there is no need
to implement an advanced management panel on the device.
This functionality can be implemented in the cloud – on a
virtual server.
Keywords-Real Time Operating System; Routers; Embedded
Systems; Internet of Things, FreeRTOS.
I. I NTRODUCTION
The introduction of micro-controllers and processors
has resulted in a technological revolution comparable to
that of the replacement of vacuum tubes by transistors.
Thanks to the overall performance of processors it is easy
now to construct a controller that, not long ago, was to
be built from a combination of systems that were made
of single logic gates where logic gates could be combined
to make logic systems. What is more, controllers built in
the new technology are far more elastic in terms of their
reconfiguration. Until quite recently similar constructions
have been widely used in industrial and amateur systems.
This approach has made it possible to simplify the process
of design and construction of systems. Similar solutions
have been used in devices supporting the Software Defined
Networks (SDN) [1], [2] or Internet of Things (IoT) [3],
[4]. A great number of devices are based on a micro-
computer and operating system. However, from the point
of view of the capabilities of present-day devices, this
solution is not particularly effective due to its excessive
use, as compared to the actual needs, of computational
resources (processor and memory).
By studying the current trends of development, it can be
said that the approach towards construction of devices that
978-1-5090-2526-8/16/$31.00 ©2016 IEEE
Piotr Zwierzykowski
Poznan University of Technology
Chair of Communication and Computer Networks
pl. M. Skłodowskiej-Curie 5, 60-965 Poznań, Poland
e-mail: piotr.zwierzykowski@put.poznan.pl
operate in the Internet of Things will tend to change its
direction towards minimalistic solutions and will depart
from using complicated operating systems that demand
a large number of resources. A good example of this
approach is the home wireless router. Initially, a Linux
distribution system called OpenWRT [2], [5] was installed
on routers. This software was then replaced with another
one and, as a result, the router was equipped with the
amount of flash memory on the device that was twice
as lower. Other examples include personal computers. In
many households stationary computers became an insep-
arable element in our life, while their use was versatile
and universal. A noticeable decline in the interest in
stationary computers (the personal computer era) in favour
of mobile devices, i.e. tablets and smartphones, is clearly
evident. This tendency, called ubiquitous computing, is
well-grounded as low costs of electronic devices and
the decidedly higher comfort in their use, as opposed to
personal computers, are just plain to see [6].
The Internet of Things (IoT) as well as machine to
machine (M2M) solutions are even one step forward than
ubiquitous computing. In IoT all devices are connected in
a global network. Such an approach to telecommunications
is though complicated. In earlier solutions of the M2M
type, devices communicated with the help of their own
simplified protocols that, more often than not, were not
standardised. The use of network protocols in IoT requires
high outlays related to the implementation, which often
results in the frequent application of an operating system,
e.g. Linux, that has demands of a few orders higher than
the devices on which it has been implemented for M2M
solutions. Such a high system requirements (technical
specifications) often result from the demand for the least
amount of work with the implementation only and the
need for launching a product on the market as soon as
possible. This approach however, has a number of funda-
mental disadvantages, such as: high system requirements
(a large memory of the order of at least a gigabyte, CPU
ratio), a relatively high energy and cost requirements, as
well as potentially higher failure frequency. The situation
described above is a typical case of the phenomenon of
bloatware [7].
This article presents an application of a minimalistic
Real Time Operating System FreeRTOS in implementa-
tion of devices that work in the internet of things. An
application of an operating system makes it possible to
 2016 10th International Symposium on Communication Systems, Networks and Digital Signal Processing (CSNDSP)

run a number of tasks operating in the background, thanks

to which a programmer can be released and relieved from
handling a software by himself and from manual construc-
tion of packets which are to be transmitted throughout the
net. This approach is presented with the example of an
implementation of an access server in which a platform
and libraries to control and operate an intelligent home
environment are used [3], [4].
The remaining part of the article is structured as follows.
Chapter II provides a description of the hardware structure
of the access server. Chapter III presents the software
architecture operating on the server. Chapter IV proposes
a simple modification of this architecture that significantly
increases its efficacy without making any large changes in
the software necessary. Chapter V provides the conclu-
sions and summary.
II. H ARDWARE STRUCTURE OF THE ACCESS SERVER
In [8], the first version of an access server with imple-
mented ready-made ethernet module with its own proces-
sor is described. The application of such an ethernet–serial
port converter significantly simplified the implementation
of the software, but was also burdened with a number of
limitations. Some of the most important disadvantages of
this solution included:
• relatively high manufacturing costs,
• support only one connection with user console,
• limited maximum bandwidth to 230 kb/s,
• one serial port of the processor is required to com-
municate with ethenret module.
It is no surprising then that the use of a converter was
considered in the project to be only transitional from the
start. For the same reason, also in the software architecture
of the server a dedicated system to serve as an ethernet
controller was implemented.
In the papers [3], [4] a modification to the software
was presented. The main goal of this modification was to
make the application of the device to control an intelligent
home environment possible. The changes were mainly
based on the application of the system to FreeRTOS real
time and to implement control environment to provide
service to the network and ethernet controller. In addition,
a command interpreter was implemented, which made a
configuration of the device with the help of a console
possible. The changes in the software made modifications
to the device possible. The Ethernet to serial converter was
eliminated and the USB–serial port converter was added.
Thus modified hardware and software architecture was
then used to construct the server presented in the present
article.
The access server has a module structure. Three types
of modules can be distinguished: the main controller,
serial ports module and power control module. In addition,
the system is equipped with a power supply unit. The
structure of the server is shown in Figure 1. The main
controller is responsible for the communication with a
local network. The controller receives appropriate mas-
sages in IP packets), converts them and forwards them
Figure 1. Block diagram of the server
Figure 2. Main module
via SPI bus to modules with serial ports. From the SPI
perspective, the execution module performs the function
of a "master" device, whereas the modules with serial ports
perform the function of "slave" devices. SPI bus is used
for the communication between modules to communicate
between the systems in the main controller module. Each
of the serial modules consists of two serial card (two SPI
slave devices) and therefore is additionally connected with
two separate address lines to the main controller1 . The
modules that control 230V power are connected directly
to the serial modules.
Figure 2 presents the mail controller module. In the
main module, the enc28j60 system is used to service the
ethernet. This system communicates with the processor
via SPI bus. In the presented hardware architecture, the
modules with serial ports are coupled (attached) to the
same SPI bus. Chapter IV proposes the new architecture
in which a newer type of micro-controller equipped with a
large number of SPI buses is used. The module discussed
in this article includes the atmega128 micro-controller to
which 64 kB external memory is connected. Additionally,
the module has a SD card slot, a system to control rs485
serial bus and the ft232rl system to convert the serial port
to USB.
The module that services serial ports is composed of two
serial cards. Each of the serial cald has a micro-controllers
connected to SPI bus. Ech of the micro-controllers is
equipped with two serial ports, which effects in a single
module servicing four serial ports, while in the system it
is visible as 2 SPI devices and hence it uses only 2 address
line. Communication software for serial modules has been
1 In the figure, these connections are marked with dashed line
 2016 10th International Symposium on Communication Systems, Networks and Digital Signal Processing (CSNDSP)
Figure 3. The data reception process of data from the operator’s console
and the instance of sending them to a serial port
written in assembler and has not been modified from the
original. Only minor bugs have been remedied. A detailed
description of the serial port module and power supply
module is not provided in the article due to the fact that
these modules are not based on real time.
III. S OFTWARE
The operation of the access server is based on passing
on messages in both directions between the router console
ports and the user’s terminal. In addition, the access server
enables the power supply unit of a router to be switched
on or off. To receive messages from the user’s terminal
the following actions are to be executed:
• The main controller receives an UDP message that
has been sent from an application in the user’s
terminal. Then, this message is parsed and, via SPI
bus, sent to an appropriate serial card.
• Serial card sends the message to an appropriate port.
Figure 3 shows the process of the reception of messages
from the network and the transfer to an appropriate port
in the router. In the main controller this activity is divided
into three stages. Such a division enables a multitasking
implementation to be performed, since individual stages
can be executed in separate tasks that communicate with
each other via buffers. The buffers are depicted as ellipses
in Figure 3. The FreeRTOS provides appropriate mech-
anisms for buffer service, which significantly simplifies
their application.
During the first stage, the processor receives messages
from the enc28j60 controller via SPI bus and places them
in buffer UDP data RX.2 It should be noticed that the
implementation of this stage can be used in many other
projects, while a buffer can be treated as an equivalent
of a network socket. It is thanks to this approach that a
programmer can be responsible for creating a task that
2 These data are to be processed in the next sage only.
Figure 4. Format of the message sent between the access server and
the virtual console
receives network messages and places their content in a
buffer, but does not have to have the knowledge of the
functions and rules for their application. Multitasking of
an operating system makes it possible to run the execution
of this task in parallel with the execution of the remaining
tasks defined in the project’s code. It should be also
mentioned that even a replacement of a controller for
Ethernet service with another system requires only this
functionality to be rewritten and has no influence upon
the operation of the remaining parts of the software.
During the second stage, the messages stored in the
buffer UDP data RX are parsed. These messages are
written in the TLV format that starts with the sequence
denoting the beginning of a message and ends with a 16
bit correction sum. The format of the message is shown in
Figure 4. The meaning of particular fields in the message
is as follows:
• Sync - an 8-bit field that always includes a value equal
to 0xA5 and defines the beginning of a new message.
• Type - an 8-bit field that defines the number of a serial
port or a command that is responsible for power to
be switched on or off for a given router 3 .
• Lenght - an 8-bit field that determines the number of
bytes with data written in successive fields.
• CRC - two 8-bit fields that include the control sum.
As a result of an analysis of the message the data that
are to be sent to an appropriate serial port are derived. A
separate sending buffers Serial Card XA and Serial Card
XB are created for each serial port, where X denotes the
number of the serial card.
In the third, last, stage data stored in buffers Serial Card
XA and Serial Card XB are sent to the serial cards via SPI
bus. Because of the specific nature of the operation of
SPI bus, and also due to the fact that the card services
two serial ports, transmitted data have to include some
additional information 4 . For this purpose, the problem
resulting from the architecture of serial cards used in the
system had to be first solved. The AVR micro-controller
that is used in them does not provide a hardware buffer for
SPI, which means that it is necessary to read a byte sent
by SPI bus before the next byte of data arrives and appears
on the bus. When the data transfer rate is taken into
consideration, one can assume that the micro-computer
needs a total of 32 clock states to receive such a message.
This explains why the software written in assembler was
used to analyse the sent messages. The applied protocol
assumes that the 4 oldest bits in the transferred byte
3 Values from 0 to 15 define the port number, value 254 denotes power
to be switched off, whereas the value 255 to be switched on.
4 A solution to this problem could be an introduction of framing, but
then a transfer of one byte would involve a huge add-on resulting from
the need for maintaining the structure of a frame
 2016 10th International Symposium on Communication Systems, Networks and Digital Signal Processing (CSNDSP)
Figure 5. The process of data reception of data from the serial port and
of sending them to the console of the operator
will include control flags, while the successive 4 bits the
transferred data. Each byte constitutes then a full message
in which 4 bits of data can be transferred. It is worthwhile
to notice that sending a given number of bytes to a serial
port always requires sending a double number of bytes
via a SPI bus. The operation of the protocols assumes
that after a reception of a single byte from buffer Serial
Card XA and Serial Card XB it is converted into two bytes
and placed either in table SPI TX A data or table SPI TX B
data, depending on the buffer (see Figure 3). As a result,
the buffers include data ready to be sent off and to be
transferred via SPI bus. After the preparation of data, data
are sent via SPI bus. At the same time, reading of data
that are to be sent by the serial cards is performed. Thus
the third stage of data transfer from the console of the
operator to the router is related to the first stage of data
transfer from the router to the console of the operator,
which is shown in Figure 5.
Reception of data from the router and sending them to
the user’s terminal requires the following activities to be
executed:
• The serial card receives, via a serial port, a single
sign and forwards it via SPI bus as two bytes.
• The main controller reads the serial cards. When a
card sends the content of received signs, then the
signs are sent by the main controller to the console
of the operator.
The data sending algorithm to be applied for data transfer
via the main controller between the router and the oper-
ator’s console can also be divided into three stages that
are presented in Figure 5. In the first stage, the controller
receives data from the serial card. The same protocol as
the protocol for data sending is used for data reception
from the serial card, which means that each byte is sent
in two one-byte messages. Received data are stored either
in table Spi data RX A or table Spi dataRX B, depending on
the number 5 bit that determines whether relevant data are
related to either port A or port B. Then, the data stored in
the tables are parsed and consolidated. From two messages
that include 4 bits of data each 1 byte of data is created
and is then placed in the buffer Serial XA Rx or Serial XB
Rx, where X denotes the number of the serial card.
In the second stage, data stored in buffers Serial XA
RX and Serial XB RX are prepared for sending to the
console of the operator via the network. For this purpose,
a message with data that are taken from buffers Serial
XA RX and Serial XB RX is sent to buffer UDD TX. The
message is composed in the TLV format and it is shown
in Figure 4.
In the third stage, data stored in buffer UDD TX are
placed in a message that is then sent to the enc28j60
controller. Buffer UDD TX, similarly to buffer UDD RX,
is a counterpart (equivalent) to a network socket, whereas
the implementation of buffer service itself is independent
of the format of a message sent via the UDP protocol.
The stages described above can be run in parallel by
placing them in appropriate tasks. Figure 6 shows the
implementation of these stages and their placement in ap-
propriate tasks. The tasks are shown as rectangles in solid
line. The buffers (presented as ellipses) serve to commu-
nicate between tasks. The arrows denote the direction of
communication between tasks. The lines drawn in dashed
line serve to exchange messages between tasks to test
the correctness of the implementation. In the FreeRTOS
system, a task or the interrupt handling procedure can be
sent by data to the buffer. These procedures are presented
in the figure as rectangles in dashed line.
Task SPI TASK is responsible for providing service to
SPI bus. This task includes stage 1 and 3, i.e. receiving
and sending messages. This eliminates the necessity of
occupying and releasing the SPI bus. Chapter IV proposes
a division of this task for systems that have two SPI
buses. Separate tasks are created for servicing the second
stage. Thanks to this solution, changes only relate to the
communication protocol for communication between the
console of the operator. An application of a newer system
of the atxmega family will make it possible to employ
the DMA controller to service SPI bus, which will allow
parallelization of the execution of the task from the second
stage possible. The tasks can be then performed parallelly
to the SPI transmission without the necessity to put these
tasks on hold after every transmitted sign.
The multitasking operating system makes execution of
additional processing by the processor possible. The above
includes service to the configuration console of the access
server. Configuration of the access server is similar to that
of the router. In order to add this particular functionality
task CLI Task has been created. The task makes it also
possible to test implementations of particular stages. For
this purpose, appropriate commands to record and read
data from buffers Serial 1A RX, Serial 1A TX ..., Serial 8B
RX, Serial 8B TX have been added. Data recording to these
buffers triggers a simulated event that the operator of the
console or router has sent a message, thus triggering a test
 2016 10th International Symposium on Communication Systems, Networks and Digital Signal Processing (CSNDSP)
Figure 6. Relation between the RTOS tasks and stages in the process
of data forewarning
of the functionality of the third stage. Reading of messages
from these buffers makes testing of the functionality of the
first and third stage possible. The architecture proposed in
the present paper makes it possible to add in a simple way
a successive task with the command interpreter that will
use the network (instead of a serial port) to communicate
with the operator. To make it operative, an appropriate task
that would send data to buffer CPI RX and receive date
from buffer CPI RX has to be added.
IV. P ERFORMANCE IMPROVEMENT
The solution proposed in Chapter II is based on one SPI
bus, and therefore is limited by the throughput of one serial
peripheral interface (SPI) bus. It is then quite conceivable
that the performance and efficiency of the system can be
significantly improved by increasing the number of SPI
buses. A relevant solution based on the application of two
SPI buses is presented in Figure 7. In this solution one
SPI bus is responsible for servicing the enc28j60 system,
while the other for servicing the serial cards. Figure 7
shows a concept diagram of the controller discussed in
the article. However, it should be added that the addition
of the second SPI bus – with similar software architecture
– is well grounded only when the processor is clocked
with a faster clock and the operating system will mange to
switch processes that service SPI bus. It should be stressed
Figure 7. Modified main module
that in SPI bus management it is the DMA controller that
is very important. The DMA controller makes automation
of the process of placing successive data (retrieved from
the buffer) in the SPI registry possible.
The AVR atxmega processor satisfies all the requirements,
i.e. it can provide service to a number of SPI buses, can be
clocked with a faster clock and is equipped with the DMA
controller. It should be also stressed that the software
written for the older family of AVR atmega processors
can be easily adopted, i.e. without much additional work,
to any new hardware platform.The fact that the new
architecture with two SPI buses is taken into account in
the implementation makes the operating system easier and
facilitates the division of the algorithm into cooperating
tasks that are scheduled at run time. Figure 8 shows the
proposal of the implementation of the software in a system
with two SPI buses. The task responsible for servicing
SPI bus is then divided into two tasks. Each of these
tasks services a separate SPI bus. The appropriation of
SPI bus to exclusive tasks makes it possible to avoid
using semaphores and other mechanisms that synchronize
processes. After an introduction of these changes each of
the 3 stages in message communication is performed in a
different task.
V. C ONCLUSIONS
This article presents an example of the application of
a real time system for servicing devices that work in
the Internet of Things. An algorithm for servicing an
exemplary device is discussed. This algorithm is divided
into stages. Successive stages can be implemented in
separate tasks that communicate with one another. This
solution ensures high elasticity and the resulting ease
of being used in a great number of other projects. In
addition, the introduced division of functionality make
is possible to introduce parallellization of implementation
works, thus facilitating the acceleration of implementation
completion. The application of the command interpreter,
in turn, introduces additionally a possibility to test the
system that has not been yet fully implemented. It should
be stressed that activation of the device is accomplished
very quickly and does not exceed fractions of a second.
The functionality that is similar to the one discussed in
the article can be also achieved using a microcomputer
with 4 USB ports in which each port can accommodate
a quadruple serial port. A disadvantage to the above
solution, however, is hardware add-on (nearly a 1,000
times greater memory and 10 times faster clock). Another
drawback of this solution is the consumption of energy.
The tests show that the device consumes about 2.5 Watts
of power. It is equipped with a Graetz bridge and a voltage
converter, so it can be powered by AC voltage from 6 to
30V. Similar power is consumed by Raspberry Pi Model
B, but it requires a DC voltage of 5V. Therefore, an
analysis of the power consumption of a Raspbery Pi-based
device should take into account the power losses resulting
from the operation of the voltage converter. Moreover, the
connected Rs232 USB converters also consume additional
 2016 10th International Symposium on Communication Systems, Networks and Digital Signal Processing (CSNDSP)
Figure 8. Modified division of the algorithm into processes
power (about 1.6 Watts). Consequently – assuming that
a Raspberry Pi microcomputer is powered by a 90% –
efficiency converter – the proposed prototypical solution
consumes about 45% less energy than the Raspberry Pi
one.
The solution presented in the paper did not include any
efforts to design software reducing the power consumption
by the processor, such as disabling the resonator’s rail-to-
rail mode. Using the latest processor that does not require
an external crystal in the architecture described in IV
would enable a further reduction of energy consumption,
particularly when the entire system is supplied with a
3.3V voltage. A further possibility of limiting the power
consumption lies in replacing the Ethernet enc28j60 driver
circuit. The enc28j60 alone is responsible for 30% of
energy consumption in the described solution. The authors
expect that the solution presented in Section IV would
halve the power consumption as compared to the Rasp-
berry Pi-based system.
R EFERENCES
[1] A. Kaliszan, S. Hanczewski, M. Głabowski,
˛ M. Stasiak, and
P. Zwierzykowski, “Routing and control plane in the Parallel
Internet IPv6 QoS,” in Proceedings of 8th International
Symposium on Communication Systems, Networks & Digital
Signal Processing, Poznań, Poland, July 2012, pp. 1–5.
[2] A. Kaliszan and M. Głabowski,
˛ “A Didactic Platform for
Testing and Developing Routing Protocols,” in Proceedings
of 8th Advanced International Conference on Telecommuni-
cations, Stuttgart, Germany, IARIA, 2012, pp. 197–202.
[3] A. Kaliszan and M. Głabowski,
˛ “Didactic Embedded Plat-
form and Software Tools for Developing Real Time Op-
erating System,” in Proceedings of 7th Advanced Interna-
tional Conference on Telecommunications, St. Maarten, The
Netherlands Antilles, IARIA, 2011, pp. 77–82.
[4] A. Kaliszan and M. Głabowski,
˛ “A Didactic Platform for
Practical Study of Real Time Embedded Operating Systems,”
International Journal on Advances in Telecommunications,
vol. 4, no. 3, pp. 293–314, 2011.
[5] M. Chmielewski, P. Szyszkowski, and M. Piechowiak, “Ap-
plication of IP multicast in embedded systems with Open-
WRT,” in Proceedings of 8th International Symposium on
Communication Systems, Networks & Digital Signal Pro-
cessing, Poznań, Poland, July 2012, pp. 1–5.
[6] S. Poslad, Ubiquitous Computing: Smart Devices, Environ-
ments and Interactions, Wiley, 2009.
[7] Y. Jiang, C. Zhang, D. Wu, and P. Liu, “Feature-Based Soft-
ware Customization: Preliminary Analysis, Formalization,
and Methods,” in Proceedings of 17th International Sym-
posium on High Assurance Systems Engineering, Orlando,
Florida, USA, January 2016, pp. 122–131.
[8] A. Kaliszan and P. Zwierzykowski, “Remote access server
in the laboratory of computer networks,” in Proceeding of
the Poznan Telecommunications Workshop. Poznań, Poland,
Poznan University of Technology, December 2007, pp. 1–5.