A bare-metal microcontroller as a target for 20-sim...

A bare-metal microcontroller as a target for 20-sim-generated C code

B. (Berend) Visser

BSC ASSIGNMENT

Committee:dr. ir. J.F. Broenink

ing. M.H. Schwirtzir. E. Molenkamp

August, 2020

043RaM2020Robotics and Mechatronics

EEMathCSUniversity of Twente

P.O. Box 2177500 AE Enschede

The Netherlands

ii A bare-metal microcontroller as a target for 20-sim-generated C code

Berend Visser University of Twente

iii

Summary

By the use of 20-sim, real-time controllers for mechatronic systems can be developed. Usingthe 20-sim 4C software this controller can be run on actual hardware. Several developmenttargets are by default supported by this software, it is also possible to make a custom target.

The goal of this project is to explore the capabilities of a microcontroller as a target for 20-sim-generated C code. A microcontroller is an interesting target as it can run without an operatingsystem allowing for fast interrupt response times while having direct access to a wide range ofperipherals. Also, it can be low energy, has a small footprint on a PCB and is relatively cheap.This comes at the cost of processing power.

We found that the Arduino Due board, featuring an ARM-M3 microcontroller, can run a PIDcontroller with a 10th-order low-pass filter at a loop frequency of 100[Hz]. The combined max-imum latency per sample is 0.6[ms]. We measured latencies for the step calculation, readinginput, setting output and sending logging.

Extending the IO drivers would allow the system to be used on a wider range of plants. Thelatency can be reduced further by converting the control algorithm to work with fixed-pointnumbers. The data interface between the base station and the microcontroller should be im-proved as this is currently limiting the maximum sampling frequency.

Robotics and Mechatronics Berend Visser

iv A bare-metal microcontroller as a target for 20-sim-generated C code


v

Contents

Summary iii

1 Introduction 1

1.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Previous research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Problem definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Research Goal and requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Background 4

2.1 20-sim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Real number representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 Arduino Due . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.4 Linix test plant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Design 6

3.1 Software framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2 Test method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4 Results 11

4.1 Sample period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.2 Sensor input latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.3 Control loop calculation latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.4 Output actuation latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.5 Logging latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.6 Cumulative latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.7 Test plant performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5 Discussion 18

6 Conclusion 20

6.1 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

A Appendix: Demo instructions 21

B Appendix: Wiring schematic 23

C Appendix: Measurement data 24

Bibliography 28


vi A bare-metal microcontroller as a target for 20-sim-generated C code


1

1 Introduction

1.1 Context

The progress in digital computing over the last 50 years has allowed for increasingly advancedcyber-physical systems. Large and complex control systems require a structured way of designto keep them extendable and updatable. Simulation tools like 20-sim (Controllab Products,2020a) offer a separation between control algorithm design and embedded control system im-plementation. In this research, we will focus on embedded control system implementation.

Embedded control system implementation means that the control algorithm, designed in sim-ulation software, is converted into computer code. 20-sim offers C code generation with itsreal-time toolbox. This C code can than be configured and compiled for a specific control com-puter like a Raspberry pi.

Finding the ideal hardware target for a specific application can be challenging since the numberof supported hardware targets is limited. The package 20-sim 4C (Controllab Products, 2020b)enables running C code on hardware using open-source real-time Linux.

Even real-time operating systems can suffer from excessive jitter due to task switching(Zagan,2015). This has a significant effect on the predictability of hard real-time tasks. Also, the powerconsumption of a real-time operating system can be very high compared to the applicationcode (Dick et al., 2003).

A microcontroller can be run without an operating system. It is an embedded system withits processor, memory and peripherals on a single integrated circuit. Making a microcontrollerinto an embedded control computer can be cost-effective, low power and have a small footprintas very few external components are needed.

1.2 Previous research

An organised design style is required to keep product development efficient, maintainable andsafe.

In the paper by Broenink and Hilderink (2001), such an approach for embedded control sys-tems is described. First, the physical system should be made into a model: this can be donevia a bond-graph representation. Using this model, a control law can be designed. Then thiscontrol law is converted into computer code. All these steps are verified by simulation. Finally,in the realization step, the control algorithm is implemented on the target computer whichis connected to the physical system. The general structure for the realization is divided intothree parts: "The embedded computer and its software", "I/O interfacing" and "The applianceitself", Broenink and Hilderink (2001).

To select an appropriate embedded computer, it’s real-time scheduling capabilities are vital.For some processes, missing deadlines can lead to catastrophic failure of the system, these are"hard" deadlines (Xu and Parnas, 1993). Deadlines are called "soft", when low and constantresponse time is desirable but not required.

The real-time performance of a raspberry pi is evaluated by (Johansson, 2018). A raspberrypi is a low-cost single-board computer. This research works with Linux loaded with a real-time extension called Xenomai. Linux is a General-purpose Operating system and has a largenumber of features but is unpredictable in timing. Xenomai opts to bound and reduce thelatency of tasks that require real-time scheduling. This is achieved through using a co-kernel,which takes control of the hardware interrupt management (Gerum, 2004).


2 A bare-metal microcontroller as a target for 20-sim-generated C code

In the research of Dokter (2016), the raspberry pi was made into a target for 20-sim 4C. Here thetarget also runs Linux, but due to a compatibility issue, it could not be patched with Xenomai.The raspberry pi was found to be a valuable asset for quick prototyping with 20-sim. Adding areal-time extension was recommend, then the system would also be able to satisfy hard real-time requirements.

1.3 Problem definition

To satisfy the timing requirements, the target running the control law should possess enoughprocessing power. The C code generated by 20-sim is based on floating-point numbers. Mi-crocontrollers are cost-sensitive, therefore they do not always have a dedicated floating-pointunit. Floating-point calculations then have to emulated, requiring more computation time.

Monitoring the target over the network is very convenient, but requires a TCP/IP stack. There-fore, decisions have to be made about which functionality can be implemented and which not.

1.4 Research Goal and requirements

In this research, a microcontroller is evaluated as a target for 20-sim generated C code. Themicrocontroller will run bare-metal, this means there is no operating system. The ArduinoDue board is used as it is low cost, open-source and features a fast 32-bit microcontroller withdiverse input and output peripherals.

The goal is to create a software framework that can run control algorithms exported from 20-sim. Features like automatic compilation and upload, parameter adjustment and data loggingare added to make the software convenient to use. The system is tested using a test plant tofind its real-world performance. An overview of the system functions is given in Figure 1.1.

Microcontroller

Control theplant

plantBase station

Drive theIO

Receive commands

Sense

Actuate

