D2.1 Report on the Reference Hardware Development Platforms Project: Open Framework for Embedded Robot Applications

D2.1 Report on the reference hardware development platforms Project: Open Framework for Embedded Robot Applications

June 2018

1 D2.1 Report on the reference hardware development platforms

Contents

1 Introduction 6 1.1 Summary ...... 6 1.2 Purpose of document ...... 6 1.3 Partners involved ...... 6

2 Acronyms and keywords 6

3 Reference platform selection 7 3.1 Introduction ...... 7 3.1.1 Architectural context ...... 8 3.2 Selection Criteria ...... 8 3.3 Options ...... 9 3.3.1 Olimex STM32-E407 ...... 9 3.3.2 STM32L1 Discovery ...... 10 3.3.3 Hercules TMS570LS04x/03x LaunchPad Development Kit ...... 10 3.3.4 Bosch XDK110 ...... 11 3.3.5 DEVKIT-MPC5744P ...... 11 3.3.6 Robotis OpenCR 1.0 ...... 12 3.4 Selection ...... 12

4 Reference platform validation 13 4.1 Olimex LTD STM32-E407 ...... 13 4.1.1 Introduction ...... 13 4.1.2 Memory usage ...... 14 4.1.3 Power Consumption Measurements ...... 15 4.2 5.2 STM32L1 Discovery ...... 15 4.2.1 Introduction ...... 15 4.2.2 Memory usage ...... 15 4.2.3 Power Consumption ...... 16 4.3 TI Hercules LaunchPad TMS57004 ...... 17

5 Reference Hardware Development Platform selection 17

6 Reference Hardware Development Platform development 18 6.1 General development resources ...... 19 6.1.1 NuttX shell ...... 19 6.1.2 GPIO ...... 19 6.1.3 I2C ...... 20 6.1.4 SPI ...... 20

2 D2.1 Report on the reference hardware development platforms

6.1.5 UART ...... 20 6.1.6 ADC ...... 20 6.1.7 SD Card ...... 20 6.1.8 Ethernet ...... 20 6.1.9 802.15.4 protocol support ...... 20 6.1.10 6LOWPAN protocol support ...... 20 6.1.11 Zigbee protocol use ...... 21 6.1.12 Power Consumption and Management ...... 21 6.2 RHDP development: Olimex LTD STM32-E407 ...... 22 6.3 RHDP development: STML1 Discovery ...... 24

7 RTOS analysis 25 7.1 Microcontroller RTOS overview ...... 25 7.2 Additional RTOS test ...... 31 7.2.1 Olimex STM32-E407 ...... 31 7.2.2 STM32-L1 Discovery ...... 31 7.2.3 TI LaunchPad TMS570LS04 ...... 31 7.3 Conclusion ...... 32

8 ROS2 RIOT prove of concept 32 8.1 ROS2 NuttX test ...... 32

9 Supporting tools 32 9.1 Introduction ...... 32 9.2 RHDP development containers ...... 32 9.2.1 Olimex LTD STM32-E407 Docker file ...... 33 9.2.2 STML1 Discovery Docker file ...... 33 9.2.3 TI LaunchPad TMS57004 Docker file ...... 33 9.3 Development guides ...... 33

10 Appendix A: NuttX guide 34 10.1 NuttX basic concepts ...... 34 10.1.1 Introduction ...... 34 10.1.2 NuttX structure ...... 34 10.1.3 Uploading ﬁrmware ...... 35 10.2 Creating a new application ...... 36 10.3 Adding Drivers ...... 41 10.3.1 Driver implementation ...... 41 10.4 How to use serial communication ...... 47 10.4.1 Menuconﬁg ...... 47

3 D2.1 Report on the reference hardware development platforms

10.4.2 Using serial at code ...... 48 10.5 How to use I2C ...... 49 10.5.1 Configuration ...... 49 10.5.2 Driver’s code ...... 49 10.5.3 Write ...... 50 10.5.4 Read ...... 51 10.6 How to use SD Card ...... 51 10.6.1 Using SD Card within an application ...... 52 10.7 How to use ADC ...... 52 10.7.1 Board initialization (Advance/Optional) ...... 52 10.7.2 Configuration ...... 53 10.7.3 ADC use under NuttX application (Beginner/Required) ...... 53 10.7.4 Debugging ...... 53 10.8 How to use UDP under 6LoWPAN ...... 53 10.8.1 NuttX Driver ...... 54 10.8.2 Board initialization ...... 54 10.8.3 NuttX configuration ...... 55 10.8.4 Application use ...... 57 10.8.5 Debugging ...... 57 10.9 Using SPI at driver level ...... 58 10.9.1 Hardware ...... 58 10.9.2 Driver ...... 58 10.9.3 Write functions ...... 58 10.9.4 Read functions ...... 59 10.9.5 Configuration function ...... 61 10.9.6 Initialization function ...... 61 10.9.7 NuttX configuration ...... 61 10.9.8 Application ...... 61 10.9.9 Debugging ...... 61

11 Appendix B: Running FreeRTOS 61

4 D2.1 Report on the reference hardware development platforms

Concept Description

Grant agreement no. 780785 Project acronym OFERA Project full title Open Framework for Embedded Robot Applications Dissemination level Public Date of delivery 30/06/2018 Deliverable number 2.1 Deliverable name Report on Reference Hardware Development platforms Keywords Microcontroller, ROS2, ROS, DDS, Robot, Open-Source Abstract The micro-ROS project aims to bring resource-constrained devices, such as microcontrollers, as first-class participants of the robot ecosystem. In particular, it aims to offer support to the Robot Operating System (ROS) on its second version: ROS 2.0. In an attempt to maximize the impact of our work, to concentrate and align our efforts, we will propose a set of Open Source and Open Hardware Reference hardware development platforms

