What is an "IoT device development platform"? | APS｜組み込み業界専門メディア

In this article, I would like to note that Mbed can be used as a platform for developing IoT devices. As you know, IoT is translated as “Internet of Things”, which means “Internet of Things”. This does not simply mean “things are connected to the Internet”, but rather “things are connected like the Internet”, which means they are interconnected.

Aside from that, to call it an “IoT device development platform,” it must be able to handle IP (Internet Protocol).

The reason why I started to use Mbed is that I wanted a microcontroller board that can connect to the Internet natively. At that time, I had just started to use Arduino after a blank period of more than 15 years since I touched the Z80 when I was a junior high school student.

At that time, it was common to use a chip called W5100, which was a hardware implementation of the IP stack, to connect the Arduino to an IP network. This meant that the IP processing was offloaded to the W5100 instead of being done in the development target microcontroller. Offloading to a dedicated chip allows for IP handling even on an 8-bit microcontroller with 1KB of memory, such as the ATmega328P, but there are certain problems with this approach.

The first problem that comes to mind is the inability to update the protocol stack in hardware implementations. If the necessary protocols and processes are not implemented, you will still have to implement them in the target microcontroller. And even if there is an implementation, debugging to check the offloaded processes will be very difficult. This is why I started to use mbed LPC1768, which is designed to run the protocol stack on a microcontroller and has an Ethernet interface.

I just connected the mbed LPC1768 to Ethernet.

The photo shows the author connecting the mbed LPC1768 to Ethernet in 2010 to read a text file via HTTP and display the contents of the text file. I connected the Ethernet signal wire to the RJ-45 connector with a jumper wire, and I remember being surprised at the fact that I could communicate with such a cumbersome connection.

IP Stack
Driver API
Components
RTOS
Device management
Summary

IP Stack

As I mentioned in the last issue, Mbed OS has a built-in IP stack. The built-in IP stacks are lwIP, a well-known IP stack for embedded applications, and Nanostack. There is a ://os.mbed.com/docs/v5.9/reference/network-socket.html”>Network socket API, which abstracts IP connectivity.

【Source：IP networking】

The Network socket API (NSAPI) is a relatively recent addition to the interface, so support for application layer libraries is limited. However, for example, the frequently used MQTT (Message Queuing Telemetry Transport) library and sample program HelloMQTT, a client of Mbed Cloud, and the sample program Mbed Cloud Client The mbed-cloud-client-example, for example, supports NSAPI.

In addition to encryption, Transport Layer Security (TLS) is often used to secure network connections as a means of authenticating devices, and TLS also runs on microcomputers without offloading the protocol stack, making it a more flexible way to manage There is a TLS implementation of Mbed called mbed TLS. mbed TLS will be described in detail next time.

Driver API

How does Mbed handle things that are connected to the network (sensors and actuators)? This kind of I/O is provided as Driver API, which supports digital and analog input/output, and this abstraction makes it possible to write Mbed-independent code (of course, you can use analog input/output to develop target microcontroller). (If you don’t have peripherals, you won’t be able to implement it…).

With the existence of this Driver API, you can read the value of the LM75B connected to the microcontroller without having to read the microcontroller’s datasheet or sample code to learn how to operate I²C, you can simply write the following code to read the value of the LM75B connected by I²C.

#include "mbed.h"

I2C i2c(I2C_SDA , I2C_SCL); 

const int addr7bit = 0x48;      // 7 bit I2C address
const int addr8bit = 0x48 << 1; // 8bit I2C address, 0x90

int main()
{
    char cmd[2];
    while (1) {
        cmd[0] = 0x01;
        cmd[1] = 0x00;
        i2c.write(addr8bit, cmd, 2);
 
        wait(0.5);
 
        cmd[0] = 0x00;
        i2c.write(addr8bit, cmd, 1);
        i2c.read( addr8bit, cmd, 2);
 
        float tmp = (float((cmd[0]<<8)|cmd[1]) / 256.0);
        printf("Temp = %.2f\n", tmp);
    }
}

This implementation of the Hardware Abstract Layer (HAL) is one of the things that makes Mbed OS more useful than other RTOSs. The only rewrite you will need to do when porting this code to other Mbed OS-supported microcontrollers is, in most cases, the pin name on the third line. Note that this pin name is a definition that exists in many Mbed enabled boards, so you may not even need to rewrite it.

Components

Although the Driver API handles inputs and outputs directly, there are libraries (drivers) for each component, such as sensors. For example, the LM75B library is available at LM75B Temperature Sensor and can be found at You can read the values by writing the following code, which is published here

#include "mbed.h"
#include "LM75B.h"
 
LM75B sensor(I2C_SDA , I2C_SCL);
 
int main()
{
    if (sensor.open()) {
        printf("Device detected!\n");
 
        while (1) {
            printf("Temp = %.3f\n", (float)sensor);
 
            wait(0.5);
        }
    } else {
        error("Device not detected!\n");
    }
}

In the code that uses the library, you can see that the I²C data transfer is not directly described like the code in the Driver API section. Using the library in this way makes it easy to try to run the sensor without having to peruse the sensor’s datasheet.

However, many of the libraries are created by other Mbed users and contributed to by publishing them. So, it may not work as intended, or there may be quality issues. If you find such code, please submit a Pull Request and contribute by improving the quality of the code. If a Pull Request is not being handled because the original author is not active, etc., you may want to edit the Components page and change it to show the modified code.

If you don’t have a library of components you want to use, you can check out the Library The page “How to make components” is a good place to start. When you publish this, you can add it to the more usable component library that he wrote The article “How to do it” is also helpful.

RTOS

Opinions may differ, but applications that communicate, such as end nodes in the IoT, will often have asynchronous processing, or multi-threaded programming. Threads are a central component of Mbed OS, and the RTOS API handles the creation and destructuring of threads.RTOS in Mbed OS is CMSIS-RTOS RTOS RTX, which is also a standard feature of the commercial compiler Keil MDK-ARM, and so on. We have a good track record.

Device management

A few prototypes, but if you want to actually deploy the IoT, device management is what you’ll need. Device lifecycle management, such as provisioning and post-deployment updates for each sensor node, is provided by Pelion Device Management and Pelion Device Management, formerly known as the Mbed Cloud, is now part of the recently announced Arm Pelion IoT Platform. I think.

Summary

As such, Mbed OS has all the features needed to develop IP stacks, standardized I/O, multi-threaded programming, as well as device management and IoT end nodes. It is also open source software, often distributed under the Apach 2.0 license and a license that is convenient for use in commercial projects.

Furthermore, it supports not only GCC as a compiler, but also the major commercial compilers for Arm, such as armcc and IAR’s EWARM, as well as debugging, which means that it has all the features you need for your business.