Real Time Communication PlatformUsing ARM Cortex M7 and MQTT

Kommunikationsplattform med realtidsstöd Baserad på ARM Cortex M7 och MQTT

Robert Kyrk Karl Lindblom

Faculty: Faculty of health, science and technology

Subject: Computer science

Points: 15 Hp

Supervisor: Katarina Asplund

Examinating teacher: Tobias Pulls

Date: 2018-06-04

Abstract

Microcontroller platforms are heavily used in embedded solutions adopted in nearly ev-

ery industry covering a wide range of applications and use cases. In the paper and pulp

industry the change prompted by the rising popularity of data decentralisation, big data

analysis and machine learning, forces companies to upgrade or renew old platforms used to

collect and analyse data. This thesis will evaluate a generation change for a communication

platform that collects data from a sensor, its capabilities regarding secure communication

over TCP/IP with the possibility to implement an efficient machine-to-machine commu-

nication protocol. The main focus of the evaluation is development, implementation and

integration of software for the embedded system with a real time operating system using

the ARM Cortex M7. Using small open source tools and the powerful ARM core we were

able to build a small, flexible, real time system that publishes sensor data over MQTT

securely using TCP/IP and TLS.

i

Contents

1 Introduction 1

1.1 Project Goal and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Project Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Main Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Dissertation Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Background 4

2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Atmel SAMV71 Xplained Ultra . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 Microcontrollers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3.1 Atmel ATSAMV71Q21 . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3.2 Cortex M Processors . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4 Operating System and Scheduling . . . . . . . . . . . . . . . . . . . . . . . 7

2.4.1 FreeRTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.4.2 Tasks and Scheduling in FreeRTOS . . . . . . . . . . . . . . . . . . 9

2.4.3 FreeRTOS+TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4.4 Alternatives to FreeRTOS+TCP . . . . . . . . . . . . . . . . . . . 12

2.5 Atmel Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.5.1 Atmel Software Framework - ASF . . . . . . . . . . . . . . . . . . . 14

2.6 Programming Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.7 Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.8 Analog Front-End Controller - AFEC . . . . . . . . . . . . . . . . . . . . . 15

2.9 Transport Layer Security - TLS . . . . . . . . . . . . . . . . . . . . . . . . 16

2.9.1 WolfSSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.10 Message Queuing Telemetry Transport - MQTT . . . . . . . . . . . . . . . 17

2.10.1 WolfMQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

ii

2.10.2 Mosquitto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Project Design 20

3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 Hardware Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.1 Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3 Software Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3.1 Real Time Operating System . . . . . . . . . . . . . . . . . . . . . 23

3.3.2 TCP/IP Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3.3 Secure Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3.4 MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4 Project Implementation 25

4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2 Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2.1 FreeRTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.3 Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3.1 FreeRTOS+TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.4 Phase 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.4.1 WolfSSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.4.2 WolfMQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.5 Phase 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.5.1 WolfSSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.5.2 Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.5.3 Website . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5 Results 40

5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.2 Main Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

iii

5.2.1 FreeRTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.2.2 TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.2.3 TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.2.4 Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.2.5 MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.3 Implementation Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.4 Project Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.5 Problems and Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.6 Limitations of this Project . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6 Conclusion 45

6.1 Future Work of this Project . . . . . . . . . . . . . . . . . . . . . . . . . . 45

References 46

iv

List of Figures

1.1 System Overview and MQTT Traffic Flow . . . . . . . . . . . . . . . . . . 2

2.1 Atmel SAMV71 Xplained Ultra. Fair use for Educational Usage . . . . . . 5

2.2 Overview of the Cortex M7 Features . . . . . . . . . . . . . . . . . . . . . 7

2.3 FreeRTOS Task States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4 Atmel Embedded Debugger Terminal Example . . . . . . . . . . . . . . . . 13

2.5 MQTT Traffic Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1 Schematic Overview of the Setup . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Picture Overview of the Setup . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3 Software Overview of the System . . . . . . . . . . . . . . . . . . . . . . . 22

4.1 Task Monitor Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2 SAMV71 Schematics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3 ADC Schematics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.4 Website Showing Data From the Sensor . . . . . . . . . . . . . . . . . . . . 39

v

List of Code

1 Create Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Check if Task was Created . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Enable AFEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Creation of the LED Task . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5 The LED Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6 The Task Monitor Function . . . . . . . . . . . . . . . . . . . . . . . . . . 26

7 Enumerated List of GMAC Queues . . . . . . . . . . . . . . . . . . . . . . 29

8 WolfSSL Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

9 MQTT Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

10 MQTT Publish . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

11 Sensor Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

vi

1 Introduction

1.1 Project Goal and Motivation

For industries like the paper and pulp industry, a move towards industry 4.01 with its

strong emphasis on decentralisation, digitalisation and cloud based services could reap big

rewards. The industry today is burdened with atomic digital systems requiring personnel

to physically be located at a station to read its data, stations that are many and spread out

over large areas due to the big scale of the paper and pulp industry complexes. Digitalisa-

tion also motivates the use of big data for data analytics and better machine-to-machine

communications for automatic or adaptive system like robotics. Digitalisation and the

move to cloud-like platforms does, however, greatly aggravate the security risk of a system

and secure communication solutions such as TLS (see Section 2.9) has to be implemented.

As a step in this direction we have been tasked by Altran and one of their customers to

develop a proof of concept for a Communication platform (CPM) that can have its data

read by external agents. While doing this, the new platform, an open source real time op-

erating system and communication security has been evaluated. The customer also wants

to know if the open source software provided by the operating system and other libraries

such as the IP stack and the ethernet drivers are of good enough quality to ensure fast and

easy implementation making it valid as an option over non open source software. Altran

supplied the hardware, a microcontroller evaluation board featuring a ARM Cortex M7

core (see Section 2.2) and BTG Instruments AB (BTG) supplied a sensor and the current

version of the CPM that can be used as a reference system.

1The term ”Industry 4.0”[4] is used to describe new technological advancements and their potentialbenefit and competitive advantage for industrial companies. Key technologies are: artificial intelligence,Internet of Things, machine learning, cloud systems, cybersecurity and adaptive robotics

1

1.2 Project Summary

This dissertation will evaluate a platform change for the current communication platform,

its capabilities regarding communication over TCP/IP with the possibility to implement

MQTT (see Section 2.10) services for FreeRTOS (see Section 2.4.1). Microcontroller (see

Section 2.3) platforms are heavily used in embedded solutions adopted in nearly every

industry covering a wide range of applications and use cases. The system is constructed

by running a real time operating system on a Cortex M7 core and with that RTOS start

an MQTT client. The client will publish data to a broker that other clients can subscribe

to (see Figure 1.1).

Figure 1.1: System overview and MQTT traffic flow.

1.3 Main Results

We were able to start tasks using FreeRTOS and assign an IP address to the board with

FreeRTOS+TCP. With FreeRTOS and FreeRTOS+TCP (see Section 2.4.3) working the

ability to communicate with the outside world existed for the system. The system also got

a functional MQTT client for publishing data. With WolfSSL (see Section 2.9.1) working