5 D2.1 Report on the reference hardware development platforms

1 Introduction

1.1 Summary

In this document, we introduce and analyze hardware platforms that will be used to conduct research over this time. We also offer support for them as a consortium, during the duration of the project. The openness of these hardware platforms facilitates the adoption and reuse of our work. In addition, it enhances contributions and matches the existing philosophy of the ROS ecosystem. Firstly, hardware selection criteria are presented, stating the points we consider relevant for picking RHPDs. Sec- ondly, development platform candidates are introduced, showing their technical characteristics and stating why they could be appropriate for the project. Once the hardware platforms are presented, a preliminary selection is made. Then, validation work of the pre-selected board is described, explaining how we have obtained the data that has allowed us to validate candidates. After reasoning the chosen Reference Hardware Development Platforms, each platform development status under default RTOS is shown, describing, porting and testing the performed work. This development process fits with the technical requirements for micro-ROS devices we have detected in the project. Once the default platforms have been tested, we proceed to analyze additional RTOSes that complement the project. Under those new platforms, an analysis of the selected RHDPs is performed. We also present a novel approach that allows the use of ROS2 code under MCUs with the use of a modified ament tool-chain. This tool has been analyzed and tested. Additionally, we introduce a prove of concept using NuttX. Finally, we describe the work performed to support other partners in the use of hardware tools, explaining the resources that have been created to make the adoption and reuse of our work smooth. A final appendix includes relevant information about NuttX RTOS usage for developers, as it is thought to be beneficial.

1.2 Purpose of document

The document aims to provide an insight into the steps followed to test, validate and choose Reference Hardware Development Platform (RHDP) out of the candidate boards. It also describes the development performed under the default Real-Time Operating System (RTOS) for the RHDPs. In addition, it shows the side-work done testing material we consider of interest for the project.

1.3 Partners involved

Short Name Full Name Contribution

ALR Acutronic Link Robotics AG Leading author Bosch Robert Bosch GmbH RTOS analysis table, candidate-platform suggestion eProsima Proyectos y Sistemas de Document review Mantenimiento S.L. PIAP Industrial Institute for Document review Automation and Measurements

2 Acronyms and keywords

Term Deﬁnition

A Ampere

6 D2.1 Report on the reference hardware development platforms

Term Deﬁnition

ALU Arithmetic Unit Logic ADC Analog to Digital Converter CAN Control Area Network CPU Central Processing Unit DAC Digital to Analog Converter DDS Data Distribution Service DDS-XRCE DDS for Extremely Resource Constrained Environments GPIO General Purpose Input Output HAL Hardware Abstraction Layer I2C Inter-Integrated Circuit IoT Internet of the Things MCU Microcontroller Unit OMG Object Management Group PCB Printed Circuit Board RAM Random Access Memory RHDP Reference Hardware Development Platform RHDPs Reference Hardware Development Platforms ROS Robot Operating system RTOS Real-Time Operating System SPI Serial Peripheral Interface TCP Transmission Control Protocol UART Universal Asynchronous Receiver Transmitter UDP User Data Protocol WIP Work In Progress

3 Reference platform selection

This section provides insight into the process of selecting and validating the candidate boards. Firstly, selection criteria is presented, where we describe the characteristics we consider signiﬁcant. Secondly, we present a list of boards that were suggested to support from consortium partner side, describing their main speciﬁcations. Thirdly, board selection is made, introducing the major reasons to select them. Finally, validation of candidates is shown, checking their rightness under the project’s default RTOS.

3.1 Introduction

According to the proposal, the reference Real-Time Operating System (RTOS) for the project will be NuttX. While, theoretically, any board including a microcontroller could be selected, in most cases, supporting a new board (or even a new microcontroller) is a time-consuming action. Bearing this in mind and considering the limited time and funding available for the project, we have considered development boards that have, at least, some support for NuttX, simplifying and accelerating the adoption process.

7 D2.1 Report on the reference hardware development platforms

3.1.1 Architectural context

The original idea stated in the proposal of the project followed the architecture pictured below:

Figure 1: micro_ROS_layers

Where some layers would be candidates to be exchangeable in order to offer a flexible technical solution, this flexibility specially affects middleware, RTOS abstraction and RTOS layers.

3.2 Selection Criteria

The reference platforms should be representative, accessible and ﬂexible. With representative we mean that they should commonly be used for the targeted use cases and typical scenarios where micro-ROS devices use is desired. In particular, this includes:

• Memory and ﬂash capacity for running micro-ROS • Computational power • Input/output hardware • RTOS support (in particular NuttX)

Since a large number of boards would qualify as representative, we include accessibility as an additional criterion. With this, we mean that the board should:

• Be well documented • Be affordable • Support of open-source tools for development purposes • Be supported by a large community, for access to help • Not require expensive additional equipment (e.g., some boards require expensive tools for debugging or flashing) • Not use end-of-life electronic components • Be open-source, for maximum future proofing and adoption

And with ﬂexible we mean that, beyond the default architectural approach, it should also support other scenarios. Capabilities would include:

8 D2.1 Report on the reference hardware development platforms

• Enhancement capabilities, where additional interface access is given • Support for other popular RTOSes

3.3 Options

This section provides a list of candidates to be tested. The proposal already included three example boards, the Olimex STM32-E407, the STM32L1 Discovery, and the Hercules TM570 Launchpad. These have been pre-selected by partner ALR according to the criteria above, and are thus retained to be further considered. In addition, the other partners suggested additional hardware for consideration, because they intend to use them for speciﬁc demonstrations. These include the Bosch XDK110 (a development kit, including sensors and batteries), the DEVKIT-MPC5744P (a low-cost safety platform), and the Robotis OpenCR (the micro-controller platform of the ROS2 reference robot, Turtlebot3).