Send logging

Command thecontroller

Receive dataStore data

Process data

Behavedynamically

Figure 1.1: Functional overview control system

For the requirements we will follow the scheme as described by Waters (2009):

• Must have: the minimal functions required for the project to be useful

• Should have: functions that add a lot of value but are not critical

• Could have: functions that are nice to have, but not implemented when time becomesscarce.

• Won’t have: Possible desirable functions, but these are outside of this project’s scope

1. Base station requirements

1.1. The base station must be able to start the controllerThe user must be able to start the controller remotely from the base station. This isrequired for a convenient prototyping workflow.

1.2. The base station must receive data from the microcontroller


CHAPTER 1. INTRODUCTION 3

1.3. The base station must store the received data

1.4. The base station must process the data storedThe data stored from the experiments must be processed in order to evaluate theperformance of the microcontroller.

1.5. The base station should be able to change controller parameters during run timeBeing able to change parameters, like plant run time, set points and controller pa-rameters speeds up development on the target significantly as recompiling and up-loading is not needed.

1.6. The base station could have an automated uploading schemeThe user is protected from a lot of target specific technicalities and can instead focuson the control system itself.

2. Micro controller requirements

2.1. The micro controller must receive commands

2.2. The micro controller must control the plant real time

2.3. The micro controller must have basic IO drivers

2.4. The micro controller must send logging

2.5. The micro controller could have IO drivers implemented for all the sensors availableHaving access to various IO drivers allows for more complex designs of the controlsystem.

3. Plant requirements

3.1. The plant must react on steering values by showing dynamic behaviour

3.2. The plant must provide its status via its sensor interface



2 Background

2.1 20-sim

20-sim is a software tool for simulating the dynamic behaviour of cyber-physical systems(Broenink, 1999a). The tool facilitates model-driven design (Bezemer, 2013), allowing complexcontrol algorithms to be created for multi-domain physical systems.

Physical systems can be modeled in 20-sim through bond-graphs (Broenink, 1999b). Bond-graphs are a graphical representation of domain-independent system components like capaci-tors, springs, inductors and inertial masses. The components are connected through ports thatspecify the transfer of energy between the components.

A control algorithm can be exported as C code (Kleijn, 2009) which can then be implementedon a hardware target which is connected to the actual physical system.

2.2 Real number representation

Representing real numbers in digital systems means trade-offs have to be made between pre-cision, speed, power usage and development cost (Gaffar et al., 2004). Floating-point numbersrepresentations are efficient when a large dynamic range is required. The IEEE 754 standarddescribes how floating-point numbers are represented. It can be implemented either in soft-ware, hardware or a combination of the two. Emulating floating-point arithmetic in softwaretakes significantly more processing time (Iordache and Tang, 2003) compared to a dedicatedfloating-point unit.

Integer arithmetic is supported by most microcontrollers, minimizing processing time. Fixedpoint numbers are integer numbers scaled by a fixed factor (Yates, 2009). This makes efficientimplementation in microcontrollers possible without requiring specialized hardware. Fixedpoint numbers suffer from a reduced dynamic range compared to a floating-point number withthe same data size.

2.3 Arduino Due

The Arduino Due board features a 32-bit ARM Cortex M3 microcontroller, clocked at a fre-quency of 84[M H z]. It has no operating system, allowing for direct access to input and outputperipherals. Among the supported peripherals are:

• 2 channel - 12 bit - 1 MSPS - Digital to analog converter

• 16 channel- 12 bit - 1 MSPS - Analog to digital converter

• 8 channel - 16 bit - Pulse width modulation

• 3 Quadrature Decoders

• USB 2.0

• 1 UART & 4 USART

• 103 GPIO lines

The microprocessor on the board has no dedicated Floating-point unit, but it supports the"UMULL" instruction. This multiplication instruction takes two 32-bit integers and producesa 64-bit output (Yiu, 2010), which allows for efficient implementation of fixed-point numbers.


CHAPTER 2. BACKGROUND 5

2.4 Linix test plant

The Linix plant was designed as a mechatronic demonstrator for 20-sim software (Bax, 2006).

The Linix consists of a DC-motor and a flywheel. The flywheel and the DC-motor have dif-ferently sized pulleys, which are connected through an elastic band. It can be modeled as a4th-order system. The 20-sim model is shown in Figure 2.1 and a 3D model is shown in Figure2.2.

Figure 2.1: 20-sim model of the Linix test plant, Electrical part of the DC motor(red), mechanical partDC-motor (blue), belt and pulleys (green), flywheel(orange)

A motor driver and angle sensor are connected to the Linix setup, these actuate and measurethe system. The motor driver receives two digital signals. One sets the motor direction and theother is a square wave with a varying duty cycle which sets the motor speed. The position of theflywheel is measured with an angle sensor. The position is digitally encoded in 2 square wavesthrough quadrature encoding.

Figure 2.2: 3D-model of the Linix test plant



3 Design

A testbench is needed to evaluate the performance of the microcontroller. The testbench con-sists of a base station for commanding and monitoring, a test plant to find real-world perfor-mance, a measurement setup that can measure the actual system performance, and the Ar-duino due board itself (see Figure 3.1).

The C code generated by 20-sim only provides the control algorithm. A software framework isrequired that can handle other system tasks like variable logging and input and output control.

Base station Arduino Due Board test plant setup

measurement setup

Figure 3.1: Overview of different subsystems

3.1 Software framework

The software framework has to perform a number of functions which are partly executed onthe base station and partly on the micocontroller(see Figure 3.2). The basestation software isimplemented using Matlab and the microcontroller software with C++.

Export loopcontroller from

20-simConnect target configure

inputs & outputsCompile&upload

controller

set parameters run controller

store logging process data

connect configure compile Processingcommanddesign

Microcontroller

Basestation getparameters

Figure 3.2: Overview of functions the software framework has to perform

3.1.1 Base station

First, a control algorithm is exported from 20-sim. The exported files consist of C code and atoken file. The C code contains the controller algorithm and the token file contains informationabout the configuration. This includes the number of parameters, variables and states and theirnames.

After connecting the microcontroller to the base station the input and output ports should beconfigured. Using the token file, the base station can determine how many ports there are.Since only one test setup is used the ports are set by default and cannot be changed. The Ccode is then added to the target code and the base station compiles and uploads the targetcode to the microcontroller.


CHAPTER 3. DESIGN 7

After uploading has finished the microcontroller reboots and goes into a state called "start-up".In the start-up state, a minimal number of peripherals is initialized to minimize power usage ofthe microcontroller. The base station sends the "INIT" command to initialize all in and outputperipherals and the control algorithm. The microcontroller is now in the "initialized" state.