the MQTT client also had the functionality of establishing a secure connection to the

2

broker and send encrypted MQTT messages. With these four components working in the

system, the goal of the project was partly fulfilled as REST had to be cut due to loss of

time.

1.4 Dissertation Layout

The dissertation starts with chapter one outlining our motivations and goals with the

project. Chapter two contains information about different tools and technical concepts

that the reader needs to understand in order to understand the project. Chapter three

describes how our software design choices are motivated and explains each part and its

purpose. Chapter four describes the implementation of the project by dividing the work

into phases and describing each of them in detail. Chapter five describes the results of the

project and problems faced in the project. It also contains an evaluation of the results and

the problems. The last chapter, chapter six, describes our take on the project and what

we have learned while working with this project. It also contains the possible features that

can be implemented in the future.

3

2 Background

This chapter contains necessary information in order to understand all the different tools

and concepts used in this project. The chapter explains what a microcontroller is, what

board model is used, how ARM designs its processors and the chapter also outlines basic

behavior of operating software and describes how the real time operating system works in

detail. The chapter continues with information about the development environment, TLS,

MQTT, analog to digital conversion and the sensor.

2.1 Overview

Building a platform for sending data made for the industry creates some problems to

overcome. The restrictions and variables of the real world are not lab-like, the hardware

may for example be abused by environmental factors like vibrations, dust or damp air.

Making a system robust includes taking some of these aspects into consideration during

component selection. The protocols and software used are all tested and considered stable.

No hard drives or SD-cards were used to avoid accidents and increase stability, and as such

no file system was present. The absence of a file system made restrictions on the choice of

software and implementation. This mostly affected communications where certificates were

necessary but also choosing our libraries and presented an interesting challenge. Chapter

3 and 4 will go further into our challenges and solutions.

2.2 Atmel SAMV71 Xplained Ultra

SAMV71 Xplained Ultra[15] is a hardware platform using the Atmel ATSAMV71Q21 (see

Section 2.3.1). The hardware platform is specially designed to evaluate the Atmel micro-

controller and is outfitted with all the peripheral connections to allow full functionality of

the microcontroller’s features. Other than the microcontroller there is also two LEDs, two

buttons and an external power input on the card. (see Figure 2.1). The Communication

4

Port (COM) on the SAMV71 together with the data visualizer (see Section 2.5) made it

possible to debug the code.

Figure 2.1: Atmel SAMV71 Xplained Ultra. Fair use for educational usage [15].

5

2.3 Microcontrollers

Microcontrollers[11] can be seen as small computers on a single chip. A microcontroller

contains a CPU, memory and programmable I/O. Program memory comes in several forms

such as RAM, ROM or Flash , which are all different techniques for arranging and managing

memory cells. Microcontrollers are often used in embedded systems where resources are

sparse and real time requirements are critical such as in the automotive, space and defense

sectors where some systems are very critical. Microcontrollers are also used in household

systems such as washing machines, entertainment systems or remote controls. A typical

home in a developed country may have around four general-purpose microprocessors but

around three dozen microcontrollers and a typical automobile may have as many as 30

microcontrollers.

2.3.1 Atmel ATSAMV71Q21

The microcontroller on the Atmel SAMV71 Xplained Ultra is Atmels ATSAMV71Q21[19].

The core is a 32-bit ARM Cortex M7 running up to 300 MHz and 2048 KB embedded

flash memory for program storage. The core also features Double Precision Floating Point

Unit (FPU)2 and supports up to 114 I/O lines. This core is commonly used in automotive

system like infotainment or telemetric systems due to its high performance and connectivity

interfaces.

2.3.2 Cortex M Processors

Cortex M[21] is a series of ARM processors for microcontrollers. ARM processors have two

types of instruction sets, 32-bit ARM instructions and thumb instructions. The Cortex M

only supports thumb instructions. Thumb 1 instructions are a 16-bit encoded subset of

ARM instructions. The M7 also supports thumb 2 which is a subset of 32-bit instructions of

the ARM instructions. The difference between ARM instructions and thumb instructions

2A co-processor designed to carry out operations on floating point numbers.

6

is how they are encoded and decoded by the CPU. Cortex M7[13] can handle regular

arithmetics with signed/unsigned integers and with floating point numbers if it has a

Floating Point Unit (FPU). Cortex M7 can also handle saturation arithmetics, which

means the result from a calculation can not go lower than a minimum value or higher than

a maximum value. The ARM Cortex M7 core has many modules you can use to design

your system. For example a module for protecting memory and modules for adding more

memory like a cache or a tightly coupled memory (TCM) (see Figure 2.2).

Figure 2.2: Overview of the Cortex M7 features [2].

2.4 Operating System and Scheduling

Operating systems appear to allow multiple processes to execute at the same time. In

reality, each processor core can only run a single process at any given time. The CPU

scheduler decides which process to run and provides the illusion of simultaneous execution

by rapidly switching between the processes. The CPU scheduler in a RTOS is designed

to provide a deterministic execution pattern, which means the system must respond to

7

an event within a strictly defined time. The system either uses hard- or soft deadlines

depending on how critical the response time is in the real world (harder meaning faster,

more critical). Should two processes collide the process with the highest priority will

execute. Priorities are very important in real time scheduling to make sure that important

tasks are not missed. A deterministic execution pattern is of great interest to embedded

systems as they have real time requirements, e.g. reading sensor values or making exact

placement of robot arms in a car assembly factory.

2.4.1 FreeRTOS

FreeRTOS[17] is a free real time operating system kernel that is small enough to use on an

embedded system such as a microcontroller, but still powerful enough not to be limited to

just microcontrollers. It was first developed in 2003 by Richard Barry and maintained by

Real Time Engineers Ltd. In 2017 stewardship of the project was passed to Amazon Web

Services (AWS). During 2017 a copy of the operating system was downloaded every three

minutes.

FreeRTOS is designed to run on small embedded systems with a typical kernel size of

6-12KB. The scheduler in FreeRTOS achieves determinism by allowing the user to assign

a priority to each thread. The scheduler then uses the priority to know which thread of

execution to run next. The operating system never runs a non-deterministic operation.

The priorities in FreeRTOS are assigned by descending order, i.e. the lowest numbers have

the highest priority. For example, a thread with priority 3 is granted CPU time before a

thread with priority 5.

The operating system supports many usages and can as such run the very minimalistic

kernel of only three files to very complex systems running multiple libraries and with

support for many protocols and applications.

8

2.4.2 Tasks and Scheduling in FreeRTOS

Starting a task3 in FreeRTOS is simple, only one command is needed, xCreateTask. Each

task is automatically allocated RAM from the FreeRTOS heap. Parameters used to con-

figure the task are the following.

• pvTaskCode - A pointer to the task entry function.

• pcName - Description of the task, used for debugging.

• usStackDepth - The number of words (note that this is not specified in bytes!) to

allocate for the stack of the task.

• pvParamters - Value passed into the created task. If this is a variable it must be

declared and allocated in memory and exist when the task executes.

