Everybody got their Google “glasses”.

Two weeks ago I visited the 2016 edition of the European Maker Faire in Rome.

The Rome fair can be reached easily with the train that goes between Rome center (mostly Tiburtina station) and the airport of Fiumicino. The whole fair has ten pavilions, and the Maker Faire managed to fill six of them with all kinds of exhibitors, stands, shops and conference rooms.

Each of the pavilions had a theme:

• 5: Move: it contained the drone arena and mostly robots.
• 6: Life: solutions for the environment and health.
• 7: Interaction: Electronics, IoT, home automation, virtual reality.
• 8: Fabrication: mostly 3D printing.
• 9: Young makers: everything to inspire curiosity into kids and enable them to become makers.
• 10: Short-circuits: this pavilion has big conference rooms for big talks.

The drone arena.

I spent the first day exploring all the stands and the exhibitions. There were two kinds of stands: blue for enthusiasts and red for businesses and associations.

The finals for the R.O.M.E. prize.

The faire hosted a competition called R.O.M.E. Prize, where the invention with the most social impact would win 100.000EUR in funding. The winner was a glove that translated sign language into words, called “Talking Hands”. Some of the other projects were, such as a 3D-printed incubator for newborn babies, or a smart toothbrush. Other were more curious, such as a toy for dogs that can be controlled by an app.

This competitor tries to answer the question: Where is my jetpack?

Bautiful box: play with your dog from the Internet.

3D printing was everywhere. There was an enormous printer from WASP that could extrude entire houses. There were metal printers, professional printers, portable, triangular, and so on. I attended a talk from Olivetti about their printers for industry and for education.

PivotMaker, one of the biggest 3D printers at the faire.

Metal 3D printing.

Robotics played a big part of the exhibitions, with autonomous vehicles, humanoid robots and drones.

RoboSec Panther.

The One Love Machine band.

The stands were full of ideas for the Internet of Things. Home automation such as the Casa Jasmina, smart plug from PoWaHome, and µPanel, a common web interface for all the sensors and actuator at home; wearable electronics, social gardening such as CloudGarden, hardware platforms such as UDOO or Fishino. I also attended a talk given by Marco d’Itri called “The Internet of other people’s things” on the dangers of connecting everything, in terms of reduced functionality (when the servers go offline or the companies discontinue the products), when you are giving away your sensitive data for free, and when malicious hackers can exploit weaknesses to perform cyber attacks and steal information.

This dragon roars on tweets with particular hashtags.

All in all, it has been a wonderful weekend, and the faire really gave the makers the opportunity to share their work, exchange ideas, build connections and leap forward.

Maker Faire will come to Rome in the weekend of 14-15-16 October 2016, and I plan to go there.

The faire format is  by Make Magazine, and gathers the makers from all around the globe, so that they have the possibility to interact and showcase their work and their art.

The maker movement has gained traction these years thanks to numerous factors. Some of these are technological, such as 3D printing, microcontroller boards such as Arduino and Nucleo, connectivity protocols at the base of the Internet of Things. Some of these are social: people have always made their own creation in the solitude of their own home, in their room full of screws, drills, saws and dust. Now there are so many ways to ask for suggestions and to share.

I hope it will be a fun weekend!

The instructor entices the learner by showing a famous real-time system failure, during the landing of the Apollo 11 on the surface of the Moon. The course then sets the objective to teach to design a real-time system so that every deadline is always respected.

In a further note, it claims that of all computing systems in the world, about 98% are embedded systems, and most of them are real-time systems. This information alone gives a pretty clear idea of the relevance of the topic in the modern industry.

The course makes use of FreeRTOS as a platform to implement the theories that are presented in the various lessons.

Coursera: Development of Real-Time Systems

Hardware

The Ethernet shield is a board with Arduino common connectors, an Ethernet port, a Wiznet chip (mine has W5100) and a microSD card slot. Both the Wiznet chip and the SD card are connected to the microcontroller with an SPI bus. The two targets have two different “chip select” signals connected to them, so that the microcontroller can choose which one to control. The SPI signals that go to the SD card are also reduced in voltage by resistive partitors, so that the 5V I/O pins of the Arduino Atmel chip can drive the 3.3V interface of SD cards. The STM32 microcontroller on the Nucleo board instead has 3.3V I/Os, so the same resistors will bring the voltage levels to around 2.2V; turns out this is enough to drive the SD card interface correctly. Note that for the Nucleo to adapt to the Ethernet shield I had to route three wires from the ICSP connector to the commmon Arduino connectors to bring the SPI signals to the correct places. This is explained in a previous blog post “Arduino Ethernet shield on STM32 Nucleo“, summarizing the wiring is:

• MISO: pin 1 of the ICSP to pin 12 of the Arduino connector,
• SCK: pin 3 of the ICSP to pin 13 of the Arduino connector,
• MOSI: pin 4 of the ICSP to pin 11 of the Arduino connector.

Nucleo board wired with Ethernet shield.

Software stack

My goal is to use functions like fopen, fprintf and fscanf to access the SD card content, and the solution that I implemented is shown in the picture below. It’s a stack of libraries that talk to each other; some of them were already developed, some of them I made them myself (the colored boxes) to glue together the parts. I’m going to explain them from top to bottom.

Software stack to access SD card filesystem with C standard I/O functions.

Main program and C standard library

When anybody learns C, they make use of standard functions to access files. I wanted to write a solution that lets the same C program be compiled on something like a Linux system and also on a microcontroller such as STM32. The program should be compiled using a different toolchain, and should link different libraries. For the STM32, the toolchain that I used is GCC ARM Embedded for Cortex-M microprocessors. This toolchain provides the C standard library functions by the newlib library. This library implements the functionalities that can be found in “stdio.h” and other headers, and it is optimized for small systems. The low-level part of the newlib implementation resides on Linux-like system calls such as _open and _write. For example, when fopen is called by the main program, ultimately newlib calls the _open function.

System calls and FAT filesystem

In my case I don’t have an operating system running on STM32: the code runs on bare metal. For this reason, I had to develop these system calls myself. These system calls must provide ways to manage the file descriptors that are returned by _open and passed to functions such as _write to identify the file that should be accessed. So there are structure in this part of the stack that contain all the information needed to manage an open file, such as the access mode (read/write). I decided to write this part of the system following POSIX specifications, from the function prototype to the behavior and the error codes. In this way I didn’t have to invent anything and users might be more familiar with the way the code is working. With the same approach I also implemented some functions to manage directories, such as mkdir and readdir.

When a file needs to be opened or its data need to be read or written, a filesystem is needed. The filesystem itself has the role of organizing the files on a disk. An SD card does not have the concept of files, it’s a contiguous memory space that can be read or written. It’s the filesystem that writes tables and pointers on this memory to implement the hierarchy of directories and their content. I selected FatFS, a library that manages FAT filesystems, because it works independently of the hardware or the operating system, and it’s exactly what I needed to transform the system calls to file system access. Specifically I am using version 0.11a at the time of my development. In fact, much of FatFS API is very similar to system calls, with functions like f_open that accept the same parameters (to some extent) as fopen and _open. My system calls in most cases just need to translate the input parameters, call the FatFS API and then translate the result and the return value. FAT is common for SD cards and it is supported by most operating systems such as Linux and Windows natively and for a long time. It has disadvantages such as the absence of links to files, but it is a trade-off for its simplicity. FatFS can be configured with a simple header, for example the filesystem can be configured as read-only to reduce the footprint of the library that won’t need the write functions anymore; as another example, the filenames can be restricted to be the classic 8 characters of file name and 3 characters of file extension.

Disk I/O and SPI communication

FatFS implements the FAT filesystem but needs an underlying layer to manage the actual hardware access as disk I/O. Each filesystem access is translated to an action that reads the disk or writes the disk, so there are low-level functions called disk_read and disk_write that must be provided. I had to write this code that specifically accesses SD cards through SPI. Note that down to this point the code was unaware that we were using SD cards or an SPI bus: it was hardware-independent C. In this layer of code I implemented the SD card protocol, described in some specifications such as the official SD standard Physical Layer Simplified Specification. These specifications contain both an SD bus mode and an SPI mode to access the card. While the SD bus mode is generally faster because it uses more I/Os, the SPI mode is enough to implement all the functionalities, and it’s what we have to use because of the hardware connection between the microcontroller and the card.

The SD card can be commanded using simple SPI transactions, so I needed to access the SPI peripheral of the STM32 to perform these transfers. The last library that I used is libopencm3, which provides low-level access to Cortex-M3 core and many peripherals. These SPI transactions pass through the wires that I connected on the boards and communicate the data back and forth between STM32 and memory card. The code has also to assert the chip select of the SD card during each transaction to indicate to the SD card that the data travelling through the SPI bus is directed to it.

“SPI single slave” by en:User:Cburnett – Own workThis vector image was created with Inkscape.. Licensed under CC BY-SA 3.0 via Wikimedia Commons – https://commons.wikimedia.org/wiki/File:SPI_single_slave.svg#/media/File:SPI_single_slave.svg