By sending the "GETPAR" command, the microcontroller transmits all current parameter val-ues to the base station. Using parameter names provided by the token file, the base stationmaps the received values to the correct parameter names. This way the user knows which valuecorresponds to which parameter. The parameters can be changed by sending the "SETPAR"command.

With the "START" command, the microcontroller is put in the "running" state which starts thecontrol algorithm on the microcontroller. During the running state, the microcontroller trans-mits variable and state data to the base station every sampling period. This data are storeduntil the "STOP" command is sent. The stop command puts the microcontroller in the "fin-ished" state, this stops the control algorithm.

The stored logging is now copied into a data structure with field names corresponding to vari-ables names. This data structure can then be used for further processing like transient plottingor frequency analysis.

3.1.2 Microcontroller

The paper of Broenink and Hilderink (2001) describes a general structured approach for em-bedded control software design. In Figure 3.3, an overview of the design is given. The micro-controller software is implemented using the C++ programming language, as it has extendedsupport for classes compared to traditional C. Using component-based software design (Heine-man and Councill, 2001), a clear separation of system functions is realized. This can aid devel-opment and make it easier to extend the system.

Microcontroller softwareCommand and control

UART driver

Init loop controller

Loop controller

start/stop loop controller

get/set variablesparameters

IO-drivers

Handle commandsSend logging

Base station

Plant

Control algorithm

Figure 3.3: Layered microcontroller software structure

The loop controller is hard real-time as missing a sample deadline can lead to system failure.It contains the control algorithm. Before compilation, the C code files generated by 20-simare copied into the source files of the microcontroller software. The C code files are accordingto a certain standard, therefore the microcontroller software is universal for different controlalgorithms. The control algorithm might miss certain elements for example, it could have zerostates. This is handled through conditional compilation, this allows the compiler to ignore



parts of the code based on the definition of certain variables. The input and output drivers arealso a component of the loop controller. The control algorithm works directly on actuators andsensors connected to the physical plant. Hence the IO-drivers also work in the hard real-timedomain.

The control algorithm is initialized, started and stopped through the command and controlcode. Missing a deadline here decreases the quality of service, but it does not lead to systemfailure. The loop controller component is contained inside the command and control code.The commands are transmitted over a UART connection. The commands can start and stopthe loop controller, and set the parameters of the control algorithm. Also, the variable loggingis managed through the command and control code.

3.2 Test method

In this research, the real-world performance of the microcontroller is verified by testing thesystem with a physical plant. By measuring processing latencies of the system, we can deter-mine for which applications the microcontroller is a suitable target. Each test is performed for10 minutes to get reliable results of the maximum, minimum, average and standard deviationof the measured latencies.

The complexity of the control algorithm is varied to find the performance over a wider spec-trum. The complexity of control algorithms created in 20-sim can be categorized by the num-ber of independent states, equations and variables. The values of these criteria for a specificalgorithm can be read from the token file that is generated together with the C code.

The computational precision of the algorithm is also varied by using single and double-precision floating-point numbers. Single-precision floating-point numbers only require halfthe memory. Since the microcontroller has a relatively low amount of memory, it could be use-ful to switch to single precision if the increased error does not cause any problems.

We also study the effect of different setpoint curves on the latency of the microcontroller. Eachtest scenario is executed with a sine wave curve, a periodic cycloidal motion profile and asquare wave. In each of the tests, the same amplitude is used. It is expected that the systemexperiences different latencies under different setpoint curves.

Another important system aspect is the sampling frequency. We will measure the consistencyof the sampling period for different loop frequencies. Sampling time jitter is an important sys-tem characteristic and should be taken into account for real-time systems as it can have a sig-nificant effect on control algorithm behaviour (Marti et al., 2001).

3.2.1 Measurement and plant setup

An overview of the measurement and plant setup is given in Figure 3.4. The input and outputdrivers of the microcontroller send and receive digital signals over wire connections.

The “Linix” is used as the physical plant.


CHAPTER 3. DESIGN 9

Microcontroller

Measurement Test setup

IO-drivers

motordriverangle encoder

oscilloscope(RTB2004) PWM

DC-motor

Angle

Flywheel belt

Figure 3.4: Overview of the measurement setup

The latency is measured by an oscilloscope with a logic analyzer. When a certain part of thecontrol algorithm is started a digital output pin is set high and when it is finished the digitalpin is set low again. This generates a square wave with a positive pulse width that correspondsto the execution time of the algorithm. Setting an output pin takes processing time and doesinfluence the measurements. To minimize this effect the output pins are set by directly writingto the IO-pin peripheral registers.

3.2.2 Measurements

The microcontroller is tested using 3 different test algorithms with 3 different input signals and2 precision levels each for 10 minutes. The test algorithms are implemented in the discretedomain and consist of a PID controller, a PID controller with a 5th-order low-pass filter and aPID controller with a 10th-order low-pass filter. The controller schematic is shown in Figure3.5.

The input signals are a continuous pulse cycloid, a square wave and a sinewave, all with am-plitude 2π. The amplitude was chosen to be 2π so that during real-world testing obvious setupproblems can be spotted visually. The periods are respectively 8, 6.28 and 6 seconds. The pe-riods are chosen 10 times larger than the biggest time constant of the system. This makes surethat the system has time to settle during the period of the setpoint curve and does not start tooscillate.

A sine wave was chosen as it contains only one frequency component. The square wave con-tains high-frequency components as well. The motion profile is a combination of the two. Thisallows us to study the effect of signal input on algorithm calculation time.

Input signal 5th/10th order low-pass filter

Angle

PWM duty cyclePID+-

Figure 3.5: Control algorithm used for bench marking



The PID controller is a widely used control algorithm in industrial control systems (Knospe,2006) hence it was chosen for the system performance test. To increase computational com-plexity a low-pass filter was added. The filter is placed after the input signal, to be able to verifythe filter functionality. Since the input signal in simulation should be the same in the real worldtest, we can compare the signals check for any deviations.

The low-pass filter has a cut-off frequency of 0.5[H z], which is lower than the plant time con-stant but higher than the input signal frequency. This way the input signal is filtered partiallyand the loop can maintain its stability. The filter order was based on the amount of memoryrequired to store all the system parameters. A 15th order filter was found to be the limit of themicrocontroller. During measurements a reasonable margin of 5 orders lower was chosen toprevent any memory related bottlenecks.

The bandwidth of the data link is limited. For data monitoring purposes we want to log allvariables and states. The sampling rate is selected such that the bandwidth of the data link isnot exceeded. The complex algorithm has more variables and states and is tested at a lowersampling rate. The sampling rate should not affect measurements of individual samples.