• uxPriority - Task priority by which it is compared to other tasks by the scheduler.

• pxCreatefTask - Used to pass a handle to the created task. This parameter is

optional and can be set to NULL.

An example of a task created in FreeRTOS using xTaskCreate() can be found in Listing

1.

Listing 1: Create Task

1 xTaskCreate(

2 vTaskCode , /* Function that implements the task. */

3 "NAME", /* Text name for the task. */

4 STACK_SIZE , /* Stack size in words , not bytes. */

5 ( void * ) 1, /* Parameter passed into the task. */

3The word ”task” is mostly used in the context of scheduling, were it can refer to either a thread or aprocess.

9

6 tskIDLE_PRIORITY ,/* Priority at which the task is created.

*/

7 &xHandle /* Used to pass out the created task’s

handle. */

8 );

xTaskCreate returns pdPass if successful or a memory-related error if not. To check if

a task was created the method call can be assigned to a variable and checked after creating

i.e:

Listing 2: Check if Task was Created

1 if( xReturned == pdPASS )

2 {

3 //do something here

4 }

Tasks in FreeRTOS can have four different states. The different states and how to set

tasks into these states can be found in Figure 2.3.

• Running - A task that is executing is in the running state.

• Ready - Tasks that are ready to execute are in the ready state.

• Blocked - Task waiting for external or temporal(Intentional by task delay command

or otherwise) states are blocked. Tasks in blocked state normally have a timeout

period.

• Suspended - Almost the same as blocked but with no timeout defined. The task

needs to be explicitly commanded to enter or leave this state.

10

Figure 2.3: Different task states in FreeRTOS [3].

2.4.3 FreeRTOS+TCP

The TCP/IP implementation developed by FreeRTOS uses Berkeley sockets and is thread

safe. Since it is developed by FreeRTOS it has the same programming style as FreeRTOS,

using the same variable names and commenting style. FreeRTOS+TCP[18] is easy to

configure with a well documented configuration file (FreeRTOSIPConfig.h) where settings

such as static ip or DHCP can be set. Depending on what features are enabled the size of the

implementation ranges from 20-35KB (depending on compiler optimization). Supported

features include:

• Berkeley sockets API

• Optionally supports TCP sliding windows

• Fully re-entrant and thread safe API

• Includes ARP, DHCP, DNS

11

• Static, DHCP and Auto-IP address assignment

• Can also be used as a UDP only stack

• Optional callback interface

• Optionally fragment outgoing packets

Features used are defined or tuned in the configuration file.

2.4.4 Alternatives to FreeRTOS+TCP

lwIP (Light Weight TCP/IP) is a popular alternative to FreeRTOS+TCP and is used

as default for many libraries such as WolfSSL (see Section 2.9.1). lwIP focuses on small

embedded system with restricted resources such as RAM and ROM.

2.5 Atmel Studio

Atmel Studio[1] is an integrated development platform for developing and debugging appli-

cations for Atmel microcontrollers. Atmel Studio is built using a Microsoft Visual Studio

shell and as such looks familiar to Visual Studio. It does, however, lack many functions

found in Visual Studio, like IntelliSense4. Atmel Studio supports programming in C/C++

or Assembler. The studio includes several libraries, drivers and code examples. Atmel

studio also includes an advanced software framework for touch and graphic functional-

ity. Debugging embedded software is very complicated and a great tool provided with the

software is the Data Visualizer, which is a program used to visualize data received from

various sources such as COM ports or embedded debugger ports during run time. Most

embedded systems run real time operating systems without any terminal interface and the

Data Visualizer can be one of few tools available to the developers. The tool provides sev-

eral options for monitoring and debugging a project such as serial port connection, Data

4IntelliSense is a tool in Visual studio that provides parameter info, quick info and complete words. Itkeeps track of parameters and functions while typing.

12

Gateway Interface(DGI)5, Oscilloscope6 and power monitoring. When connecting to the

board over the serial port an option to open a terminal exists and the terminal can be

used to, for example, read from standard out, this also enables debugging via standard out

prints from the software. (see Figure 2.4)

Figure 2.4: Atmel Embedded Debugger Terminal example

In Figure 2.4 the terminal is used to connect to the embedded debugger. Atmel Studio

also has debugging tools to view memory and I/O events during run time. Atmel Studio

comes preinstalled with Visual Assist (VAssistX), a tool with multiple uses ranging from

refactoring to finding references in the code or help with debugging. Further extensions can

be downloaded through Atmel Studio Gallery, e.g. tools, embedded software or plugins to

extend the development environment. Atmel Studio is also compatible with many Microsoft

5The Data Gateway Interface is a USB interface for handling the transport of data to and from a targetMicrocontroller.

6Oscilloscopes are used to observe the change in voltage over time, this is represented as a graph andused for debugging and monitoring hardware.

13

Visual Studio plugins.

2.5.1 Atmel Software Framework - ASF

The Atmel Software Framework is a software package that contains Atmel specific configu-

ration files, drivers and Atmel Studio related files. The framework also contains imported,

third party, libraries like FreeRTOS and WolfSSL. ASF includes a wizard where you can

select what board you are using and then list different modules that can be included into

the project. This functionality makes it very easy to include different modules that Atmel

studio offers. With the wizard you can include the modules with a simple button click that

will include the selected module into the project.

2.6 Programming Languages

The main language used in microcontroller programming is ANSI-C. Besides ANSI-C,

Atmel Studio uses Assembler for a few files. Atmel Studio also generates a few different

files in the output, such as binaries (BIN), Executable Linkable Format (ELF) and Hex-

files7. ANSI-C is the main programming language used in this project. The GNU C

Compiler (GCC) is set to work with the standard C99.

2.7 Sensor

BTG uses the sensor to measure consistency of pulp while it’s moving through pipes be-

tween stations in an industrial complex. BTG provided us with a sensor and a control

unit from the current generation CPM. The sensor measures consistency of paper fiber in

the pulp. To calculate this you need to be in a lab and weigh the pulp and then remove

all the water and weigh the pulp again. The sensor measures the pulp consistency in real

time and returns a value in percentage without the need of a lab environment.

7Used to transfer machine language code to the microcontroller.

14

2.8 Analog Front-End Controller - AFEC

AFEC[20] is a set of analog signal circuitry that uses integrated circuits for sensors, radio

receivers, and other circuits to provide a configurable and flexible way to interface with a

microcontroller. The AFEC driver on the Atmel SAMV71 Xplained Ultra[14] uses 12-bit

resolution, has a clock frequency of 6MHz and is activated in five steps. An example of the

initialisation of the interface can be found below. The interface is used by first enabling

the AFEC module by calling the method in Listing 3, row 1 where AFEC0 is the channel

where the results of the conversion is stored.

Next step is to configure the AFEC using a simple default configuration, which is

preconfigured by Atmel, using the function in Listing 3, row 2.

Initialization of the module can now be done as it is both enabled and configured by

using the function in Listing 3, row 3.

Now the trigger can be set as shown in Listing 3, row 4, which is activated in this case