Conclusion

All together, the collection of layers and libraries implement the file I/O that is expected to be available for common C programs. Each call to a C standard function will propagate downwards through all the library stack and perform accesses to the SD card, and the result of the operation will be propagated upwards to give to the main program the correct response.

The libraries and test code is currently available at my GitHub repository nucleo_tests.

Better Embedded System SW: Top 5 Embedded Software Problem Areas – Five areas to dig into when evaluating embedded software projects

I read some guides around, some old, some with big warnings and disclaimers, some interesting. Ultimately I decided to apply a strategy involving an intermediate step where I could dual boot between 32 and 64 bits, and this would allow me to return easily to the old system. When I first installed Debian 32bit, I separated my home, root and boot partitions, and this helped much in my migration.

The strategy has been:

1. Reduce the size of some existing partitions. In my case I reduced my home, to make space for the new 64bit partitions.
2. Add new partitions for root64 and boot64. Note that it doesn’t seem like a good idea to share boot partition between two distributions, otherwise one distro might decide to delete the kernels of the other ones. While Grub is able to detect Linux kernels and other operating systems in partitions other than boot.
3. Install (from CD or USB) Debian 64-bit on root64 and boot64, keeping shared (and without formatting!) the home and swap directories. I used an “Alpha” snapshot of the Debian testing (Stretch) network installer (netinst).
4. Replicate the setup of installed packages and configurations. This has been an easy but iterative process of installing packages that I installed on previous
5. Remove old 32bit root and boot (actually, I haven’t yet done this one)

Some notes about what happened:

• Before installation, I ran “dpkg --get-selections >selections.txt” to get a list of all packages, but since I use aptitude, I ran “aptitude search '~i !~M' >pkgs.txt” to search for packages that I did install and were not installed automatically as dependencies.
• During CD installation, it complained about systemd vs ifupdown dependencies not met. I found this post, and ran “apt-get install -f” from recovery shell to solve it.
• I installed Grub into the Master Boot Record, and rebooted. The first time, it complained about home partition not clean, and I had to enter recovery console and run fsck manually.
• I could log into my desktop, but it was very slow to start. I installed some XFCE packages and other software that I ran in autostart, and XFCE was then starting smoothly.
• One problem that I had in my old setup and it still appeared was a failure in checking some partitions at boot: it would timeout after a minute and the partitions were not checked. Turns out I had to run “systemctl mask systemd-fsckd.socket” and “systemctl mask systemd-fsckd.service” that were interrupting the operation.
• I noticed that I had no xfce4-mixer anymore, and I substituted it with a pulseaudio plugin instead.
• dropbox, truecrypt and google chrome were installed by downloading from their respective websites.
• I had some programs on wine, but it turns out I have to install the 32bit version to make them run. So I added the 32bit architecture with “dpkg --add-architecture i386” and installed wine32-development package.

I am happy with the end result, I am typing right now in the 64bit version and I don’t notice the difference. The user experience seems more fluid, but it may very well be just an impression. I hope this strategy can be helpful for reference.

Here’s the talk:

Time Protocol

The RFC 868 describes the “Time Protocol“, which is a very old but deadly simple way to get the time from a server that implements this service. With this protocol a device is able to retrieve a 32-bit unsigned value indicating the number of seconds that have passed since the 1st of January 1900.

There are two ways to connect to the service: TCP or UDP. With TCP the device connects to port 37 and the server immediately sends back to the device the 32-bit value in 4 bytes (in network byte order); the device can now close the connection. With UDP, the device sends a dummy UDP datagram to port 37 of the server, containing 0 or more bytes whose content is ignored by the server; when the server receives a packet, it replies with the 32-bit value as before.

The precision of this time synchronization can’t be less than a second, moreover the time that passes between the sending and the receiving of the packet may vary. Anyway if we simply want the approximate time of the day, it’s good enough.

The implementation that I used in my Nucleo board is here in rfc868_time.c.

Simple Network Time Protocol

Many people are familiar with NTP, which is the protocol that our PCs use to synchronize the time with time servers around the globe. Its specifications are detailed in RFC 5905, and the precision that can be reached is very high.

But a simpler variant exists, aptly named SNTP and described in RFC 4330. An implementation of this protocol is able to retrieve from a server the timestamp containing the number of seconds from 1st of January 1900 and a fraction of second. A whole timestamp occupies 64 bits, and its value is more precise that what can be achieved by the Time Protocol, especially when the device performs some estimation of packet travel time and clock offset, using the timestamps present in the exchanged packets. The interaction also in this case is simple: it’s about sending a 36-byte UDP packet and receiving a similar packet, whose fields contains the timestamps that are used to synchronize the device clock with the server clock.