It is important to examine sampling-time consistency. Therefore, the period between individ-ual samples is also measured. We measure at a sampling rate of 100[H z] and a 1000[H z]. The100[H z] sampling rate is the maximum sampling frequency for which all the different controlalgorithms can still send all their logging data. The 1000[H z] is the maximum sampling fre-quency for which the algorithm with the least number of variables can still send all its data.

Finally, the effect of using single-precision and double-precision floating-point numbers is ex-amined. As double-precision numbers require 64 bits of memory and single-precision onlyhalf, there should be a significant difference in calculation time between the different datatypes. The effect of the increased error will also be examined by comparing simulation dataand logged data.


11

4 Results

An overview of the measurement setup is shown in Figure 4.1. The programming interface anddata interface are connected to a base station running Matlab.

All the tests are executed for 600 seconds. The data is normalized per test set, to allow foreasier comparison between subtests. The normalisation factor is based on the mean latency ofthe double-precision cycloid test. The sampling period is fixed per test. The double-precisionmeasurements are abbreviated by ’DP’ and the single-precision measurements by ’SP’.

Figure 4.1: Complete setup

4.1 Sample period

The sample period of 1[ms] has a maximum deviation of ±0.11%. The mean period has a posi-tive offset of 2 ·10−3%. The relative standard deviation is 0.04%.

The sample period of 10[ms] has a maximum deviation of±0.02% and the mean period has alsoa positive offset of 2 ·10−3%. The relative standard deviation is ∼ 10 times lower with 0.0044%.



The relative difference in the mean is equal for both measurements. The absolute standarddeviation is also the same but the relative maximum-minimum and standard deviation are 10times bigger for the shorter sampling period.

required period [ms] min[ms] max [ms] mean[ms] σ[ms]1 0.9989 1.0011 1.00002 0.0004210 9.999 10.002 10.0002 0.00044

Table 4.1: sample period measurement

4.2 Sensor input latency

There is no consistent difference in latency between double-precision tests and single-precision tests (see Figure 4.2). Over the results of different algorithms there is also no correla-tion between increased algorithm complexity and sensor input latency. The maximum latencyis 20% higher and the minimum latency is 75% lower than the reference mean. The standarddeviation is consistent over all tests at ∼ 5%.

The absolute maximum sensor input latency over all tests is ∼ 17.9[µs].

Figure 4.2: sensor input latency - normalization factor of 14.91[µs]left:PID - 250[Hz] , middle:PID + 5th-order filter - 150[Hz], right:PID + 10th-order filter - 100[Hz]

4.3 Control loop calculation latency

The maximum latency of the cycloid input signal for the PID algorithm is 75% higher than thereference mean (see Figure 4.3a). The minimum latency is 50% of the reference mean. Theminimum and maximum latency are consistently lower for the single-precision calculation forall subtests. The maximum latency for the square wave input signal is 1.93 times lower forthe single-precision test. The maximum latency of the sine wave input is lower than that ofthe cycloid but its mean is 25% higher. The square wave input signal has a significantly lowerstandard deviation and its mean is much lower than that of the cycloid input signal. The sinewave input is in between the two measurements.


CHAPTER 4. RESULTS 13