by a software interrupt, i.e when the function is called a value is returned.

Now everything is in place and the channel from which the values will be polled can

be enabled as shown in Listing 3, row 5. Channel 5 here is internally routed to one of the

eleven analog PIN available on the SAMV71 Xplained Ultra. (see Section 2.2).

Listing 3: Enable AFEC

1 afec_enable(AFEC0)

2 afec_get_config_defaults (& afec_cfg)

3 afec_init(AFEC0 , &afec_cfg)

4 afec_set_trigger(AFEC0 ,AFEC_TRIG_SW)

5 afec_channel_enable(AFEC0 , AFEC_CHANNEL_5)

15

2.9 Transport Layer Security - TLS

TLS[10] is a protocol for secure communication over a network and are widely used in

different applications such as web browsers and servers. By using symmetric cryptography,

TLS provides a secure connection between sender and receiver. Symmetric cryptography

uses one secret key to encrypt the data that is being transmitted between the sender

and receiver and the key is generated between the parts by using for example elliptic

curve Diffie Hellman[22] which is an asymmetric key exchange algorithm. This is done in

the TLS handshake where they exchange a calculated value with each other to create a

shared secret key. In the handshake they also agree on what cryptography algorithm and

what keys to use for the encryption between the sender and receiver. With asymmetric

cryptography, public key encryption, the client can use a public key to authenticate the

server to ensure that they are communicating with the correct server. Usually the server is

the one with a key pair in order to authenticate that the server is the owner of the public

key. To authenticate itself the server can use certificates, which are issued from certificate

authoritys (CA). A certificate authority is an entity that offers certificates for servers and

providing security by acting as a trusted third party, promising that the server is authentic.

With the certificates the CA ensures that the server is the owner of the public key. The

client can then use the public key to check if the server is authentic.

2.9.1 WolfSSL

WolfSSL[12] is a TLS library written in C. WolfSSL is used by many big companies and

softwares like MySQL and Ubuntu for their SSL implementation. WolfSSL is a small sized

library for enabling secure communication in an embedded system.

16

2.10 Message Queuing Telemetry Transport - MQTT

MQTT[6] is a protocol for publishing and subscribing to messages. The protocol works over

the TCP/IP protocols and it is very useful in places where there is a limit on memory space

and bandwidth. MQTT consists of publishers and subscribers. The publishers categorize

their messages into topics and the subscribers subscribe to interesting topics and only

receives messages from those topics. For this to work there needs to exist a message broker

which routes the messages depending on the topic the messages have. When a client wants

to connect to a broker, the clients starts with performing a TCP handshake and when that

is done the client sends an MQTT connect message. If the MQTT connect is correctly

done the broker responds with an MQTT connect ack and after this the client has a MQTT

connection with the broker. When the MQTT connection is completed the client can send

MQTT publish packets whenever the client wants to. The publish packet can have certain

settings on it such as quality of service (QoS). The package has three possible QoS:

• Qos 0 - When QoS 0 is set it means that the client does not want an ack back from

the publish packages.

• QoS 1 - When QoS 1 is set the client expects an ack back letting the client know that

the publish packet was received and if not the package will be resent from the client.

• QoS 2 - When the client is using QoS 2 it will make sure that the message is only

sent once and when the broker is receiving the publish packet it will respond with

publish received (pubrec). When the client receives the pubrec it will send publish

release (pubrel), telling the broker that the publish was completed and the broker will

then respond with publish complete (pubcomp). This will make sure the message is

received and only sent once.

Figure 2.5 demonstrates how the MQTT protocol works with publishers and subscribers.

On the left side there is an MQTT client with a temperature sensor which publishes the

17

data under some topic to the broker illustrated in the middle. On the right side there is

another client that wants to subscribe to these temperature values from the sensor client.

It tells the broker that it wants all messages that the broker receives under a certain topic

that the left client is using when publishing. The broker then sends these values to the

client on the right side.

Figure 2.5: MQTT traffic flow with publish and subscribe example [7].

2.10.1 WolfMQTT

WolfMQTT[23] is an MQTT library written in C for embedded use. WolfMQTT offers

methods for creating MQTT clients with abilities to both publish and subscribe to MQTT

data. It has support for all the necessary settings for MQTT such as encrypted connections

with TLS and QoS levels.

18

2.10.2 Mosquitto

Mosquitto[5] is an open source MQTT Broker responsible for receiving messages from

MQTT clients, filtering the messages and sending them to clients who are subscribers to

the message topic.

19

3 Project Design

This chapter outlines and explain various design aspects of the project, the explanations

also contain a brief summary of the objects involved. The chapter includes both hardware

design and software design. Section 3.2 provides an overview of the hardware setup. Section

3.3 contains details of what the different software components looks like and what settings

the software components are using in order to be integrated with each other.

3.1 Overview

The project is designed to be simple and with low complexity using as few tools as possi-

ble to reach the goals. Simplicity and low complexity also have the benefit of having low

resource requirements, low code quantity, memory usage and power consumption. FreeR-

TOS has a restrictive resource usage and integrates well with libraries that are used in the

project, such as WolfSSL. FreeRTOS will manage all the scheduling and priorities allowing

the imported libraries to focus on their specific task. With an MQTT client setup on the

microcontroller to publish data to a broker, the MQTT broker will make the data available

for other devices or machines interested in this data.

3.2 Hardware Design

The following section will describe the hardware setup used in the project. It will give an

idea of what the hardware design looks like in a schematic view and in a picture. Figure

3.1 is a simplified view of the hardware design. Figure 3.2 is a picture of the hardware

setup, showing how the different hardware components are connected to each other. It

shows that the sensor is connected to the CPM and the board is connected to the CPM.

20

Figure 3.1: Schematic overview of the setup.

Figure 3.2: Picture overview of the system.

21

3.2.1 Sensor

A sensor from BTG was connected to the board’s analog input pin to generate values to

publish from the board to the MQTT broker.

3.3 Software Design

The following sections will explain the design purpose of each part of the system that can

be seen in Figure 3.3.

Figure 3.3: Software overview of the system.

22

3.3.1 Real Time Operating System

The real time operating system controls the scheduling and sets priorities of tasks. Config-

urations of FreeRTOS can be done in the FreeRTOSConfig.h file. Design choices were made

to minimize memory usage by turning off features that were not needed to make room for

larger heap allocation for the MQTT task. Trace functions that allow logical analysis of

running tasks are used during development but turned off before release. Tickless idle, a

feature that enables the embedded device to enter a low power mode, which reduces power

consumptions during idle, is turned off as the device was designed to continuously send

data from the sensor and would not be idle enough to benefit from the feature.

3.3.2 TCP/IP Stack

The TCP/IP stack is designed to be of low complexity and robust with as many unnecessary

features turned off as possible. Interesting features in a software design aspect is DHCP and

AUTO IP. DHCP was enabled to allow easy setup on different networks during development

and was left enabled at release for the same reasons. Auto IP that allows the system to

set a static IP address if the DHCP fails was also enabled.

