In this final part of Bob’s article series about the open-source FreeRTOS, he looks at the options that you, the system designer, have for connecting to the Internet using FreeRTOS and its libraries.
Ihave a friend who, when he came to the United States for the first time, was overwhelmed with the choices that he found in a supermarket. Although I myself continue to be amazed by the choices that supermarkets offer, I am likewise overwhelmed with the choices we have as embedded system designers when it comes to selecting a processor for our next project. Circuit Cellar does a good job in trying to keep us up to date with the dizzying number of choices. But is it enough?
In 1977, I was in charge of a large project to migrate our US based minicomputer controller and our European-based hardwired controller to a microprocessor-based system. Even then I was a little overwhelmed with the number of choices. Do I go with the front-runner from Intel: the 8080 processor? Or the up-and-coming MOS Tech 6502, which was used in the Apple II and the Atari personal computers? What about the venerable Motorola 6800? Motorola (now NXP Semiconductors) had a longer corporate history than MOS Tech or Intel. After all, it got its name from creating radios for automobiles [1].
The Signetics 2650 (Signetics is now also part of NXP) was the most like a minicomputer in architecture and that looked good. Meanwhile, Texas Instruments (TI) had introduced a single-chip 16-bit processor around that time and that was pushed by our European engineers. The TMS9900 from TI was the first single-chip 16-bit microprocessor and implemented the architecture of the TI 990 minicomputer. A big plus was that it was similar to the PDP-11 minicomputer that we used in our US-based control. Do I go with an 8-bit or 16-bit device? Ultimately, I chose the Zilog Z80 which, from a production point of view, turned out to be a prescient choice given that the controller was in production for over 20 years and is actually still in operation in some parts of the world. Long term availability of the chip surpassed my wildest dreams. But it was not my brilliance that picked such a winner. A very good case was made by my European partners for choosing other chips. I don’t even remember why I picked it. Figure 1 shows images of each of these microprocessors.
These are the six processors I considered back in 1977 when I was in charge of a project to migrate a minicomputer design to a microprocessor-based system.
Today, embedded designers face a daunting task of choosing a processor. If I thought the number of options for microprocessors in 1977 was overwhelming, consider today. Digi-Key [2] lists 9,807 separate choices of microprocessors and an astronomical 90,600 different MCUs. Admittedly, a lot of these are just packaging choices and processor speeds—but they are choices nonetheless. To make matters worse, Digi-Key doesn’t sell all of the available microprocessors and MCUs that are on the market. I get tired just thinking about where to start narrowing down such a list of options.
Thankfully, there are not that many options for designers when it comes to connecting our devices to the Internet. But the task is still quite daunting as well. In a previous article, “The Internet of Things (Part 1)” (Circuit Cellar 299, June 2015), we talked about a number of ways to connect to the Internet wirelessly [3]. This month we will look at some of the ways to connect FreeRTOS systems to the Internet. Specifically, we’ll examine the options when using the FreeRTOS+TCP library with FreeRTOS. First, we will briefly discuss the hardware options and then spend most of our time looking at the software required.
HARDWARE
Ethernet: To connect to the Internet over Ethernet you need an Ethernet controller (standalone or built into the MCU), a PHY and a set of magnetics usually built into an RJ-45 connector (Figure 2). Table 1 shows the current list of Ethernet controllers supported in FreeRTOS+TCP in the latest release (v202107.00) as of the writing of this article. Note, I don’t cover the eval boards that are supported—just the chips. Nor do I cover those chips supported by the much earlier TCP/IP stack called IW/IP. If you use one of these controller chips or MCUs that embed an Ethernet controller, you’ve got some code to get you started. The Ethernet drivers are not part of the tested TCP/IP stack provided by FreeRTOS. Per their disclaimer: “Network drivers are provided as examples only, and do not form part of the FreeRTOS+TCP stack itself” [4]. They are not fully tested, they are not optimized, they may be dependent upon a particular PHY and they may have other dependencies that are not applicable. In other words, prepare for some work. Pay particular attention to the PHY. A lot of eval boards use a much more expensive PHY than you need or it may not be second sourced.
— ADVERTISMENT—
—Advertise Here—
Wi-Fi through a gateway: In this case, the gateway can connect to a local network or use a cell modem to connect to the cell network. Figure 3 provides one particular layout of Wi-Fi to the cloud. Our first FreeRTOS project used Wi-Fi through a hotspot thus bi-passing the need to use the customer’s router. FreeRTOS devices can connect to the local network via Wi-Fi using connectivity libraries such as the Wi-Fi management library. This library implements an abstraction layer for Wi-Fi features such as setup, configuration, provisioning, security and power management. Table 2 provides the list of MCUs containing supported Wi-Fi chips. And if you are surprised with how few of these exist, you don’t realize how long it takes to write a Wi-Fi driver. Definitely not for the faint-of-heart.
To connect to the Internet over Ethernet you need an Ethernet controller, a PHY and a set of magnetics usually built into an RJ-45 connector.
This is the current list of Ethernet controllers supported in FreeRTOS+TCP in the latest release (v202107.00) as of the writing of this article.
The gateway can connect to a local network or use a cell modem to connect to the cell network. Shown here is one particular layout of Wi-Fi to the cloud.
List of MCUs containing supported Wi-Fi chips
Cell modem: Since most cell modems interface to the processor through serial or USB ports, you need to make sure that your port provides these drivers. Serial drivers are pretty easy to write but USB drivers are quite a bit more complicated. Since many cell modems interface through a series of AT commands, no additional software is needed. However, FreeRTOS does provide interfaces to the following cell modems through FreeRTOS-Labs: Quectel BG96, Sierra Wireless HL7802 and the U-blox Sara-R4. We have used the U-blox Sara module on a number of projects. Keep in mind that this code has not completed full implementation testing, usability verification, documentation and memory usage reductions.
Other mechanisms: We have covered LoRa quite extensively previously in this column, so you should know that there are LoRa gateways to connect the Internet. Most of the interfaces are via some serial interface (I2C, UART or SPI) so you will need to make sure these are covered in your port (most are).
SOFTWARE
Berkeley Sockets: FreeRTOS+TCP provides all of the standard Berkeley Sockets most of us are familiar with going all the way back to UNIX. The TCP stack is thread safe and very scalable. Being thread safe means that you can have multiple threads using the socket APIs without problems and they are re-entrant. For those who are trying to minimize network traffic, even the UDP protocol APIs are provided to talk over the network. The UDP implementation is so geared to small memory footprints that it allows you to choose whether or not the functions copy the data into your buffer or just provide a pointer to the data.
HTTP: Most of us don’t interface to web services via TCP/IP or UDP. We send JSON files over HTTP or HTTPS. FreeRTOS libraries provide support there with the coreHTTP library. Be aware that it only implements a subset of the HTTP/1.1 protocol—but I would say it covers the basics that I normally would use.
MQTT: For an even smaller footprint (both in terms of on-board memory but also network traffic), coreMQTT is a library providing a 3.1.1 compliant MQTT client. MQTT is designed to be a publish/subscribe style lightweight protocol. This is what we used in our first FreeRTOS project. coreMQTT runs on top of TCP/IP. Figure 4 provides a rough layout as to where MQTT fits into the overall scheme.
This provides a rough layout as to where MQTT fits into the overall scheme of things. Also shown here, Amazon added several libraries to enable FreeRTOS to connect to its AWS.
AWS services: Given Amazon’s takeover of FreeRTOS you would expect that it would contain Amazon’s cloud interfaces for IoT: AWS IoT Core for small low power devices and AWS IoT Greengrass for more powerful and more resource rich devices. And although the software is free, use of the AWS cloud services is not. Since Amazon’s takeover, it has added the following libraries to enable FreeRTOS to connect to AWS: the Device Defender library is the glue needed to interface with the Amazon IoT Device Defender; the Device Shadows library provides the interfaces to create, update, and remove Amazon IoT Device Shadows; the Over-The-Air (OTA) agent allows you to provide software updates; a Greengrass discover library to enable you to connect to an Amazon IoT Greengrass Core; a Transport Layer Security (TLS) library to provide secure connections; and finally an API library to manage cryptographic tokens (or Key Management) that conforms to Public Key Cryptography Standard (PKCS) #11. Figure 4 also shows how all of these fit into FreeRTOS.
JSON: We have used JSON (JavaScript Object Notation) formatted data almost exclusively in all of our IoT projects. It is widely supported in cloud services and to no surprise used in AWS IoT Device Shadow services. FreeRTOS provides a JSON parser to allow you to easily extract data, validate and create JSON-compatible structures.
Azure: If you are required to integrate your device with your customer’s Azure Cloud (Microsoft), your options are limited. The Azure Middleware for FreeRTOS is available on GitHub, but is not ready for general availability and is quite far away from release to manufacturing (RTM). Also, as of this writing it is only supported by five MCUs: STMicroelectronics’ STM32L475, STM32L4+ and STM32H745; NXP’s RT1060 and the ESP32 from Espressif.
— ADVERTISMENT—
—Advertise Here—
CONCLUSION
One important thing you need to keep in mind: The core of FreeRTOS is pretty robust, but the libraries are still pretty immature. The disclaimers that they make could scare you away. Just know—and let your manager know—that this isn’t going to be as easy as it looks. My first software project looked like about a two- to three-day project. It took me two to three weeks. And it was only about 100 lines of code! Our first FreeRTOS project using MQTT took months longer than we expected.
At the outset, I said that there were not many choices available to you in connecting your FreeRTOS design to the cloud. In one respect, that is true. Digi-Key offers more than 5,000 MCUs with Ethernet built in. So, if you want built-in Ethernet, you have reduced your choices significantly if you choose FreeRTOS. You only have 14 to choose from (I know there is overlap in those 5,000, but hear me out). Digi-key offers 14 MCUs with built-in Wi-Fi. And you only have two to choose from if you go with FreeRTOS.
This may sound like a bad thing. But it isn’t. We cannot evaluate over 90,000 MCUs for our application. But we can evaluate 14. Maybe you had a bad experience with Microchip. At least you have other manufacturers to choose from.
This concludes my article series about FreeRTOS. Overall, I think it is a welcome addition to our tool kit. Amazon’s foray into these waters has made the waters both more abundant and muddier. The situation is more abundant because they have poured a lot of welcomed resources into FreeRTOS. But its muddier because tying ourselves to one web services provider does not seem like a good thing.
Next time, we will launch into a new topic. We will look at Lehman’s law and how it affects us as embedded systems designers. But of course, only in thin slices.
RESOURCES
References:
[1] Motorola was derived from motor” (for motor car) and “ola” (where the derivation is not as clear – but probably a takeoff on Victrola)
[2] https://www.digikey.com Search on microprocessors and microcontrollers
[3] “The Internet of Things (Part 1): Options for Connecting Wirelessly to the Internet” (Circuit Cellar 299, June 2015)
[4] See the “readme” that comes with these drivers in the FreeRTOS+TCP software download.
Digi-Key | www.digikey.com
Espressif Systems | www.espressif.com
FreeRTOS | www.freertos.org
Infineon Technologies | www.infineon.com
Microsoft Azure | www.azure.microsoft.com
NXP Semiconductors | www.nxp.com
Texas Instruments | www.ti.com
Xilinx | www.xilinx.com
Zilog | www.zilog.com
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • DECEMBER 2021 #377 – Get a PDF of the issue
Sponsor this Article
Bob Japenga has been designing embedded systems since 1973. From 1988 - 2020, Bob led a small engineering firm specializing in creating a variety of real-time embedded systems. Bob has been awarded 11 patents in many areas of embedded systems and motion control. Now retired, he enjoys building electronic projects with his grandchildren. You can reach him at
Bob@ListeningToGod.org