(a) PID - 250[Hz[

(b) PID + 5th-order filter - 150 [Hz]

(c) PID + 10th-order filter - 100[Hz]

Figure 4.3: loop calculation latency - normalization factor of 83.51[µs]



For the algorithm with the added 5th-order low-pass filter, the relative standard deviation forall algorithms except the square wave becomes smaller. The maximum and minimum latenciesbecome less spread for the different input signals. Also, the mean calculation time has overallincreased by a factor of 2.5.

The mean calculation time for the PID + 10th-order low-pass filter algorithms has increased bya factor of 6 for all the tests. The difference in maximum latency has reduced even further.

The absolute maximum loop calculation latency over all the tests is ∼ 550[µs].

4.4 Output actuation latency

The mean latency of setting the output is consistent over all three tests (see Figure 4.4). Thereis no trend between algorithm complexity and single or double-precision calculations.

The absolute maximum output setting latency over all tests is ∼ 16.5[µs].

Figure 4.4: Set output actuators latency - normalization factor 14.03[µs]left:PID - 250[Hz] , middle:PID+5th order filter - 150[Hz], right:PID + 10th order filter - 100[Hz]

4.5 Logging latency

The maximum logging latency is 10% lower for the single-precision compared to double-precision in the PID algorithm test (see Figure 4.5). The difference in logging latency betweensingle and double-precision becomes bigger when the algorithm has an added low-pass filter.

The maximum absolute logging latency over all the tests is ∼ 6.7[µsec].



Figure 4.5: logging latency - normalization factor 3.577[µs]left:PID - 250[Hz] , middle:PID+5th order filter - 150[Hz], right:PID + 10th order filter - 100[Hz]

4.6 Cumulative latency

In Figure 4.6 the timing diagram of the total maximum latency is shown.

Sn An

0

: Sample input

: Calculate step

: Jitter

: Set output

: Log data

0.1 0.2 0.3 0.4 0.5 0.6Time [ms]

10.0

Sn+1

Figure 4.6: Timing diagram of the PID + 10th order low-pass filter algorithm with Fsample = 100[hz],Calculate step represents the mean latency

The total maximum latency is ∼ 0.59[ms], which is ∼ 5.9% of Tsample at a frequency of 100[H z].

The combined maximum latency of getting the input and setting the output is ∼ 0.034[ms].This is ∼ 0.34% of the total sampling period at a sampling frequency of 100[H z].

The maximum latency of logging is ∼ 0.007[ms] which is ∼ 0.07% of the total sampling periodat a sampling frequency of 100[H z].

4.7 Test plant performance

The error for double-precision numbers stays constant throughout the experiment (see Figure4.7a). The error oscillates with an amplitude of 0.1 ·10−3[r ad ] and has a period of 2.5 seconds.

The test with single-precision numbers starts with an error equal to that of double-precision.At the end of the test however, there is a time shift of ∼ 0.28[s] between the simulated data andthe experiment which leads to a maximum error of almost 2[r ad ].



(a) PID + 10th-order cycloid input DP

(b) PID + 10th-order cycloid input SP

Figure 4.7: setpoint error, the measurement is after the input signal has been filtered by the low-passfilter, the error is scaled for readability

4.7.1 sensor signal

The absolute error for the double-precision measurement between the simulated sensor inputand measured sensor input is below 0.2[r ad ] and is maintained during the entire length of thetest run.

The single-precision error starts the same as the double-precision but becomes almost 2[r ad ]at the end of the test due to a time shift of ∼ 0.28[s].



(a) sensor input of PID + 10th-order low pass with a cycliod input signal double-precision - 100[Hz]

(b) sensor input of PID + 10th-order low pass with a cycliod input signal single-precision - 100[Hz]

Figure 4.8: error in setpoint between simulation and real measured data



5 Discussion

We tested the following characteristics:

• Sample period measurement

• Input latency

• step calculation latency

• Output latency

• Logging latency

• Test plant performance

The generated sampling period has a relative offset. This was expected as the oscillator crystalthat generates the clock signal of the microcontroller has a finite precision causing the differ-ence. A more precise oscillator like a temperature-controlled crystal oscillator can reduce theoffset.

The control software is constantly polling for a new sample at a certain frequency. This imple-mentation adds sampling time jitter. However, implementing the sampling generation with aninterrupt instead of through polling could yield a much lower jitter.

The input latency should be constantly low relative to the sampling period to minimise sam-pling jitter. Choosing a high sampling frequency increases the relative jitter as this jitter isindependent of the sampling period. The designer of the control loop should consider themaximum allowable delay bounds of their control algorithm to decide if this meets their spec-ifications.

The step calculation latency shows a consistent performance gain for single-precision overdouble-precision. It is important to note that at the cost of half the precision we do not gaintwice the performance. Since part of the algorithms does involve logic statements which seeno benefit from single-precision over double-precision it is expected that the cumulative per-formance gain is less than two.

Maximum latency is of main interest as this describes the worst-case performance of the sys-tem. For hard real-time systems, this latency should always be bounded. The PID algorithmwith a cycloid input shows a relatively large gap between mean and maximum calculation time.The sine and square wave inputs show a much smaller difference.

The motion profile block generates the cycloid signal and makes use of a lot of logic statements.The number of logic statements the algorithm has to check, varies greatly during run time.Hence a lot of jitter is generated. The implementation of the sine and square wave are simplerand therefore generate less jitter. For the PID with the 5th and 10th-order filter algorithms, thedifference between mean and maximum becomes much smaller. Since the cycloid generationtakes up a much smaller part of the total algorithm the relative jitter becomes smaller too.

The output latency shows similar results as the input latency. The time required to changethe output can be improved by simplifying the driver design. Currently, the driver convertsan output signal between −1 and 1 from the control algorithm to a suitable duty cycle for thePWM peripheral. By instead letting the control algorithm pre-calculate the duty cycle, thiscalculation time would be saved reducing the latency.

Logging variables is a monitoring task and is soft real-time. The direct memory access con-troller was used to minimize CPU overhead. The increase in latency for the more complex


CHAPTER 5. DISCUSSION 19

algorithms is due to the increased number of variables and states. The monitoring algorithmhas to copy more data, which increases latency.

The error in setpoint for the double-precision should be zero as the same data type and algo-rithm are used. The cycloid input signal generation, however, is dependent on trigonometricfunctions. These functions are not standardized among hardware platforms (Monniaux, 2008).

Every sample the current run time is increased by the sample step size. If the step size cannot be exactly represented by the floating-point number a rounding error occurs. At the startof the test, this error might not be significant, however, at the end of the test this error hasaccumulated and becomes clearly visible for the single-precision data type. This issue can beresolved by using a higher precision data type or by selecting a time step that can be exactlyrepresented and thus prevent rounding.

The error between simulation sensor data and measurement sensor data can occur due to aninaccurate simulation model of the mechanical system or if sensor readings do not match theactual state of the system. Bearing friction is highly non-linear at slow rotational speeds, but itis modeled as a linear fiction in simulation. The error is the largest when the angular velocityof the flywheel is zero, this coincides with the part where bearing fiction is very non-linear.

The increased error with single-precision numbers is again a result of an accumulating round-ing error.



6 Conclusion

The goal of this project was to investigate if a bare-metal microcontroller is a suitable hardwaretarget for 20-sim generated code. The Arduino Due microcontroller was used and a softwareframework was created to run generated code with a test plant. We measured latencies forgetting sensor data, step calculation, setting actuators and logging variables. The maximumlatency for a control algorithm consisting of a PID controller with a 10th-order low-pass filter is∼ 600[µs]. This is only 6% of the total sample period at a loop frequency of 100[H z]. The dataconnection with the base station has not enough bandwidth to keep up with variable loggingat higher frequencies.

In conclusion, the Arduino Due can be a suitable target for a wide range of real-time controlalgorithms like PID controllers combined with digital filters with sampling frequencies up toabout 100[H z].

6.1 Recommendations

Use a faster communication channel for the data interface. Data logging is currently the limit-ing factor for the sampling frequency. The Arduino Due supports high-speed USB which has amuch larger bandwidth than the current data connection over UART.

Add live variable plotting, so the variables can be viewed during a test run. Currently, the datacan not be viewed until the test run has been finished. By adding live plotting the user can spotissues during a test saving a lot of time during controller development.

The Arduino Due has a lot of build-in IO-ports like an ADC, 2 DACs and GPIO. By adding driversfor these peripherals the system could be used for a wider range of test plants.

The control algorithm can be converted to work with fixed-point numbers. As there is no dedi-cated floating-point unit in the microcontroller, there could be a significant performance gainby using fixed-point numbers.


21



A Appendix: Demo instructions

Demo instructionsDemo instructions

SetupSetup

PrerequisitesPrerequisites

The demo requires the following software tools listed below.

20-sim - 4.8 Matlab - 2020a Arduino IDE - 1.8.13

InstallingInstalling

1. Install the Arduino SAM Boards(32-bits ARM Cortex-M3) in Tools->Board:->Boards manager... .

2. Go to C:\Users\[USERNAME]\AppData\Local\Arduino15\packages\arduino\hardware\sam\1.6.12\variants\arduino_due_x and openvariant.cpp

Comment out the following lines:

/*

void UART_Handler(void)

{

Serial.IrqHandler();

}

*/

3. Unzip Demo.zip and copy the contents of Demo\libraries into C:\Users\[USERNAME]\Documents\Arduino\libraries .

SettingsSettings

4. Connect the Arduino Due programming interface and the Data interface

5. Open the Arduino IDE and select Arduino Due Programming port in Tools->Board:->Arduino ARM (32-bit) Boards

6. Select the Arduino Due programming port in Tools->Port

7. Open Demo\Command_and_control\main.m with Matlab and run serialportlist in the command window and set XX to the port of the Data interface

%% comports

comport = "COMXX";

Running the testsRunning the tests

1. Open Demo\linix.emx with 20-sim and open the 20-sim Simulator window.

2. Go to Tools->Real Time Toolbox->C-Code generation and select C-Code for 20-sim submodel . Set the output directory to~\Demo\Command_and_control\ccode and select OK .

3. Run Demo\Command_and_control\main.m with Matlab

4. Select Yes in the window Upload controller?

5. Set parameters and select OK

6. Set a runtime and select OK

7. After the run finishes the variable data is loading in the Tokenstruct variable, plotting is done with:

figure(1);

plot(tokensstruct.VARIABLE_NAMES2.[SOMEVAR].TIME,tokensstruct.VARIABLE_NAMES2.[SOMEVAR].DATA);


23

B Appendix: Wiring schematic

z

61

Vcc

OUTBOUTA

gnd Vin+

GNDMotor drivervnh2sp30

DC-motor2260.815-

51.216-200

Power supply12 V

+

-

- +

ArduinoDue

USBto

SERIAL

ProgrammingInterface

DataInterface

Logicprobe

01234567Gnd

Figure B.1: Schematic of wiring connections



C Appendix: Measurement dataLo

ggin

gla

ten

cy[s

]A

lgo

rith

mP

rec

F_s

amp

leD

ura

tio

nM

inM

axM

ean

Sigm

aP

IDD

ou

ble

250[

Hz]

600[

s]3.

572E

-06

4.82

4E-0

63.

577E

-06

7.11

2E-0

8P

IDSi

ngl

e25

0[H

z]60

0[s]

2.83

E-0

64.

18E

-06

2.88

E-0

65.

39E

-08

PID

+5t

ho

rder

filt

erD

ou

ble

150[

Hz]

600[

s]4.

70E

-06

5.88

E-0

64.

76E

-06

7.83

E-0

8P

ID+

5th

ord

erfi

lter

Sin

gle

150[

Hz]

600[

s]3.

19E

-06

4.48

E-0

63.

24E

-06

6.13

E-0

8

PID

+10

tho

rder

filt

erD

ou

ble

100[

Hz]

600[

s]5.

52E

-06

6.66

E-0

65.

53E

-06

9.46

E-0

8P

ID+

10th

ord

erfi

lter

Sin

gle

100[

Hz]

600[

s]3.

68E

-06

4.89

E-0

63.

68E

-06

4.88

E-0

8

PID

Do

ub

le25

0[H

z]60

0[s]

3.41

E-0

64.

61E

-06

3.45

E-0

68.

14E

-08

PID

Sin

gle

250[

Hz]

600[

s]2.

88E

-06

4.08

E-0

62.

92E

-06

5.70

E-0

8

PID

+5t

ho

rder

filt

erD

ou

ble

150[

Hz]

600[

s]4.

09E

-06

5.26

E-0

64.

14E

-06

7.81

E-0

8P

ID+

5th

ord

erfi

lter

Sin

gle

150[

Hz]

600[

s]3.

19E

-06

4.42

E-0

63.

23E

-06

8.23

E-0

8

PID

+10

tho

rder

filt

erD

ou

ble

100[

Hz]

600[

s]5.

01E

-06

6.27

E-0

65.

02E

-06

7.63

E-0

8P

ID+

10th

ord

erfi

lter

Sin

gle

100[

Hz]

600[

s]3.

71E

-06

4.88

E-0

63.

72E

-06

4.29

E-0

8

PID

Do

ub

le25

0[H

z]60

0[s]

3.84

E-0

64.

99E

-06

3.86

E-0

65.

55E

-08

PID

Sin

gle

250[

Hz]

600[

s]3.

07E

-06

4.42

E-0

63.

12E

-06

6.28

E-0

8

PID

+5t

ho

rder

filt

erD

ou

ble

150[

Hz]

600[

s]4.

59E

-06

5.77

E-0

64.

62E

-06

1.04

E-0

7P

ID+

5th

ord

erfi

lter

Sin

gle

150[

Hz]

600[

s]3.

30E

-06

4.59

E-0

63.

33E

-06

8.42

E-0

8

PID

+10

tho

rder

filt

erD

ou

ble

100[

Hz]

600[

s]5.

45E

-06

6.62

E-0

65.

46E

-06

6.67

E-0

8P

ID+

10th

ord

erfi

lter

Sin

gle

100[

Hz]

600[

s]3.

70E

-06

4.84

E-0

63.

70E

-06

3.64

E-0

8


APPENDIX C. APPENDIX: MEASUREMENT DATA 25

Inp

utl

aten

cy[s

]A

lgo

rith

mP

rec

F_s

amp

leD

ura

tio

nM

inM

axM

ean

Sigm

aP

IDD

ou

ble

250[

Hz]

600[

s]3.

904E

-06

1.62

6E-0

51.

491E

-05

5.42

4E-0

7P

IDSi

ngl

e25

0[H

z]60

0[s]

4.46

E-0

61.

79E

-05

1.66

E-0

56.

88E

-07

PID

+5t

ho

rder

filt

erD

ou

ble

150[

Hz]

600[

s]4.

03E

-06

1.75

E-0

51.

61E

-05

1.11

E-0

6P

ID+

5th

ord

erfi

lter

Sin

gle

150[

Hz]

600[

s]4.

26E

-06

1.65

E-0

51.

51E

-05

9.97

E-0

7

PID

+10

tho

rder

filt

erD

ou

ble

100[

Hz]

600[

s]4.

05E

-06

1.75

E-0

51.

61E

-05

1.08

E-0

6P

ID+

10th

ord

erfi

lter

Sin

gle

100[

Hz]

600[

s]4.

30E

-06

1.65

E-0

51.

52E

-05

9.41

E-0

7

PID

Do

ub

le25

0[H

z]60

0[s]

4.03

E-0

61.

74E

-05

1.61

E-0

59.

22E

-07

PID

Sin

gle

250[

Hz]

600[

s]4.

32E

-06

1.66

E-0

51.

52E

-05

7.10

E-0

7

PID

+5t

ho

rder

filt

erD

ou

ble

150[

Hz]

600[

s]4.

03E

-06

1.75

E-0

51.

61E

-05

1.00

E-0

6P

ID+

5th

ord

erfi

lter

Sin

gle

150[

Hz]

600[

s]4.

31E

-06

1.66

E-0

51.

52E

-05

7.75

E-0

7

PID

+10

tho

rder

filt

erD

ou

ble

100[

Hz]

600[

s]3.

90E

-06

1.63

E-0

51.

49E

-05

9.10

E-0

7P

ID+

10th

ord

erfi

lter

Sin

gle

100[

Hz]

600[

s]4.

30E

-06

1.65

E-0

51.

52E

-05

8.80

E-0

7

PID

Do

ub

le25

0[H

z]60

0[s]

3.94

E-0

61.

58E

-05

1.45

E-0

58.

35E

-07

PID

Sin

gle

250[

Hz]

600[

s]4.

27E

-06

1.66

E-0

51.

52E

-05

8.31

E-0

7

PID

+5t

ho

rder

filt

erD

ou

ble

150[

Hz]

600[

s]3.

92E

-06

1.58

E-0

51.

45E

-05

1.12

E-0

6P

ID+

5th

ord

erfi

lter

Sin

gle

150[

Hz]

600[

s]4.

31E

-06

1.70

E-0

51.

56E

-05

1.20

E-0

6

PID

+10

tho

rder

filt

erD

ou

ble

100[

Hz]

600[

s]3.

96E

-06

1.58

E-0

51.

45E

-05

1.12

E-0

6P

ID+

10th

ord

erfi

lter

Sin

gle

100[

Hz]

600[

s]4.

43E

-06

1.62

E-0

51.

49E

-05

1.24

E-0

6



Cal

clo

op

late

ncy

[s]

Alg

ori

thm

Pre

cF

_sam

ple

Du

rati

on

Min

Max

Mea

nSi

gma

PID

Do

ub

le25

0[H

z]60

0[s]

4.30

9E-0

51.

463E

-04

8.35

1E-0

52.

879E

-05

PID

Sin

gle

250[

Hz]

600[

s]2.

73E

-05

1.13

E-0

45.

41E

-05

2.73

E-0

5

PID

+5t

ho

rder

filt

erD

ou

ble

150[

Hz]

600[

s]1.

30E

-04

2.65

E-0

42.

04E

-04

2.81

E-0

5P

ID+

5th

ord

erfi

lter

Sin

gle

150[

Hz]

600[

s]8.

92E

-05

1.90

E-0

41.

30E

-04

2.80

E-0

5

PID

+10

tho

rder

filt

erD

ou

ble

100[

Hz]

600[

s]3.

19E

-04

5.50

E-0

44.

87E

-04

3.06

E-0

5P

ID+

10th

ord

erfi

lter

Sin

gle

100[

Hz]

600[

s]2.

24E

-04

3.53

E-0

42.

92E

-04

2.80

E-0

5

PID

Do

ub

le25

0[H

z]60

0[s]

7.59

E-0

51.

18E

-04

1.05

E-0

42.

18E

-06

PID

Sin

gle

250[

Hz]

600[

s]5.

04E

-05

9.18

E-0

57.

89E

-05

2.29

E-0

6

PID

+5t

ho

rder

filt

erD

ou

ble

150[

Hz]

600[

s]1.

62E

-04

2.40

E-0

42.

27E

-04

2.10

E-0

6P

ID+

5th

ord

erfi

lter

Sin

gle

150[

Hz]

600[

s]1.

15E

-04

1.69

E-0

41.

56E

-04

2.18

E-0

6

PID

+10

tho

rder

filt

erD

ou

ble

100[

Hz]

600[

s]3.

30E

-04

5.47

E-0

45.

33E

-04

3.81

E-0

6P

ID+

10th

ord

erfi

lter

Sin

gle

100[

Hz]

600[

s]2.

48E

-04

3.30

E-0

43.

16E

-04

2.57

E-0

6

PID

Do

ub

le25

0[H

z]60

0[s]

4.04

E-0

56.

51E

-05

5.77

E-0

51.

87E

-06

PID

Sin

gle

250[

Hz]

600[

s]2.

32E

-05

3.44

E-0

52.

81E

-05

8.65

E-0

7

PID

+5t

ho

rder

filt

erD

ou

ble

150[

Hz]

600[

s]1.

25E

-04

1.94

E-0

41.

87E

-04

6.33

E-0

6P

ID+

5th

ord

erfi

lter

Sin

gle

150[

Hz]

600[

s]8.

89E

-05

1.19

E-0

41.

14E

-04

2.51

E-0

6

PID

+10

tho

rder

filt

erD

ou

ble

100[

Hz]

600[

s]3.

11E

-04

5.02

E-0

44.

88E

-04

1.54

E-0

5P

ID+

10th

ord

erfi

lter

Sin

gle

100[

Hz]

600[

s]2.

28E

-04

3.17

E-0

43.

00E

-04

6.25

E-0

6


APPENDIX C. APPENDIX: MEASUREMENT DATA 27

Seto

utp

utl

aten

cy[s

]A

lgo

rith

mP

rec

F_s

amp

leD

ura

tio

nM

inM

axM

ean

Sigm

aP

IDD

ou

ble

250[

Hz]

600[

s]1.

296E

-05

1.59

0E-0

51.

403E

-05

6.49

0E-0

7P

IDSi

ngl

e25

0[H

z]60

0[s]

1.23

E-0

51.

53E

-05

1.34

E-0

55.

78E

-07

PID

+5t

ho

rder

filt

erD

ou

ble

150[

Hz]

600[

s]1.

20E

-05

1.49

E-0

51.

31E

-05

5.87

E-0

7P

ID+

5th

ord

erfi

lter

Sin

gle

150[

Hz]

600[

s]1.

30E

-05

1.59

E-0

51.

41E

-05

6.55

E-0

7

PID

+10

tho

rder

filt

erD

ou

ble

100[

Hz]

600[

s]1.

20E

-05

1.48

E-0

51.

31E

-05

5.78

E-0

7P

ID+

10th

ord

erfi

lter

Sin

gle

100[

Hz]

600[

s]1.

30E

-05

1.59

E-0

51.

41E

-05

6.50

E-0

7

PID

Do

ub

le25

0[H

z]60

0[s]

1.20

E-0

51.

49E

-05

1.31

E-0

55.

86E

-07

PID

Sin

gle

250[

Hz]

600[

s]1.

34E

-05

1.60

E-0

51.

41E

-05

6.56

E-0

7

PID

+5t

ho

rder

filt

erD

ou

ble

150[

Hz]

600[

s]1.

20E

-05

1.48

E-0

51.

31E

-05

5.89

E-0

7P

ID+

5th

ord

erfi

lter

Sin

gle

150[

Hz]

600[

s]1.

05E

-05

1.60

E-0

51.

41E

-05

6.51

E-0

7

PID

+10

tho

rder

filt

erD

ou

ble

100[

Hz]

600[

s]1.

30E

-05

1.59

E-0

51.

40E

-05

6.49

E-0

7P

ID+

10th

ord

erfi

lter

Sin

gle

100[

Hz]

600[

s]1.

30E

-05

1.59

E-0

51.

41E

-05

6.49

E-0

7

PID

Do

ub

le25

0[H

z]60

0[s]

9.89

E-0

61.

49E

-05

1.31

E-0

57.

72E

-07

PID

Sin

gle

250[

Hz]

600[

s]1.

04E

-05

1.59

E-0

51.

38E

-05

8.44

E-0

7

PID

+5t

ho

rder

filt

erD

ou

ble

150[

Hz]

600[

s]1.

21E

-05

1.49

E-0

51.

31E

-05

6.00

E-0

7P

ID+

5th

ord

erfi

lter

Sin

gle

150[

Hz]

600[

s]1.

35E

-05

1.65

E-0

51.

47E

-05

6.82

E-0

7

PID

+10

tho

rder

filt

erD

ou

ble

100[

Hz]

600[

s]1.

21E

-05

1.49

E-0

51.

31E

-05

5.95

E-0

7P

ID+

10th

ord

erfi

lter

Sin

gle

100[

Hz]

600[

s]1.

24E

-05

1.53

E-0

51.

35E

-05

5.95

E-0

7



BibliographyBax, M. (2006), The Linix2 mechatronic demonstrator, Pre-MSc Thesis 020CE2006, University

of Twente, premsc.https://pydio.ram.ewi.utwente.nl/ws-StudentTheses/2006/bax2006premsc.pdf

Bezemer, M. (2013), Cyber-physical systems software development: way of working and toolsuite, Ph.D. thesis, University of Twente, Netherlands, doi:10.3990/1.9789036518796.

Broenink, J. F. (1999a), 20-sim software for hierarchical bond-graph/block-diagram models,Simulation Practice and Theory, vol. 7, no.5, pp. 481 – 492, ISSN 0928-4869,doi:https://doi.org/10.1016/S0928-4869(99)00018-X.http://www.sciencedirect.com/science/article/pii/S092848699900018X

Broenink, J. F. (1999b), Introduction to physical systems modelling with bond graphs, SiEwhitebook on simulation methodologies, vol. 31, p. 2.

Broenink, J. F. and G. H. Hilderink (2001), A structured approach to embedded control systemsimplementation, in Proceedings of the 2001 IEEE International Conference on ControlApplications (CCA’01)(Cat. No. 01CH37204), IEEE, pp. 761–766.

Controllab Products (2020a), 20-sim.https://www.controllab.nl/product/software/20-sim/

Controllab Products (2020b), 20-sim4c.https://www.controllab.nl/services/software/20-sim-4c/

Dick, R. P., G. Lakshminarayana, A. Raghunathan and N. K. Jha (2003), Analysis of powerdissipation in embedded systems using real-time operating systems, vol. 22, no.5, pp.615–627, ISSN 1937-4151, doi:10.1109/TCAD.2003.810745.

Dokter, J. (2016), 20-sim Template for Raspberry Pi 3, BSc Thesis 019RaM2016, University ofTwente, bsc.https://cloud.ram.eemcs.utwente.nl/index.php/s/SydM7FSnCiBiaYw

Gaffar, A. A., O. Mencer and W. Luk (2004), Unifying bit-width optimisation for fixed-point andfloating-point designs, in 12th Annual IEEE Symposium on Field-Programmable CustomComputing Machines, IEEE, pp. 79–88.

Gerum, P. (2004), Xenomai-Implementing a RTOS emulation framework on GNU/Linux,White Paper, Xenomai, pp. 1–12.

Heineman, G. T. and W. T. Councill (2001), Component-based software engineering, Puttingthe pieces together, p. 5.

Iordache, C. and P. T. P. Tang (2003), An Overview of Floating-point Support and Math Libraryon the Intel/spl reg/XScale/spl trade/architecture, in Proceedings 2003 16th IEEESymposium on Computer Arithmetic, IEEE, pp. 122–128.

Johansson, G. (2018), Real-Time Linux Testbench on Raspberry Pi 3 using Xenomai, Master’sthesis, KTH, School of Electrical Engineering and Computer Science (EECS).

Kleijn, C. (2009), 20-sim 4.1 Reference Manual, Getting Started with 20-sim.

Knospe, C. (2006), PID control, IEEE Control Systems Magazine, vol. 26, no.1, pp. 30–31.

Marti, P., J. M. Fuertes, G. Fohler and K. Ramamritham (2001), Jitter compensation forreal-time control systems, in Proceedings 22nd IEEE Real-Time Systems Symposium (RTSS2001)(Cat. No. 01PR1420), IEEE, pp. 39–48.

Monniaux, D. (2008), The pitfalls of verifying floating-point computations, ACM Transactionson Programming Languages and Systems (TOPLAS), vol. 30, no.3, pp. 1–41.


https://pydio.ram.ewi.utwente.nl/ws-StudentTheses/2006/bax2006premsc.pdf

https://pydio.ram.ewi.utwente.nl/ws-StudentTheses/2006/bax2006premsc.pdf

http://www.sciencedirect.com/science/article/pii/S092848699900018X

http://www.sciencedirect.com/science/article/pii/S092848699900018X

https://www.controllab.nl/product/software/20-sim/

https://www.controllab.nl/services/software/20-sim-4c/

https://cloud.ram.eemcs.utwente.nl/index.php/s/SydM7FSnCiBiaYw

Bibliography 29

Waters, K. (2009), Prioritization using moscow, Agile Planning, vol. 12, p. 31.

Xu, J. and D. L. Parnas (1993), On satisfying timing constraints in hard-real-time systems, IEEEtransactions on software engineering, vol. 19, no.1, pp. 70–84.

Yates, R. (2009), Fixed-point arithmetic: An introduction, Digital Signal Labs, vol. 81, no.83, p.198.

Yiu, J. (2010), APPENDIX A - The Cortex-M3 Instruction Set, Reference Material, in TheDefinitive Guide to the ARM Cortex-M3 (Second Edition), Newnes, Oxford, pp. 349 – 403,second edition edition, ISBN 978-1-85617-963-8,doi:https://doi.org/10.1016/B978-1-85617-963-8.00025-9.http://www.sciencedirect.com/science/article/pii/B9781856179638000259

Zagan, I. (2015), Improving the performance of CPU architectures by reducing the OperatingSystem overhead, in 2015 IEEE 3rd Workshop on Advances in Information, Electronic andElectrical Engineering (AIEEE), IEEE, pp. 1–6.


http://www.sciencedirect.com/science/article/pii/B9781856179638000259

http://www.sciencedirect.com/science/article/pii/B9781856179638000259

Date post:	18-Nov-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times