3.3.3 Secure Connection

WolfSSL is a library that enables TLS connections over a socket. One upside to using

this library is that there is documentation available to help with the integration with

FreeRTOS. A requirement of the program was that the data to and from the system should

be encrypted with TLS since the values sent from the sensor contains sensitive information

about the pulp. Because of this the system needed to have a TLS library that would work

with the RTOS. The development environment used is made for C or C++ programming

so it was necessary that the TLS library was written in C as well. Another aspect that was

important when choosing the TLS library was how much memory that library requires,

since the system has a low amount of memory.

23

3.3.4 MQTT

The choice of what protocol to use for sending the data to other clients was based on a

few requirements. MQTT was used because it offers an easy way to send many packets

over one TCP connection. After both the TCP handshake and the MQTT handshake, a

connection is established and the client can begin to send MQTT packages containing, for

example, sensor data. This was important when displaying sensor data in real time and

with MQTT this was easy to accomplish. For this implementation the client will publish

sensor data. WolfMQTT is also developed by WolfSSL which made it easier to implement

TLS over the MQTT connection. The importance of the MQTT client being developed in

C was also a contributory factor to be able to integrate it with the project.

24

4 Project Implementation

This chapter describes the implementation of the different software modules and how each

library has been modified to enable integration between them and the hardware. The

chapter is divided into four phases and each phase contains the implementation of the fea-

ture and problems with it. The first phase contains the implementation of FreeRTOS. The

second phase describes the implementation of TCP and the third phase contains the im-

plementation of TLS and MQTT. The fourth phase contains the complete implementation

of TLS, the implementation of the sensor and the implementation of the website.

4.1 Overview

The project was implemented in four phases where each phase had one of the four technical

cornerstones as focus. The first phase describes the setup of the operating system and

the hardware, making sure that the system booted and that there were no faults with the

hardware. In the second phase TCP/IP was implemented to connect over the network. The

third phase of the project was the longest, and the work load was split up. In this phase the

main focus was on getting MQTT completed and to start with the TLS implementation.

In the fourth phase we connected the sensor and continued with the implementation of

TLS.

4.2 Phase 1

This phase describes the implementation of FreeRTOS and what must be done to get

FreeRTOS to work.

4.2.1 FreeRTOS

The project is built upon FreeRTOS. Included in Atmel Studio there is an example project

that was used as a starting point for the project with the modification that FreeRTOS was

25

updated to the latest version. The example in Atmel Studio used FreeRTOS to handle a

task that lights up two LED:s (see Listing 4 and 5). The example is a good place to start

as it has a way to print different things for debugging the program and the example has a

structure that could be followed for further implementation of the project.

Listing 4: Creation of the LED Task

1 /* Create task to make led blink */

2 if (xTaskCreate( task_led ,

3 "Led",

4 TASK_LED_STACK_SIZE ,

5 NULL ,

6 TASK_LED_STACK_PRIORITY ,

7 NULL)

8 != pdPASS) {

9 FreeRTOS_debug_printf (("Failed to create test led task\r\n"));

10 }

Listing 5: The LED Function

1 static void task_led(void *pvParameters)

2 {

3 UNUSED(pvParameters);

4 for (;;) {

5 LED_Toggle(LED0);

6 vTaskDelay (1000);

7 LED_Toggle(LED1);

8 }

9 }

Furthermore, a task monitor was implemented (see Listing 6) that prints a snapshot of

the current tasks run by the scheduler and their priorities.

26

Listing 6: The Task Monitor Function

1 /**

2 * This task , when activated , reports free heap and

3 * total tasks status once every second

4 */

5

6 static void task_monitor(void *pvParameters)

7 {

8 static portCHAR szList [256];

9 UNUSED(pvParameters);

10

11 for (;;) {

12 // check to see how much free heap memory

13 size_t freeheapsize;

14 freeheapsize = xPortGetFreeHeapSize ();

15 FreeRTOS_debug_printf(

16 ("--- task ## %u ---",

17 (unsigned int)uxTaskGetNumberOfTasks ())

18 );

19 FreeRTOS_debug_printf (("\n"));

20 vTaskList (( signed portCHAR *) szList);

21 FreeRTOS_debug_printf (( szList));

22 vTaskDelay (1000);

23 }

24 }

27

Figure 4.1: Task monitor showing information about tasks in the system.

The task monitor contains five columns (see Figure 4.1). The first column contains the

name of the task and the second column contains information about the status of the task, R

for running and B for blocked. If a task is blocked it means that it is not running but waiting

to run. The third column shows the priority of the task. The fourth column contains the

stack size of the task and the fifth and final column contains the task number, which is

an id for the task. Configuration of FreeRTOS is done through FreeRTOSconfig.h which

makes it possible to turn off or on features like callbacks, mutexes, hooks (or callbacks, i.e

idle hook) and set options like heap size and range of priorities. In this phase there was a

lot of research about the different libraries and techniques that the project was built upon.

4.3 Phase 2

This phase describes the implementation of FreeRTOS+TCP. It explains what has been

done to get FreeRTOS+TCP to work and what problems were faced with FreeRTOS+TCP.

4.3.1 FreeRTOS+TCP

To implement a TCP/IP stack FreeRTOS+TCP was used and the first step was to add

the files to the existing project with FreeRTOS. FreeRTOS+TCP has to be modified to

enable integration with the hardware. For this to work there needs to be a configuration

28

file (FreeRTOSIPConfig.h) for TCP/IP settings. This file is used to define many constants

that are needed to enable necessary functionality in the system. The driver included with

FreeRTOS+TCP does not necessarily work for an arbitrary Ethernet driver and some

modification of the driver might be needed. This was the case for our project. Before

realizing that it was a faulty network driver a lot of troubleshooting was done to figure

out why the card could not send or receive any packages. An oscilloscope was connected

to the ethernet component to investigate if the component was faulty. Testing with the

oscilloscope suggested that the hardware was working but no traffic was found on the

component. The user guide for the board also stated that they had switched the receive

(RX) and transmit (TX) pin in revision 8 of the SAMV71 and it was unknown to us if

FreeRTOS had taken this into account when including the network driver in their code.

After this we contacted FreeRTOS and got the answer that the driver that was included

was for a card that had three queues. The card used in the project had six queues and the

priority of them had to be initialized to zero. The solution for this was to add GMAC QUE 3,

GMAC QUE 4, GMAC QUE 5 to the enumerated list as can be seen in Listing 7. The priority

of these queues had to be set to null to be able to use them in the system.

Listing 7: Enumerated List of GMAC Queues

1 /* This is the list of GMAC priority queue */

2 typedef enum {

3 GMAC_QUE_0 = 0,

4 #if !(SAM4E)

5 GMAC_QUE_1 = 1,

6 GMAC_QUE_2 = 2,

7 GMAC_QUE_3 = 3,

8 GMAC_QUE_4 = 4,

9 GMAC_QUE_5 = 5,

10 #endif

11 # if !defined(__DOXYGEN__)

29

12 GMAC_QUE_N ,

13 # endif

14

15 }gmac_quelist_t;