3.3.1 Olimex STM32-E407

Figure 2: Olimex STM32-E407 board

Olimex board is based on STM’s STM32F407ZGT6 part number. It contains 196KB of RAM, 1MB of ﬂash, and has a Cortex-M4F microcontroller architecture. It is a very complete board thanks to the big variety of communication interfaces it oﬀers: USB OTG, Ethernet, SD Card slot, SPI, CAN or I2C buses are exposed. The board contains various expansion options available: Arduino-like headers for attaching daughter boards, many pins exposed, as well as a UEXT connector. This connector is a custom pin-out bus and is used to attach sensor breakouts sensors that manufacturer sells. It is sold at a contained price (39.95€), and all the design resources are open at the manufacturer’s website.

9 D2.1 Report on the reference hardware development platforms

3.3.2 STM32L1 Discovery

Figure 3: STM32 L1 Discovery board

The STM32L1 Discovery Kit is an open hardware design, ultra low power and low-cost entry board for developing custom applications. It contains an STM32L152RCT6 Cortex-M3 microcontroller manufactured by ST Microelec- tronics. This part number contains 32KB of RAM and 256KB of ﬂash memory. It also includes an ST-Link in-circuit debugger that allows ﬂashing and debugging the target microcontroller. It is a cheap development board (the price is around 11€).

3.3.3 Hercules TMS570LS04x/03x LaunchPad Development Kit

Figure 4: TI Hercules LanuchPad board

The Hercules TMS570LS04 LaunchPad Development Kit is an inexpensive evaluation platform designed to help users

10 D2.1 Report on the reference hardware development platforms evaluate and get started on development with the Hercules microcontroller platform. The LaunchPad Development Kit is based on the IEC 61508 SIL 3 and ISO 26262 ASIL D certified TMS570LS0432, which is a dual-core lock-step ARM Cortex-R4 based MCU, that contains up to 32KB of RAM with 384KB of flash memory. The inclusion of the Cortex- Rseries within the micro ROS project would deliver a simplified path towards certified applications while reusing the same infrastructure. The manufacturer also offers development kit design files at no additional cost.

3.3.4 Bosch XDK110

Figure 5: Bosch XDK

The Bosch XDK110 is a complete IoT prototyping platform based on the Silicon Labs EFM32 (an ARM-Cortex M3 family chip), WiFi and Bluetooth Low Energy connectivity, a battery, and a user-interface with three status LEDs and two push-buttons. It includes a full sensor package, with accelerometer, gyroscope, magnetometer, humidity, temperature, air pressure, ambient light, and noise. The XDK itself is available for 195€, and a J-Link debugger (50€) is available as well. For development, the XDK110 also offers the XDK Workbench platform, an Eclipse-based integrated development environment. The XDK firmware is based on FreeRTOS, includes drivers for all sensors, and also supports TCP/IP, 6LowPan, encryption, etc. More information is available at http://xdk.io. Design files are not published.

3.3.5 DEVKIT-MPC5744P

Figure 6: MPC5744P Development Kit

The NXP MPC5744P is one of the most aﬀordable micro-controllers that is safety-rated for both automotive (ASIL) and industrial (SIL) applications. It is based on the MPC7544P MCU, using the e200 “PowerPC” architecture. The complete devkit costs 30€, and it does not need a JTAG adapter, due to its built-in OpenSDA interface. At volume, the MCU itself is less than 10€. The devkit has more than 100 GPIOs and onboard CAN, LIN, FlexRay or UART. It also provides Arduino- compatible extension pins.

11 D2.1 Report on the reference hardware development platforms

Figure 7: Robotis OpenCR compute-board

3.3.6 Robotis OpenCR 1.0

The Robotis OpenCR is the compute-board of the ROS2 reference robot, Turtlebot 3. It is based on the STM32F746GT6 ARM Cortex M7 MCU. Built-in are a 9-axis IMU sensor, and communication over USB (including host), TTl, RS485, UART and CAN. Most notably, it also includes power output pins for driving motors. Extension is through an Arduino-compatible pin layout. It is also completely open source, with layouts and schematics available at https://github.com/ROBOTIS-GIT/OpenCR-Hardware. The price is approximately 150€, if bought separately from the Turtlebot3.

3.4 Selection

All of the mentioned boards are relevant for the project, but concerning the reference platforms, the main deciding factor is representativeness: If representativeness can be achieved using fewer platforms, this should be done to conserve effort for other, more innovative activities. Moreover, since the reference boards will receive the complete micro-ROS package, existing NuttX support would drastically reduce effort. For the Olimex STM32 E407 and the STM32L1 Discovery boards, basic NuttX support is already present, and project-work can be limited to validation and supporting additional sensors and communication devices. Moreover, these boards are relatively inexpensive and thus, suitable for a wide-range of users. Therefore, the consortium has decided to focus the support on the STM32-E407 and the STM32L1-DISCOVERY. In terms of representativeness, these boards are not safety-certified, being this a potential missing issue. However, the proposal originally excluded safety from the scope, because it would mean considerable additional effort. Therefore, any step towards safety is already beyond what was originally promised, even without full support as a reference board. Therefore, the consortium has decided that using a modular approach, based on the integration of parts of micro-ROS with existing safety-rated software, would provide the optimal cost-benefit ratio. The other considered platforms will be retained as demonstrator platforms for specific use cases, but will not receive full support. Validation for them is solely based on the manufacturers specifications.

12 D2.1 Report on the reference hardware development platforms

4 Reference platform validation