The implementation that I used in my Nucleo board is here in sntp.c.

There’s a list of NIST servers that implement the common time protocols here: NIST Internet Time Servers. It is advised to resolve time.nist.gov so that the client points to the nearest non-busy server.

Nucleo board wired with Ethernet shield.

One of my goal of the past months was to use an STM32 Nucleo board to get a webpage through HTTPS, using an Ethernet shield for TCP/IP stack. I was close last time, but I discovered that my Nucleo-F103RB did not have enough RAM. Now I have my hands on a Nucleo-F411RE that has 128KiB of RAM and 512KiB of Flash, and I was finally able to do it.

The hardware is composed of:

• Nucleo-F411RE
  • STM32F411RE microcontroller
  • SPI master to communicate with other chips
  • USART serial port with STLink USB connection for standard I/O
  • JTAG with STLink USB connection to flash program
• Ethernet shield
  • Wiznet W5100 that implements the TCP/IP and UDP/IP stacks.
  • SPI connection to the board below.

The software that I uploaded on board is composed of:

• Low-level drivers provided by libopencm3
• W5100 SPI driver to expose the chip registers and memories.
• Socket API: POSIX socket library developed by me on top of W5100 functionality.
• USART minimal driver to write/read from serial port through the STLink USB connection on the Nucleo.
• DNS: I developed a minimal implementation of getaddrinfo() to retrieve the IP address of a website from its name.
• TLS: I used mbedTLS 2.2.0 for the Transport Layer Security 1.2
• The certificate of the CA, that is embedded statically as a binary blob into the program (I used Chrome to download it beforehand).
• The application is simply an HTTP GET request.

The tools I used to build the software are:

• GCC ARM Embedded toolchain (version 4.9 2015q1) to compile and link the code,
• OpenOCD (version 0.9.0) to write the software image into the STM32 embedded flash,
• Chrome to download the CA certificate,
• minicom to connect with the serial port
• All on my Debian (Stretch) Linux box

To build and run:

1. git checkout my nucleo_tests repo (now at commit eb2cc1942618f745286028c3cc591012b92d56bc).
2. Go in libopencm3 directory and run “make” to compile the low-level drivers.
3. Download mbedTLS 2.2.0 and unpack it in nucleo_tests directory.
4. Open “nucleo_tests/tests/test.mk“, comment the stm32f103rb line and uncomment the stm32f411re line.
5. Go in “nucleo_tests/tests/mbedtls” directory and run “make” to build both the mbedTLS library and the application.
6. Connect the Nucleo board + Ethernet shield to the PC with USB, and connect the Ethernet cable.
7. In another terminal run “minicom -b 57600 -D /dev/ttyACM0” to connect to the serial port.
8. Run “make flash” to write the program into the STM32 embedded flash (uses openocd program)
9. Wait for the Link LED on the Ethernet shield to turn on.
10. Go in the minicom terminal, and you should see a prompt; press a key to continue.
11. The terminal should print the page that has been retrieved through HTTPS.

This is the output I get from the serial port:

Press any key to continue...
Certificate:
cert. version     : 3
serial number     : 02:0B:70:F4:68:67:1E:47:13:96:63:3D:99:2C:E5:CD
issuer name       : C=US, O=DigiCert Inc, CN=DigiCert SHA2 Secure Server CA
subject name      : C=US, ST=Cali
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 04 Feb 2016 20:41:12 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Last-Modified: Mon, 09 Nov 2015 23:59:43 GMT
ETag: "687f8a-bd-52424631079c0"
Cache-Control: max-age=1209600
Expires: Wed, 10 Feb 2016 15:34:38 GMT
Vary: Accept-Encoding
X-Varnish: 324309826 304737767
Age: 709594
Via: 1.1 varnish
Strict-Transport-Security: max-age=31536000; includeSubdomains
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN

bd
<html>
    <head>
        <title>Site Under Maintenance</title>
    </head>
    <body>


<h1>This site is currently under maintenance. Please try back later.</h1>


    </body>
</html>

0

To conclude, this proof of concept shows a very small platform that can be used to build IoT applications with a layer of security. Instead of having an application processor running Linux, we have a microcontroller running at a frequency as low as 16MHz, the base software is around 90KiB of code running in flash, and needs around 50KiB of RAM, between static and dynamic memory. We are using a security layer that doesn’t invent anything new: it’s an implementation of the widely used TLS.