With the help of both the hardware manufacturer, Atmel, and the developers of the driver

at FreeRTOS a working Ethernet driver could be made.

4.4 Phase 3

This phase describes the implementation of TLS and MQTT in the system.

4.4.1 WolfSSL

The first step to implement TLS in the project was to add all the relevant source files and

header files from the WolfSSL library to the project. The next step was to make sure that

the TLS certificates were stored correctly in memory buffers as our system does not have a

filesystem. To set up a TLS connection between the client and the broker, the client needs

to at least load the CA certificate of the broker. The implementation of TLS was paused

to start with MQTT so there was a service to test TLS with. The TLS library is made to

work for many different operating systems and because of that certain configuration must

be made to get WolfSSL to work for the targeted system. The configuration is made in

the user settings.h file and in this file cryptographic functions where enabled. In this file,

it is also possible to activate debug mode to get prints that would help debug the program

and if the system uses a main driver or not. The file was configured from an example that

was included in WolfSSL and with some other defines that WolfSSL thought were needed

in order to get TLS to work. Listing 8 is a part from user settings.h and it contains the

important configuration in order to get WolfSSL to work on our platform. One important

setting for our system is the WOLFSSL SMALL STACK, which makes WolfSSL optimize the

library for a system with a small stack size. Another important setting is USE FAST MATH,

30

which optimizes the speed of the mathematical calculations. WOLFSSL GENERAL ALIGNMENT

is also very important. It is used to align the memory of WolfSSL data structures to be

the same size as the rest of the system, the alignment size can vary depending on CPU.

Listing 8: WolfSSL Configuration

1 #define ENABLE_MQTT_TLS

2 /* Platform */

3 #undef WOLFSSL_GENERAL_ALIGNMENT

4 #define WOLFSSL_GENERAL_ALIGNMENT 4

5

6 #undef SINGLE_THREADED

7 #define SINGLE_THREADED

8

9 #undef WOLFSSL_SMALL_STACK

10 #define WOLFSSL_SMALL_STACK

11

12 #define WOLFSSL_USER_CURRTIME

13

14 #define WOLFSSL_SHA256

15 #define WOLFSSL_STATIC_RSA

16 #define WOLFSSL_STATIC_PSK

17

18 #undef WOLFMQTT_NONBLOCK

19 #define WOLFMQTT_NONBLOCK

20

21 #undef WOLFMQTT_NO_TIMEOUT

22 #define WOLFMQTT_NO_TIMEOUT

23

24 #define WOLFMQTT_DEBUG_SOCKET 1

25 #define WOLFMQTT_DEBUG_CLIENT 1

26

27 /* Math Configuration */

31

28 #undef USE_FAST_MATH

29 #define USE_FAST_MATH

30 #define SIZEOF_LONG_LONG 8

4.4.2 WolfMQTT

WolfMQTT was implemented by including the library in our project and deleting files that

were not necessary, such as examples and files relating to other operating system e.g. Linux

make files. Next, a remote broker was configured to collect all the data that our system

publishes. For testing purposes a free MQTT broker from mosquitto was used. After some

troubleshooting with our network driver the conclusion was that the sliding window feature

of the driver did not work correctly as the MQTT packages had an incorrect size. Turning

off this feature in FreeRTOSIPConfig.h solved that issue and the system was publishing

test data to the broker. Listing 10 contains the code for publishing data to the broker.

By setting ENABLE MQTT TLS the MQTT client will try to connect to port 8883 on the

broker, which is the port used for secure communication and if its is not set the client

will proceed with an unencrypted connection on port 1883. The settings for the packages

is QoS 0 because it was not necessary for every value to reach the broker and by using

QoS 0 the system does not have to think about receiving acks from the broker. There are

other settings that were not used, such as retain, which means that the broker can save the

last message that has been sent so that clients that start to subscribe can get the message

that was sent before they subscribed to the topic. Another option is to set keep alive,

which means that the broker and client will keep the connection as long as both are up

and running. The settings for the MQTT client can be found in Listing 9.

Listing 9: MQTT Configuration

1 /* Configuration */

2 #define MQTT_BUF_SIZE 1024

32

3 #define DEFAULT_MQTT_HOST "test.mosquitto.org" /* test.mosquitto

.org */

4 #define DEFAULT_CMD_TIMEOUT_MS 30000

5 #define DEFAULT_CON_TIMEOUT_MS 5000

6 #define DEFAULT_MQTT_QOS MQTT_QOS_0

7 #define DEFAULT_KEEP_ALIVE_SEC 60

8 #define DEFAULT_CLIENT_ID "WolfMQTTClient"

9 #define WOLFMQTT_TOPIC_NAME "EX/test"

10 #define DEFAULT_TOPIC_NAME "EX/test"

11

12 #ifdef ENABLE_MQTT_TLS

13 #define USE_TLS 1

14 #else

15 #define USE_TLS 0

16 #endif

Listing 10: MQTT Publish

1 vTaskDelay (1000);

2 rc = MQTT_CODE_SUCCESS;

3 if (rc == MQTT_CODE_SUCCESS) {

4 cntr ++;

5 XSNPRINTF(

6 PubMsg ,

7 sizeof(PubMsg),

8 "%d.%.2d",

9 (int)getSensorVal ()/1000 ,

10 (int)getSensorVal ()%1000

11 );

12

13 /* Publish Topic */

14 (&publish , 0, sizeof(publish));

15 publish.retain = 0;

33

16 publish.qos = DEFAULT_MQTT_QOS;

17 publish.duplicate = 0;

18 publish.topic_name = "EX/test";

19 publish.topic_name_len = strlen("EX/test");

20 publish.packet_id = mqttclient_get_packetid ();

21 publish.buffer = (byte*) PubMsg;

22 publish.total_len = (word16)XSTRLEN(PubMsg);

23 rc = MqttClient_Publish (&gMQTTC , &publish);

24 PRINTF("Published: %s (%d)", PubMsg , rc);

25 }

4.5 Phase 4

This phase describes the final implementation of WolfSSL and the implementation of the

sensor function.

4.5.1 WolfSSL

When TLS was applied on the MQTT service it became clear that TLS did not work as it

should. After the TCP handshake has been made, a WolfSSL object is created, initialized

and bound to the connected socket in order to set up TLS. Initially the stack and heap size

that was allocated for the MQTT task was to small. This was easily fixed by increasing

the amount of memory given to the task. After the connection phase, the broker and

the client proceeds with a TLS handshake, which includes to exchange keys and agree on

what cipher suites to use and it was at this point our client could not keep up with the

broker and instead the client stopped working. After some debugging the solution was to

implement a small delay before the client made a function call to the handshake message

function that took care of these exchanges with the broker.

34

4.5.2 Sensor

To read from the sensor it needs to be connected to a pin on the board. To convert the

incoming voltage to a digital value AFEC was used, which is a module from Atmel that can

be included from the ASF wizard. With AFEC it is possible to set up an input channel and