Once a pre-selection of the boards is made, validation work has been performed. We have proceeded to check the development status of each board under NuttX. At a first stage, we have proceeded to run a basic functionality, using NuttX RTOS shell as test. Once we have checked this basic example was working right, we have proceeded to test additional features, trying to emulate the resources typical micro-ROS components will require. This implies verifying different communication protocols - means of communication between microcontrollers - sensors/actuators (I2C, UART, SPI buses), microcontrollers - microprocessors/controllers (wired/wireless communications)-, basic console access for debugging/introspection, power saving routines or data logging methods, like SD Card. Additionally, we have added/ported sensor drivers to make an estimation of the memory resources required for communicating to these devices. As a preliminary version of Micro RTPS middleware was given previous the deliverable, we have also made an effort to get a first idea of the amount of resources it consumes. This allows us to estimate if the RAM capabilities of the boards suffice to run a minimal micro-ROS functionality. Obviously, running firmware that just contains test code is not an example of what a micro-ROS device will require at normal operation. For example, if a simple sensor wants to be a micro-ROS participant, it would require means of communication with the DDS-XRCE agent using a DDS-XRCE client, requiring wired or wireless communication capabilities. Additionally, it also needs to run an appropriate driver to fetch sensor data and process it. This aspect needs to be taken into account. Ideally, from a consumption perspective, the firmware would need to manage microcontroller resources to achieve a better power performance. We have taken into account this requirement at the validation stage and performed a test to see its behavior.

4.1 Olimex LTD STM32-E407

4.1.1 Introduction

As stated previously, this board (from now on Olimex) has a rich communication interface. Thanks to this characteristic, it could be deployed under diﬀerent scenarios. Besides, as it embeds 1 MB of Flash and 196 KB of RAM, it oﬀers a good capability to run complete micro-ROS stack. The many board-to-board pins and connectors that are available in the PCB allow plugging Arduino shields and also the connection of extension boards sold by the board manufacturer. This permits the attachment of new sensors at the microcontroller buses and enhances the possibility of adding sensors on demand. The next image shows an example of these expansion boards:

Figure 8: UEXT sensor break-out

13 D2.1 Report on the reference hardware development platforms

This would allow creating many examples for developers, explaining the use and implementation of micro-ROS and decreasing the required learning curve to adopt it.

4.1.2 Memory usage

One of the main problems running complex software in microcontrollers is the restricted amount of RAM memory these chips embed. This is a resource to be monitored during the project. The ambition of using DDS under microcontrollers, thanks to the use of the standard DDS-XRCE (DDS Extremely Resource Constrained Environment), opens new possibilities to integrate them into a micro-processor dominating landscape. This new type of DDS implementation, is a standard promoted by the OMG standard consortium.um. In order to see to what extent candidate boards are capable of running the software we intend, RAM tests have been done using a RAM monitor under NuttX. The application is able to monitor three main variables: CPU load, the free RAM left and the current consumption value. This last allows to estimate the power consumption of the board. As consortium member eProsima has made an early stage release of Micro RTPS middleware, a preliminary test has been done including the DDS-XRCE middleware as a NuttX application. This shows that the preliminary Micro RTPS client delivered by eProsima used in NuttX, consumes around 86KB RAM. As the board contains 196KBs of RAM, there should be enough space left to add the rest of the software. Furthermore, the size of the ﬁrmware including DDS-XCRE client code is expected to be optimized dramatically, as the compiled code is an early stage version. Considering the amount of RAM is available, use of native 6LowPAN could be considered, as it takes almost 45KB of RAM. The following table shows the results we have obtained running various applications in NuttX under this candidate board. In all scenarios shown below, NuttX shell is active to have means of communication among the board and a computer used by the tester.

Total RAM Flash Static RAM Heap RAM Usage % of Free RAM

NSH 64Kb 3.6KB 7.4KB 11KB 94% Ethernet + 128KB 21,4 KB 21KB 42,4KB 78% UDP Client Ethernet + 128KB 21,4KB 21KB 42,4KB 78% UDP Server Radio + 128KB 10.3KB 19.9KB 30.2KB 84% 802.15.4 Radio + 256KB 20KB 25.5KB 45.5KB 76% 6lowpan + UDP Client Radio + 256kB 20KB 28.6KB 48.6KB 75% 6lowpan + UDP Server Sensor + 128KB 67.9KB 14.2KB 82.1KB 58% Telemetry Current Sensor 64KB 3.5KB 7.5KB 11KB 94% INA219 through I2C Second UART 64KB 4KB 10.4KB 14.4KB 93% Micro RTPS 128KB 11.8KB 74.4KB 85.5KB 55% with Serial + NSH

This table shows diﬀerent possible conﬁgurations or features a micro-ROS board could have. We have made tests to

14 D2.1 Report on the reference hardware development platforms evaluate the amount of resources communication protocols demand and which is the RAM size required for running simpler software, typically sensor communication examples, that contain a basic data processing. Referring to the tables’ number, we can conclude that this board should be able to run full micro-ROS stack, where DDS-XRCE middleware client is running, and wireless communication handling is performed. This board should also be able to use all means of communication, so it adapts easily to the requirements of various scenarios.

4.1.3 Power Consumption Measurements

This second test allows having an intuition of the power the board needs to run the applications shown above. Making an active use of NuttX power manager (explained at development section), we have tested the amount of power we could save at the Olimex board by using diﬀerent applications. These are the results we have obtained:

No PM PM Normal mode PM StandBy mode

NSH console 103 mA 100 mA 72 mA Ethernet + TCP Server 149 mA 140 mA 112 mA Radio + 6lowpan + 116 mA 150 mA 95 mA UDP Client Sensor (HIH6130) 108 mA 100 mA 75 mA Secondary UART 105 mA 100 mA 75 mA

