At the lower levels it is still possible to select
modules to decide which specific storage device
is accessed (a hard drive, SD card, RAM drive,
etc). Thus, the lower level modules are more
specific for a particular peripheral while the
higher level modules are less hardware-specific
and can even be used in combination with
multiple peripheral devices. Peripherals (the
green stack items) are the lowest level modules.
They provide information for the higher layers
of the stack to access the peripherals. Informa-
tion such as the base address and interrupt as-
signment is stored in the peripherals. In most
situations, an application does not access the
peripherals directly, because the application
accesses them through the driver interface on
top of it.
Drivers (the yellow stack items) provide the
next level of abstraction. They provide low-
level access to specific hardware either via a
peripheral or via another driver. The difference
between a driver and a peripheral is well de-
fined. The peripheral only defines basic infor-
mation about the hardware but provides no
further functionality. This basic information
can be used by a driver which is placed on top
of the peripheral. Drivers are hardware specific
and so are the interfaces they offer. Hence, if
the application contains code that accesses a
driver API, it will be hardware dependent.
Drivers still operate at a low abstraction level,
and using a device at the driver level requires
knowledge of that particular driver interface.
Some drivers are available as library wrappers.
They only offer an initialization routine which
is called from an application in order to con-
figure pins, clocks and registers. After this ini-
tialization the peripheral driver libraries from
silicon vendors can be used.
Stack services (the blue stack items) are the
most abstract layers of functionality. Stack
services provide standardized, hardware-inde-
pendent access to devices. Stack services ensure
the portability of an application. For example,
if the application uses a generic TCP/IP service,
it remains the same if Ethernet is replaced
with PPP and serial. A portable TCP/IP appli-
cation works exactly the same, whether linked
to a UART or to an EMAC peripheral, since
the Software Platform handles the lower level
details. Some services are static and not meant
to be instantiated. They have no (direct) rela-
tionship with peripherals or other services
and facilitate common functionality like POSIX
multithreading, CMSIS, software timer or in-
terrupt management support. The software
services may also be added automatically if
they are required by other services.
It takes just a few steps to integrate the Software
Platform into an Eclipse-based Tasking ARM
Cortex tools project. First the Software Platform
document needs to be added to the project.
The required software services and device stacks
are appended using the ‘Add’ menu by enabling
the related checkbox. After a device stack has
been selected in the Software Platform docu-
ment the available stacks for the device can be
chosen using the Grow stack up or Grow stack
down option. Figure 3 shows the stack items
for the USART interface. Device stacks can be
configured by changing the options in the
Properties view. Figure 4, for example, shows
the configuration options of the Ethernet MAC
driver. After the Software Platform is configured,
all C files and header files which belong to the
devices used are added (copied) to the Eclipse
project. If device parameters are changed, the
project files can be updated by selecting the
Generate Code button. From within the source
code of the embedded project the Software
Platform functions are called like other C func-
tions. The assignment of the functions, their
parameters and also data structures used (if
applicable) are described in an online API help.
Figure 5 shows a list of the available functions
and structures for the HTTP configuration.
The Software Platform repository contains sev-
eral components especially interesting for cre-
ating IoT applications.
Since the whole Internet is based on TCP/IP
networks, a TCP/IP stack service seems a nec-
essary requirement to be able to communicate
over the Internet. The TCP/IP protocol can be
on top of an Ethernet layer but there is also
the possibility to communicate wirelessly (by
using a WiFi USB stick) or over a serial con-
nection using the Point-to-Point Protocol
(PPP). This could be a serial cable but also a
modem connection, a GSM data connection
or even a GPRS connection. On top of the
TCP/IP stack the HTTP stack service can be
added which, in IoT context, is frequently
used for Representational State Transfer (REST).
Another benefit of the HTTP service is the
ability to support HTTP Secure (HTTPS). Se-
cure communication is important when the
application handles sensitive information. It
provides encrypted communication to prevent
eavesdropping and secure identification of a
network web server to know which web server
it is really talking to. Some open APIs, like the
latest Twitter API, do not even accept non-se-
cure communication anymore.
Representation of the data is also important.
Both sides should know how to interpret the
data. Although for this purpose XML is used
frequently, it is probably not the most appro-
priate choice for embedded devices. For small
devices it is often better to use the JavaScript
Object Notation (JSON) format to send data
in a structured way. The repository contains a
streaming JSON API (SAX-style) which is very
useful to parse complex JSON structures with-
out claiming much memory.
June 2014
34
I
NTERNET
-
OF
-T
HINGS
Altium: automotive safety support program for ISO 26262 certification
Altium announces the immediate availability of their TASKING ISO 26262 Support Program, an offering that assists TASKING compiler users
within the automotive industry with ISO 26262 certification. Embedded software forms a critical path in systems such as Driver Assistance,
Propulsion, In-Vehicle Dynamics, and Active and Passive Safety Devices. To mitigate the compounding safety risks associated with these embedded
systems, the ISO 26262 standard provides guidance along with requirements and processes for testing and certifying automotive embedded
software and development tools for safety.
Product News
Figure 5. HTTP functions