convert the incoming analog value from the pin. The first step to do is to initialize the base

address for the controller and then enable the channel you want to use to the controller’s

base address. After this was done the conversion of the analog value could start. A call to

the get value function could be made on the channel to get the converted value. Figure 4.3

is a snapshot of the schematics of SAMV71 found in Figure 4.2, and this was used to find

the right combination between the base address of AFEC, the AFEC channel and the AD

pin on the SAMV71, which needs to be right in order to get the converted value. Different

consistency of the pulp was simulated by using different weights that could be hung on the

sensor.

Figure 4.2: SAMV71 schematics. Fair use for educational usage [9].

35

Figure 4.3: Snapshot from the SAMV71 schematics showing how to configure AFEC. Fair

use for educational usage [9].

AFEC channel settings can be found in Listing 11, with explanations for the settings in

chapter 2 (see Section 2.8). The trigger for the ADC conversion has two interesting settings.

The first setting is afec set trigger(AFEC0, AFEC TRIG FREERUN) which tells the trigger

mode to Free Run. In Free Run mode a new measurement is started immediately without

waiting for a trigger event. The second setting is afec set callback(...) which tells

the AFEC that when a conversion starts, the callback function should be called. In our

project the getSensor function will start the AFEC conversion and in turn call the callback

function specified by the AFEC settings. These and all the other settings can be found in

Listing 11.

Listing 11: Sensor Function

1 #define VOLT_REF (3300)

2

3 /** The maximal digital value */

4 #define MAX_DIGITAL (4095 UL)

5

6 uint32_t g_ul_value;

7 uint32_t ul_vol;

8

36

9 bool is_conversion_done = false;

10

11 /**

12 * AFEC interrupt callback function.

13 */

14 static void afec_temp_sensor_end_conversion(void)

15 {

16 g_ul_value = afec_channel_get_value(AFEC0 , AFEC_CHANNEL_0);

17 is_conversion_done = true;

18 }

19

20 /**

21 * AFEC initialization function.

22 */

23 void afecc_init(void)

24 {

25 afec_enable(AFEC0);

26 struct afec_config afec_cfg;

27 afec_get_config_defaults (& afec_cfg);

28 afec_init(AFEC0 , &afec_cfg);

29 afec_set_trigger(AFEC0 , AFEC_TRIG_FREERUN);

30 struct afec_ch_config afec_ch_cfg;

31 afec_ch_get_config_defaults (& afec_ch_cfg);

32 afec_ch_cfg.gain = AFEC_GAINVALUE_0;

33 afec_ch_set_config(AFEC0 , AFEC_CHANNEL_0 , &afec_ch_cfg);

34 afec_channel_set_analog_offset(AFEC0 , AFEC_CHANNEL_0 , 0x200);

35 afec_set_callback(

36 AFEC0 ,

37 AFEC_INTERRUPT_EOC_0 ,

38 afec_temp_sensor_end_conversion ,

39 1);

40 afec_channel_enable(AFEC0 , AFEC_CHANNEL_0);

41 }

37

42

43 /**

44 * Function that returns the sensor value.

45 */

46 uint32_t getSensorVal(void)

47 {

48 afec_start_software_conversion(AFEC0);

49 if(is_conversion_done == true) {

50 ul_vol = (g_ul_value * VOLT_REF) / MAX_DIGITAL;

51 is_conversion_done = false;

52 }

53 return ul_vol;

54 }

4.5.3 Website

To display the values from the sensor an MQTT client in javascript was used. The javascript

client is using Paho’s MQTT library8[8] to create the MQTT client which is connected to

the Mosquitto broker to retrieve data. The website uses Dygraph9[16] to display the data

in a graph. Dygraph updates the graph every time a new value is received (see Figure 4.4).

8Paho is an open source MQTT library from Eclipse.9Dygraph is a Javascript library used to draw the graph on the website.

38

Figure 4.4: Live data from the sensor displayed in a graph on the website.

39

5 Results

The chapter starts with the overall results for the project, outlining the main questions

we set out to answer from chapter one. Each result will be explained with the relevant

technical scope starting with FreeRTOS, then TCP/IP stack results, TLS and the results

from MQTT. The chapter then evaluates the results from the project and continues with

problems and solutions faced in the project. The chapter ends with a discussions about

limitations of this project.

5.1 Overview

The platform met the requirements for the standards and libraries that were used in the

project. The real time operating system was simple to integrate with the system and it

met every expectation of what it was supposed to do. FreeRTOS+TCP was not as well

developed and some functions as Sliding Windows10 contributed with some problems but it

could handle TLS for a TCP connection. These results and more will be discussed further

in this chapter.

5.2 Main Results

5.2.1 FreeRTOS

The foundation, the bedrock of success for all other goals for this projects starts with

the abilities and capabilities of a functional operating system. We were able to start

tasks and set task priorities for scheduling. No surprises thanks to good documentation

from FreeRTOS. Scheduling could be monitored during run time thanks to a simple task

activating LED lights periodically, confirming that priorities and tasks could be interrupted

and activated without problems.

10Sliding Windows allows network packages to arrive out-of-order. Uses more resources such as RAMbut can increase network throughput.

40

5.2.2 TCP

We were able to implement a working TCP/IP stack. IP can be set both statically and

dynamically. Features such as responding to ping messages can be turned on and off to

verify that the layer has working features. For the final version, extra features that were

not needed were turned off but were useful during the development process for debugging

purposes.

5.2.3 TLS

TLS could be implemented and tested without problems. TLS is only activated for MQTT

messages, While all other traffic is unencrypted, such as DHCP and ARP.

5.2.4 Sensor

We were able to read data from the sensor connected to the current generation CPM and

by comparing the values on the CPM with the values on the website they could be verified

to be correct. When the sensor was affected the value on the website changed and this also

confirmed that the conversion worked.

5.2.5 MQTT

The MQTT protocol works and is verified to work with all of the QOS levels enabled. The

final version uses QOS 0. The MQTT implementation also works with and without TLS

without noticeable impact on performance.

5.3 Implementation Evaluation

Our results are directly comparable to our expectations where the real challenge was not

if the features could be implemented, but how easy it was going to be and if it could be

done within the limited time frame of the project. In this regard the results were mostly

41

as good as we could have hoped, with the exception of the TCP/IP implementation that

took longer than expected. The result, however, is good.

This project was supposed to evaluate whether the open source libraries were good

enough to build a robust system that could send sensor data over TCP and if Cortex M7

was powerful enough to run this system. The Cortex M7 has more than enough computing

power for this project and the open source libraries used worked good.

5.4 Project Evaluation

The goal with the project was to implement a system on a microcontroller with a Cortex

M7 processor that would use REST and MQTT to interact with the outside world. With

REST a user should be able to make simple requests to the board. This was in reality

never completed because of the difficulty of getting TCP/IP to work on the board. The

implementation of TCP/IP took much more time and effort than expected from us in

the beginning and because of this the REST functionality was cut from the project. We

thought that getting TLS and MQTT working was more important and more interesting