The values shown above are mean values, an oscillation in the power consumption is always present. We can conclude that the amount of power saved is close to the %30 of a normal operation mode comparing to the standby mode, which is a signiﬁcant amount.

4.2 5.2 STM32L1 Discovery

4.2.1 Introduction

This board contains a Cortex M3, 256KB of Flash and 32 KB of RAM and it is encapsulated in a new low leaking package that allows to have a much lower power consumption than regular STM32F1 family devices. One of the main issues while validating the board was the problem of accessing the whole RAM range, as we could not access the top 16KB. With this restriction, the board was not able to run many useful examples under NuttX. Once this issue was solved, we proceeded to compile and see which features are able to fit in such a constrained microcontroller. In order to obtain power profiles, we ported the power manager to the board. We observed that the implementation power consumption oscillates more than in the Olimex board. We believe that this happens because the power management is strongly dependent on the board configuration and management. Regarding these aspects, we can say that the matureness of the manager is bigger on the Olimex board and that a closer look needs to be put at the L1 implementation.

4.2.2 Memory usage

Memory usage has been calculated porting the same applications we have run under Olimex board, bringing some light to the RAM usage of the L1. Our first impression was that, as the board contains just 32KBs of RAM, it would struggle to run heavy firmware, like communication stacks. That is why we have thought that Micro RTPS should fit using only serial communication, not using the 6LOWPAN communication stack, due to the fact that it is presumingly heavy.

15 D2.1 Report on the reference hardware development platforms

The next table shows the RAM usage measurement we have obtained under the STM-L1 Discovery board. All the examples stated below contain a NuttX shell attached to a serial console.

Total RAM Flash Static RAM Heap RAM Usage % of Free RAM

Primary UART 36KB 18.5KB 4.1KB 22.6KB 30% with NSH Current Sensor 48KB 18.5KB 4.2KB 23.6KB 26,5% INA219 through I2C Secondary 12.9KB 19KB 6.3KB 25.3KB 21% UART Secondary 52 KB 19KB 6.6KB 25.6KB 20% UART + Current Sensor INA219 through I2C

As we can see, these low-resource board limitations are shown in the table. Notice that these tests have been done with no optimization of NuttX. This means that we consider we could obtain better numbers if non-used NuttX features were disabled. As an example of these pending optimizations, we could disable several NuttX shell commands. In addition to the tests shown in the table, we have also made an effort to support eProsima’s Micro RTPS, achieving a first running prototype of a Micro RTPS client. This first prototype encountered problems, but after some modifications, it looks to be fully functional. In order to save as much space as possible, eProsima is actively working on improving this first approach of the middleware, and Acutronic will continue giving support and testing the code in order to optimize it. As a first test, we consider it promising to already have an early prototype of Micro RTPS usage under this ultra-low resource microcontroller.

4.2.3 Power Consumption

One of the reasons why we have chosen this board as a device under test is to determine the amount of power we could save by using an ultra-low resource microcontroller instead of a medium resource device. Thanks to the use of NuttX power management, we intend to decrease and better control the amount of power the board requires. These are the results of some tests we have performed:

No PM PM Normal mode PM StandBy mode

NSH console 66 mA 59 mA 53 mA Sensor(HIH6130) 68 mA 61 mA 55 mA Second UART 66 mA 59 mA 53 mA

Comparing to the Olimex board, numbers show a considerable amount of power saving. Reviewing those numbers, we can see that the amount of power saved in the STM32 L1 Discovery board is around %35 on average for all the tested cases. So we can state that, for use-cases where power saving is relevant, the L1 would be a good ﬁt. We can also observe that the power saving is not big when the board enters into diﬀerent power states. Again, this is due to the fact that the power manager at this board needs a review. Once the manager is working right, we expect to obtain power saving percentages that are closer to the ones we have observed at the Olimex board Checking the schematics of the STM32 L1 board, we can see that the main debug/communication port of the platform is another STM32F1 chip that is always on. This chip is attached to the USB port and acts as an interface

16 D2.1 Report on the reference hardware development platforms when the user wants to ﬂash the STM L1 memory. When the power manager puts into low consumption the L1 device, the F1 chip keeps running, letting the user to communicate with the target device. We think that these chips could be also a source of considerable power drawn, so, in reality, the STM L1 chip and its peripheral electronics are consuming even less power than what we have presented in the table. Unfortunately, we do not see any obvious procedure for turning oﬀ the interface chip, as it is attached to a 3.3 volt source.

4.3 TI Hercules LaunchPad TMS57004

Texas Instrument low-cost development kit is intended to be used under custom safety applications. The microcontroller’s architecture is a Cortex-R4 which has functional safety as it is based on IEC 61508 SIL 3 and ISO 26262 ASIL D certifications. It contains up to 32KB of RAM with 384KB of Flash memory. One of the main inconveniences of using this board is its complex memory structure. This is a drawback, because it is not being completely ported to NuttX and its development is frozen. It has a basic support that allows to set-up the tool-chain to fit to its Cortex-R architecture. The flashing tools also allow loading compiled binaries to the flash. Unfortunately, NuttX shell is not ported rightly and does not work as in the other platforms. Taking into account that the NuttX support is very limited for this board and the development is frozen, and that the resources the board offers in terms of RAM and flash are similar to the STM L1, we have decided to halt the support of this board at the moment.

5 Reference Hardware Development Platform selection