for the project than implementing REST. It may have been easier if lwIP (see Section

2.4.4) was used instead of FreeRTOS+TCP for the TCP/IP stack but at the beginning of

the project we wanted to use FreeRTOS+TCP because it was made by the same company

that made FreeRTOS. lwIP, however, had the same problem as FreeRTOS+TCP with the

priority queues so this problem would have been faced regardless of what IP stack we would

have chosen. When the implementation of TLS and MQTT began, we also considered of

switching to lwIP with the mindset of lwIP being easier because of MQTT and TLS having

examples for how to implement them with lwIPs TCP/IP stack. We decided to keep the

FreeRTOS+TCP implementation since it had already been integrated and so it would be

a lot of work to change it.

42

5.5 Problems and Solutions

While working on this project we have faced some problems. The first and the biggest

problem we encountered was with FreeRTOS+TCP. The network driver for our board did

not work and it was difficult to investigate what caused the problem. We did a lot of trou-

bleshooting to find the error and suspected many different parts of the project that could

cause this problem. We could have reached a solution faster if we would have contacted

the manufacturer earlier and asked them about the problem. Another big problem we had

were with the implementation of MQTT and specifically the size of the MQTT packages.

The size of the MQTT packages was incorrect and so our client did not send the right

type of package. This problem caused a lot of confusion since we thought that something

was wrong with the MQTT implementation. Using Wireshark11 it looked like we sent the

wrong packages but the problem was how our system was handling window sizing, When

we turned off this feature the system worked as it should and we could create a MQTT

connection. This could have gone smoother if we had checked that the TCP implementa-

tion really worked. We could have tested this with an easy TCP echo and saved us some

time that we spent looking into the MQTT code for errors. The last major problem we had

under the course of this project was with the implementation of TLS. A problem with TLS

was that it was hard to test if it actually worked when we started with it. This could have

been avoided if we had started with MQTT first and then started with TLS but this was

not the biggest problem with TLS. The biggest problem was to understand what certificate

we should use and how we loaded the certificate. Since the system does not have a file

system we could not store it in a file and read it into a buffer. Another big problem was

that the TLS handshake was done too fast and so the client missed important packages.

11Wireshark is a tool used to monitor network traffic.

43

5.6 Limitations of this Project

The board does not have secondary memory which means that we could not have a file

system, this complicates matters as we are not able to store files such as html or certificates.

As we only used open source libraries that are written in C we are also limited to what

libraries we could use in the system. These limitations is partly set by us and not because

the card has these limitations. The choice of not using an sd card as a secondary memory

is because it could break when used in an industrial environment. The choice of only using

open source is because we wanted to investigate if it would be easy to implement this

system with only open source libraries and that many non open source solutions cost a lot

of money. The documentation for some of the open source libraries were also limited.

44

6 Conclusion

This project has gone very well and it has been very educational to work with such a

lifelike project. We have learned a lot about how to tackle problems that exist while

working with development of an embedded system. During our project we have also got

a better understanding of embedded development. We have realized that when working

with embedded systems there is not a lot of feedback to get for debugging the system and

to work with the little feedback that the environment or the system can give.

6.1 Future Work of this Project

It should be relatively easy to continue with the system and implement new features such as

your own MQTT broker on a server in order to get a more robust broker and to get a private

broker. A private broker is almost a must if the system is supposed to be used outside of

a development environment. REST was supposed to be part of the system and for future

work the possibility to implement REST exists. REST would give the system the ability

to communicate with other machines to change values such as calibration parameters with

simple HTTP messages. This would be a very useful feature for the system.

45

References

[1] Atmel studio. https://www.microchip.com/avr-support/atmel-studio-7. [On-line; accessed 7-May-2018].

[2] Cortex m7 overview. https://developer.arm.com/products/processors/

cortex-m/cortex-m7. [Online; accessed 14-May-2018].

[3] Freertos states. https://www.freertos.org/RTOS-task-states.html. [Online; ac-cessed 4-may-2018].

[4] Industry 4.0. https://en.wikipedia.org/w/index.php?title=Industry_4.0&

oldid=843726723. [Online; accessed 5-June-2018].

[5] Mosquitto. https://mosquitto.org. [Online; accessed 24-April-2018].

[6] Mqtt. https://mosquitto.org/man/mqtt-7.html. [Online; accessed 7-May-2018].

[7] Mqtt traffic flow figure. https://pagefault.blog/2017/03/02/

using-local-mqtt-broker-for-cloud-and-interprocess-communication/.[Online; accessed 14-May-2018].

[8] Paho mqtt client. https://www.eclipse.org/paho/. [Online; accessed 4-May-2018].

[9] Samv71 design documentation. http://www.microchip.com/Developmenttools/

ProductDetails.aspx?PartNO=ATSAMV71-XULT. [Online; accessed 3-May-2018].

[10] Tls - transport layer security. https://en.wikipedia.org/w/index.php?title=

Transport_Layer_Security&oldid=844220201. [Online; accessed 7-May-2018].

[11] Wikipedia - microcontroller. https://en.wikipedia.org/w/index.php?title=

Microcontroller&oldid=842017542. [Online; accessed 7-may-2018].

[12] Wolfssl overview. https://www.wolfssl.com/. [Online; accessed 7-May-2018].

[13] ARM. Cortex m7. https://developer.arm.com/products/processors/cortex-m/cortex-m7. [Online; accessed 7-May-2018].

[14] Atmel. Afec driver - samv71. http://asf.atmel.com/docs/latest/samv71/html/

group__sam__drivers__afec__group.html. [Online; accessed 7-May-2018].

[15] Atmel. Samv71 xplained ultra user guide. http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-42408-SAMV71-Xplained-Ultra_User-Guide.pdf. [Online;accessed 25-February-2018].

[16] Dygraph. Dygraph. http://dygraphs.com/. [Online; accessed 7-May-2018].

46

[17] FreeRTOS. Freertos overview. https://www.freertos.org/RTOS.html. [Online;accessed 14-March-2018].

[18] FreeRTOS TCP. Freertos overview. https://www.freertos.org/FreeRTOS-Plus/

FreeRTOS_Plus_TCP/index.html. [Online; accessed 7-May-2018].

[19] Microchip. Microcontroller - atsamv71q21. http://www.microchip.com/

wwwproducts/en/ATSAMV71Q21. [Online; accessed 7-May-2018].

[20] Wikipedia. Afec. https://en.wikipedia.org/w/index.php?title=Analog_

front-end&oldid=755832767. [Online; accessed 7-May-2018].

[21] Wikipedia. Cortex m processors. https://en.wikipedia.org/w/index.php?title=ARM_Cortex-M&oldid=844479614. [Online; accessed 7-May-2018].

[22] Wikipedia. Diffie hellman. https://en.wikipedia.org/w/index.php?title=

DiffieHellman_key_exchange&oldid=840239160. [Online; accessed 9-May-2018].

[23] WolfMQTT. Wolfmqtt overview. https://www.wolfssl.com/products/wolfmqtt/.[Online; accessed 7-May-2018].

47