Once the tests were performed, we continued deciding which candidate boards were the most appropriate. Reviewing the ported features and the RAM measurements done under the Olimex board, we can conclude that this board could be used to run typical full micro-ROS stack. The scenario could require the use of UDP or serial communication, under a wired or wireless medium. We have validated this cases using UDP client and server under 6LOWPAN wireless communication, Ethernet communications and simple UART communication. We have also validated that it is capable to run Micro RTPS client using a serial port. Additionally, we have run several sensor drivers and performed power saving tests. Furthermore, it is an inexpensive board (around 40€), a fact which we consider appealing for developers that would like to test micro-ROS technology. The design files are open, enabling rapid adoption of the technology by manufacturers and matching the philosophy of openness this project brings. This device is typically used under consumer electronic devices, specially in the fields of IoT, motor control applications, appliances or home automation, where real-time determinism is required. This satisfies the desire of supporting popular devices that are going to be accepted in the technical community. Finally, regarding the possible end-of-life of the product, the manufacturer assures its commercialization for another 10 years, due to its attachment to an internal longevity program. Thanks to its low power consumption, this board could be held as the reference platform for robot components in which the data treatment is small, and communications are of few bytes. Robot devices made out of this part could enhance the portability and size using a battery and a minimal hardware collection. Sensors are a good candidate for this scenario, such as temperature, barometric or light sensors. Another positive side of using this board is that the STM L1 family has different part numbers that contain a range of flash and RAM sizes. In case Micro RTPS and additional drivers use could not fit the RAM or flash memory, we could switch to a more powerful part number, not disturbing the development, due to the fact that they are very similar in terms of architecture and use. This would enhance the use of extremely low-resource MCU use under micro-ROS. Analyzing the non-technical properties of the board, the first thing to notice is that it is a cheap board, requiring an investment of around 11€, which makes it accessible for audiences that are sensible to the price. In the same way as the Olimex board, the design files open and the board is used in the same markets (IoT, motor control applications, appliances or home automation), making it a popular device. It also shares the same end-of-life specifications, that will end in the year 2028. Even if the certification possibility is appealing in the Hercules board, due to its limited NuttX support, the effort that it would require to support it is big. Additionally, the RAM size is the same as the L1, making no significant

17 D2.1 Report on the reference hardware development platforms difference in terms of usage. We could see that the support of the board in the preferred RTOS is rather small, facing a big barrier in its usage under the project. Even if the certification possibility is appealing in the Hercules board, due to its limited NuttX support, the effort that would require to support it is big. Additionally, the RAM size is the same as the L1, making no significant difference in terms of usage. We could see that the support of the board in the preferred RTOS is rather small, facing a big barrier in its usage under the project. From the cost side, this board is an accessible one due to its reduced price (around 17€). Moreover, it aims to satisfy the need of industrial automation, automotive, medical or defense applications thanks to the certifications the chip holds. In terms of longevity, there is no statement of Texas Instruments, but it is believed that, typically, the company offers a minimum life-cycle of 10 years. As the product launch was made back in 2012, production could be ensured at least until 2022. The board’s design is open, offering the schematics as a PDF file. The following table summarizes these ideas:

Olimex LTD Concept STM32-E407 STM32L1 Discovery TI Hercules LaunchPad

Open source Yes Yes Yes hardware platform Price (estimated) 40€ 11€ 17€ End-of-life Minimum until 2028 Minimum until 2028 Not stated Communication Ethernet, SPI, UART, SPI, UART, I2C, SPI, UART, CAN, I2C, CAN, SDIO, GPIO, CAN, GPIO, ADC, USB GPIO, ADC ADC/DAC Popularity IoT, motor control IoT, motor control medical, automotive, applications, applications, appliances, home appliances, home industry, defense automation automation Boards NuttX support Advanced Advanced Early stages & frozen

To summarize, according to the research our group performed, we select the following Reference Hardware Develop- ment Platforms (RHDP) for the development of the project:

• Olimex LTD STM32-E407 • STM32L1 Discovery

6 Reference Hardware Development Platform development

Having selected and validated the RHDPs, the next logical step is to further develop these platforms, assessing their status at different levels and adjusting the RTOS and the hardware configurations to meet the project requirements. This section will dive into the development that our team executed on the two RHDPs. All the development work described in this section fits into functional requirements the consortium has depicted for micro-ROS, helping to fulfill, as much as possible, these objectives from the beginning of the project. For instance, the power manager fits into the desire of having tight control of the device consumption defining different power saving states. Moreover, the future work at hardware side will also continue granting new functionalities, so they can be used under micro-ROS. The following table shows, at a glance, the state of the development we have performed in each board while we were evaluating them:

18 D2.1 Report on the reference hardware development platforms

Feature / Board Olimex STM32-L1

NuttX working x x Terminal console x x I2C x x SPI x x UART x x CAN W.I.P. W.I.P. GPIO x x ADC x W.I.P. Ethernet x - Zigbee x x 802.15.4 x x 6LowPAN x - SD card x - Current Sensor INA219 through x - I2C Power Management x x Ported, under test

It is important to notice that the work showed above is contained in the GitHub repositories were NuttX source code is placed. All the work related to supporting new features and developing or ﬁxing the code is done at these public repositories. This work is complementary to the noticeable amount of supported drivers NuttX already has. The list is available in this link

6.1 General development resources

In order to understand the value of the work performed supporting features in the boards - shown in the table above-, a short explanation of each functionality is explained.

6.1.1 NuttX shell

NuttX shell is comparable to the Linux shell. It allows having an interface between NuttX running microcontroller and the user. It allows executing commands that are identical to Linux in many cases. Commands like ls, cp or executing binaries are possible thanks to nsh, the NuttX shell. This utile is going to match needs of diagnostic deﬁned at functional requirements for micro-ROS devices. It would allow to have a tool for communicating and debugging micro-ROS devices. Ideally, this diagnostic tool should scale up to user API, allowing high abstraction debugging.

6.1.2 GPIO

NuttX provides basic handling of microcontroller’s GPIO in a Linux fancy way. Each GPIO can be registered with the GPIO driver and allows to control it using open(), close(), read() and write() commands. Additionally, it allows a lower level control of the GPIO, setting pull-up resistor conﬁguration, interruption set-up or controlling the switching frequency of the GPIO.

19 D2.1 Report on the reference hardware development platforms

6.1.3 I2C

Allows the use of I2C bus with speciﬁc driver calls, using i2c_read() and i2c_write() commands. The driver of the device which is connected to I2C requires to use this driver calls in its implementation.

6.1.4 SPI

Same as I2C, speciﬁc SPI driver calls allow the application to get access to the bus and interact to devices that are connected to it.

6.1.5 UART

The use of UART is Linux like. The serial ports are located in the ﬁle system, under /dev/ttySX or /dev/ttyACMX for USB devices (where X is a number). Normally the number 0 is the console, and the rest of the ports are additional. In order to operate with this interface open(), close(), read() and write() commands are used.

6.1.6 ADC

Mapped under the ﬁle system, ADC calls can be made at the same way as UART or GPIO using open(), close() and read() commands. This calls can be even made at nsh, the NuttX shell.

6.1.7 SD Card

With the same treatment as ADC and UART buses, it allows mounting storage devices and the writing/reading of ﬁles under storage units. It requires mounting the ﬁle system previous to its usage.

6.1.8 Ethernet

Thanks to the Ethernet driver, network communication is possible, granting Internet or LAN access to MCU. It allows using UDP/TCP-IP server/client, SSH and Telnet sessions. The use of Ethernet connections is made using sockets at the application layer, very similar to Linux sockets.

6.1.9 802.15.4 protocol support

The MRF24J40 module has been used under the Olimex board for supporting wireless communication. The ad- vantage of using this chip is that NuttX has preliminary support for the latest wireless communication protocols. Thanks to the MRF24J40 and communication layer drivers, we have been able to run the 802.15.04 network stack under the microcontroller and having a point to point communication

6.1.10 6LOWPAN protocol support

Continuing the work done with the 802.15.04, we have been able to add on top of this transport layer the 6LOWPAN layer, fully running under NuttX. This test validates the implementation of this wireless technology using UDP and TCP protocols, using client-server architecture. As the 6LowPan wireless stack is a heavy piece of code, the RAM size of the STM L1 does not allow running it. To solve this, we consider the use of Zigbee modules under serial communication. More information under the Zigbee section.

20 D2.1 Report on the reference hardware development platforms

Figure 9: MRF24J40 break-out module

6.1.11 Zigbee protocol use

Another method of supporting wireless communication is using serial communication between the microcontroller and a Zigbee protocol based Xbee module. The Zigbee protocol is a proprietary protocol only group members can access. All network related complexity is abstracted under Xbee modules, and this allows the use of wireless communication under resource-constrained devices, which is beneﬁcial to the STML1 Discovery board. This way, using a simple serial or SPI communication, a complex communication protocol could be used under ultra-low resource microcontrollers, allowing them to be part of a bigger and more complex ecosystem. We have tested this kind of communications using a Xbee module under the STM32 L1 Discovery board.

Figure 10: Xbee module

6.1.12 Power Consumption and Management

One of the main advantages of using microcontrollers comparing to microprocessors is that the ﬁrst require a much lower amount of power to operate. This feature has been shaped in the morphological box (see Requirements

21 D2.1 Report on the reference hardware development platforms deliverable, section 4.2) and power management proﬁles have arisen during technical discussion. In order to tackle this, the NuttX power manager has been ported to the development boards. As a preliminary test, we have performed current readings to determine the required power for each development board and tried to apply power saving methods using the power manager

6.1.12.1 NuttX Power Manager This capability can be done thanks to the use of the NuttX power manager, that allows putting into practice the dynamic configuration of MCU, for power saving purposes. The NuttX power consumption management is implemented in two levels. At OS level, it contains a state-machine that takes control of the resources that are available at the board, for example, turning off microcontroller resources or lowering clock speeds. The second level means implementating power saving at the driver side. This contemplates the resource control depending on on which state the driver is, letting the developer to make the implementation of the saving at the driver side. For example, if a driver implements a wireless communication, it means that, at a idle state, it should behave normally. The power saving states would take actions to use this resource restrictively in order to save power. This actions could put into sleep the package, receive/send for some time or just make certain message polling once per a considerable amount of time. The power management state-machine has four different modes:

• PM Normal

This mode is the normal state of the MCU, having none-reduction of consumption. In this mode, the MCU runs at maximum frequency and has every peripheral activated. There is no modiﬁcation in the drivers, having a regular behavior.

• PM Idle

If the machine detects that the MCU is doing nothing relevant, it changes to this state, where the MCU continues working at full performance, and the consumption improvement is done at device driver level. Screen brightness decrease or increasing acquisition time from a sensor are some examples of changes which lead to driver level modiﬁcations. The developer needs to identify and code the actions should perform to bring MCU back to its normal/default state..

• PM Standby

This state decreases MCU frequency and also allows the user to turn oﬀ some peripheral (i.e. UART or SPI buses). The state-machine only supports hardware and timer interruptions to wake up the microcontroller for applying recovery actions. This recovery requires some time (this is board dependent, it also depends on the resources to wake again up. The maximum timing observed is around 500 milliseconds) to put the board again fully functional. The developer must notice that some packages could be lost in the communication, leading to the need of sending data twice.

• PM Sleep

This state halts the MCU and disables peripherals. The only way to wake up again partially the MCU is enabling an internal alarm at a deﬁned time. To have a complete recovery, it’s necessary to reset the board. This mode is optional. For more information please visit this site that explains in depth how power manager works.

6.2 RHDP development: Olimex LTD STM32-E407

A significant amount of effort has been put in bringing this board to its full capabilities using NuttX, as it offers many interesting means of communication. This has provided a set of test/examples as an outcome, taking inspiration out of the partners’ use-cases and architecture outlines. It has been made adapting and supporting NuttX board’s default build, intending to support derived technical requirements. In the list below, a comparison of the board’s features is made, contrasting the status before the start of the project with the status at deliverable redaction:

22 D2.1 Report on the reference hardware development platforms

Start Status Actual Status

Implemented Notes Implemented Notes NSH Console Yes Fully Functional Yes Fully Functional GPIO manual No - Yes Fully Functional control I2C No - Yes Fully Functional SPI No - Yes Fully Functional UART Yes Support for various Yes Fully Functional UART (Support for various UART) ADC No - Yes Fully Functional DAC No - No - PWM Yes - Yes Fully Functional SDIO(SD Card Partially Implemented in Yes Performance Support) equivalent model improvement required Ethernet Yes Give the possibility Yes TCP-IP(Client/ to use a telnet Server),Telnet and console UDP (Client/Server ) partially functional Radio + 802.15.4. No - Yes Fully Functional Radio + 6lowpan No - Yes Works with UDP(Client/Ser ver) and TCP/IP(Client/ Server) CAN No - Partially WIP Power No - Yes Speciﬁc to each Management microcontrolle r part number

In addition to this table, several sensors have been tested under this board. These have been used to test out many of the bus drivers and also to measure the amount of RAM resource NuttX requires to use. Some of them are:

• BMP180 (I2C Bus): Humidity/temperature sensor that was used to bring up the I2C bus. This port was simple due to its popularity. • HIH6130 (I2C Bus): Humidity/temperature sensor that was used to write content for development guide. • INA219 (I2C Bus): Current measurement sensor, utilized in the telemetry app. • MRF522 (SPI BUS): RFID reader, which we use to bring up and test the SPI bus. • MRF24j40 (SPI BUS): Radio breakout board used for 6LowPan communication. • Xbee S2C (SPI BUS /UART): Alternative board to use Zigbee protocol instead of 6LowPan.

As stated at Reference platform validation section, we have used an application that allows the measurement of the power consumption, CPU load and free RAM. This application is also part of the development work performed.

23 D2.1 Report on the reference hardware development platforms

6.3 RHDP development: STML1 Discovery

In the same way, we have improved the state of support of the Olimex board under NuttX, we have invested time to develop STM32L1 Discovery board. In the following list you can see the features available in the board before the start of the project faced with the actual status:

Start Status Actual Status

Implemented Notes Implemented Notes NSH Console Yes Fully Functional Yes Fully Functional GPIO manual No - Yes Fully Functional control I2C No - Yes Fully Functional SPI No - Yes Fully Functional UART Yes Support for various Yes Fully Functional UART (Support for various UART) ADC No - No WIP DAC No - No - PWM Yes Yes Fully Functional SDIO(SD Card No This uController - - Support) doesn’t have this peripheral Ethernet No This uController - - doesn’t have this peripheral Radio + 802.15.4. No - Yes Fully Functional, sending and receiving messages Radio + 6lowpan No - No Insuﬃcient SRAM memory CAN No - Partially WIP Power No - First port Requires review Management and optimization

Comparing table content, we can see that many buses were not ported at the start of the project. We have added support for GPIO, I2C and SPI as well as made a first port of the power manager. This feature requires a closer look due to the fact that we have seen fluctuations when it is running. For testing purposes, we have also ported the resource monitoring application that enables the measurement of data that has allowed us making the validation process. This application is the same as the one run under the Olimex board. In terms of wireless protocols, the 802.15.4 layer has been ported. Unfortunately, we have tried adding the 6LOW- PAN application layer on top of it, but it does not fit in the board’s RAM. For this reason, the use of Xbee modules has been contemplated. A nice feature of this board is that Xbee modules allow meshing, where several micro-ROS devices could reach each other. In order to abstract this feature, development of Xbee drivers is contemplated, aiming to simplify its use under the project. The sensors described at the Olimex board are also able to run under this board, not requiring board specific changes.

24 D2.1 Report on the reference hardware development platforms

7 RTOS analysis

During the first months of the project, we have proceeded to make an analysis of additional RTOSes. As the proposed stack approach is modular, the exchange of RTOSes is contemplated offering a flexible technical solution. This section aims to explain the peculiarities RTOSes have in a generalist approach. Furthermore, a technical comparison of a handful RTOSes is made in it, and we discuss the benefits the use of some of them could have for the project.

7.1 Microcontroller RTOS overview

One of the attributes that differentiate RTOSes among each other is the lack of consensus on the API definition. Some RTOSes overcome this weakness by using POSIX-like APIs, implementing them natively or using wrappers on top of it. Another difference is that the support of communication buses and protocols is very different among RTOSes. Additionally, some of them lack file-systems or even have a threading implementation that takes different approaches. Another characteristic these RTOSes share is that they are really target oriented. This affects the support of complete architectures or vendor chips, having a landscape where the backing of MCUs is very fragmented. This situation makes it difficult to use of the same development boards under different RTOSes. We consider this last point as vital, due to the fact that, one of the main works this project is going to perform is the technical evaluation of micro-ROS devices using test-benches (under Work Package 5). Ideally, we would like to achieve the scenario where we use the same RHDPs, where the usage of different RTOSes is possible. As there are many singularities, a comparison table was made below. It displays the technical characteristics, as well as relevant non-technical information, such as certification and software licenses. The table is ordered putting the default RTOS first and adding existing popular RTOSes afterwards.