Texting and IoT Embedded Devices (Part 1)

Fun with the ESP8266 SoC

Can texting be leveraged for use in IoT Wi-Fi devices? Jeff has been using Wi-Fi widgets for a lot of IoT projects lately. This month Jeff lays the groundwork for describing a project that will involve texting. He starts off with a look at Espressif System’s ESP8266EX SoC.

By Jeff Bachiochi

Believe it or not, texting while driving as of this writing is still legal in a few states. About 10% of all motor vehicles deaths in the US can be traced back to distracted drivers. Granted that includes any distraction—however cell phone distraction has quickly become a serious issue. While hazards exist for any technology, common sense should tell you this is a dangerous act.

When the technology is used correctly, texting can deliver essential information quickly—without requiring both (or many) parties to be active at the same time. This allows you to make better use of your time. I still use email for much of my correspondence, however it’s great to be able to send your spouse a text to add milk to the grocery list—after they’ve already left for the store! And even though I chuckle when I see two people sitting next to each other texting, it is a sad commentary on emerging lifestyles.

I’ve been using Wi-Fi widgets for a lot of IoT projects lately. The cost to enter the fray is low, and with free tools it’s easy to get started. This month’s article is a about a project that will involve text, even though that may not be apparent at first. Let’s start off slowly, laying the groundwork for those who have been thinking about building this kind of project. We’ll then quickly build from this foundation into crafting a useful gadget.

A Look at the ESP8266EX

The innovative team of chip-design specialists, software/firmware developers and marketers at Espressif System developed and manufactures the ESP8266EX system-on-chip (SoC). This 32-bit processor runs at 80 MHz and embeds 2.4 GHz Wi-Fi functionality—802.11 b/g/n, supporting WPA/WPA2—as well as the normal gamut of general-purpose I/O and peripherals. It has a 64 KB boot ROM, 64 KB instruction RAM and 96 KB data RAM. Their WROOM module integrates the ESP8266 with a serial EEPROM and an RF front end with a PCB antenna for a complete IoT interface.

Anyone who has ever used a dial-up modem is most likely familiar with the term AT command set. The Hayes command set is a specific command language originally developed in 1981 by Dennis Hayes for the Hayes 300 baud Smartmodem. Each command in the set begins with the letters AT+ followed by a command word used for high-level control of internal functions. For the modem these enabled tasks like dialing the phone or sending data. As an application for the WROOM, an AT command set seemed like a perfect match. This allows an embedded designer to use the device to achieve a goal without ever having to “get their hands dirty.”

This photo shows the ESP-01 and ESP-07 modules along with the FTDI 232 USB-to-serial converter used for programming either module.

I first learned of the ESP8266 years ago and purchased the ESP-01 on eBay. It was around $5 at the time (Photo 1). I used it along with the MEGA 2560—my favorite Arduino module because of its high number of I/Os and multiple hardware UARTs. With the ESP-01 connected to a serial port on an Arduino, an application could directly talk with the ESP-01 and get the Arduino connected to your LAN. From this point, the world is under your control thanks to the AT Wi-Fi and TCP commands.

The ESP8266 literature states the Wi-Fi stack only requires about 20% of the processing power. Meanwhile, 80% is still available for user application programming and development.
So why not eliminate the Arduino’s Atmel processor altogether and put your Arduino code right in the 8266? Espressif Systems has an SDK and while it provides a development and programming environment, the Arduino IDE is comfortable for many. And it offers the installation of third-party platform packages using the Boards Manager. That means you can add support for the ESP8266EX and use much of the code you’ve already written.

Using the ESP-01

Since the ESP-01 has only 8 pins, adding the necessary hardware is pretty simple. This low power device runs on 2.5 V to 3.6 V, so you must make appropriate level corrections if you wish to use it with 5 V devices like Arduino boards. …

Read the full article in the March 332 issue of Circuit Cellar

Don’t miss out on upcoming issues of Circuit Cellar. Subscribe today!
Note: We’ve made the October 2017 issue of Circuit Cellar available as a free sample issue. In it, you’ll find a rich variety of the kinds of articles and information that exemplify a typical issue of the current magazine.

IoT: From Device to Gateway

Modules for the Edge

Connecting to the IoT edge requires highly integrated technology, blending wireless connectivity and intelligence. Feeding those needs, a variety of IoT modules have emerged that offer pre-certified solutions that are ready to use.

By Jeff Child, Editor-in-Chief

he Internet of Things (IoT) is one of the most dynamic areas of embedded systems design today. Opportunities are huge as organizations large and small work to develop IoT implementations. IoT implementations are generally comprised of three main parts: the devices in the field, the cloud and the network (gateways) linking them together. This article focuses on the “things” side—in other words, the smart, connected edge devices of the IoT. For more on IoT gateways, see “IoT Gateway Advances Take Diverse Paths“ (Circuit Cellar 328, November 2017).

Because this sub-segment of technology is growing and changing so fast, it’s impossible to get a handle on everything that’s happening. The scope that comprises IoT edge devices includes a combination of embedded processors and microcontrollers that provide intelligence. It also includes various wireless, cellular and other connectivity solutions to connect to the network. And it includes sensors to collect data and battery technologies to keep the devices running.

Connecting the various nodes of an IoT implementation can involve a number of wired and wireless network technologies. But it’s rare that an IoT system can be completely hardwired end to end. Most IoT systems of any large scale depend on a variety of wireless technologies including Wi-Fi, Bluetooth, Zigbee and even cellular networking.

What’s most interesting among all that, are not those individual pieces themselves, but rather an emerging crop of modular IoT products that combine intelligence and connectivity, while also taking on the vital certifications needed to get IoT implementations up and running. With all that in mind, the last 12 months have seen an interesting mix of module-based products aimed directly at IoT.

Certified IoT Modules

Exemplifying those trends, in September 2017, STMicroelectronics (ST)introduced the SPBTLE-1S, a ready-to-use Bluetooth Low Energy (BLE) module that integrates all the components needed to complete the radio subsystem (Photo 1). The BLE module integrates ST’s proven BlueNRG-1 application-processor SoC and balun, high-frequency oscillators and a chip antenna.

Photo 1
The SPBTLE-1S is a BLE module that integrates all the components needed to complete the radio subsystem. It’s BQE-approved, and FCC, IC and CE-RED certified to simplify end-product approval for North America and EU markets.

Developers can use this module to bypass hardware design and RF-circuit layout challenges. The SPBTLE-1S is BQE-approved, and FCC, IC and CE-RED (Radio Equipment Directive) certified to simplify end-product approval for North America and EU markets. ST’s Bluetooth 4.2 certified BLE protocol stack is included, and the supporting Software-Development Kit (SDK) contains a wide range of Bluetooth profiles and sample application code.

The device is packaged in a space-efficient 11.5 mm x 13.5 mm outline and has a wide supply-voltage range of 1.7 V to 3.6 V. The SPBTLE-1S module is well suited for small, battery-operated objects powered by various types of sources such as a primary button cell or rechargeable Li-ion battery. High RF output power of +5 dBm and good receiver sensitivity help to maximize communication range and reliability.

The BlueNRG-1 SoC at the heart of the SPBTLE-1S implements the complete BLE physical layer (PHY), link layer and network/application-processing engine comprising a low-power ARM Cortex-M0 core with 160 KB flash, 24 KB RAM with data retention and a security co-processor. The SoC also implements smart power management, with a DC/DC converter capable of powering the SPBTLE-1S module to ensure optimum energy efficiency. Users can leverage an extensive set of interfaces, including a UART, two I²C ports, SPI port, single-wire debug and 14 GPIOs, as well as peripherals including two multifunction timers, a 10-bit ADC, watchdog timer and real-time clock and a DMA controller. There is also a PDM stream processor interface, which is ideal for developing voice-controlled applications.

IoT Module for Development

Riding the IoT wave, all the major microcontroller vendors have beefed up their module-based IoT solutions in order to make it easier for developers to design in their MCUs. One example along those lines is the LPC54018 IoT module, developed by NXP in partnership with Embedded Artists. …

Read the full article in the March 332 issue of Circuit Cellar

Don’t miss out on upcoming issues of Circuit Cellar. Subscribe today!
Note: We’ve made the October 2017 issue of Circuit Cellar available as a free sample issue. In it, you’ll find a rich variety of the kinds of articles and information that exemplify a typical issue of the current magazine.

TRACE32 Extends embOS Awareness to the Renesas RH850

Lauterbach has announced that it has extended the kernel awareness for the embOS RTOS from SEGGER Microcontroller to the RH850 Family of microprocessors from Renesas Electronics. TRACE32, the class leading debug tools from Lauterbach, already supports embOS on ARM, PowerPC, RX, SH and NIOS-II families and this tried and tested technology has now been extended to include RH850.

The embOS awareness plugin for TRACE32 allows the developer to visualise RTOS resources and objects such as task lists, mailboxes, timers and semaphores. Developers are free to investigate interrupt routines, drivers and application code all from within the familiar environment of TRACE32. When the awareness is configured, extra features become available, for instance the setting of task aware breakpoints.

All MPUs of the RH850 Family provide dedicated counter registers which can be accessed non-intrusively by the TRACE32 debugger. These can be configured to display minimum, maximum and mean runtimes for a user marked block of code or the runtimes of various tasks in the embOS system. If the target provides off-chip trace capabilities, TRACE32 can record processor cycles and can be configured to collect data on task switches. Using this information, a detailed analysis of the program history, including task switches, can be viewed.

All features of the TRACE32 awareness for embOS do not require any additional target configuration or any hooks or patches within the RTOS itself. The philosophy of TRACE32 is for the application to behave exactly the same in the debug environment as on the final product; only this way can 100% certainty of testing be achieved.

Lauterbach | www.lauterbach.com

IoT Platform Gets Thread Certification

Express Logic has announced that its Industrial Grade X-Ware IoT Platform is an official Thread Certified Product, and the only such solution from an independent RTOS provider. Created by the Thread Group, Thread is a reliable, low-power, secure, and scalable mesh networking solution that provides a foundation on which any application layer can run.

The X-Ware IoT Platform, powered by Express Logic’s high-performance ThreadX RTOS and NetX Duo dual IPv4/IPv6 TCP/IP stack, provides industrial-grade implementations of IPv6 over Low Power Wireless Personal Area Networks (6LoWPAN), Constrained Application Protocol (CoAP), and Datagram Transport Layer Security (DTLS).

According to Express Logic, Thread certification provides more than just protocol compliance. Rather than measuring against single reference implementations, Thread testing validates each device’s specification conformance against a blended network comprised of four reference stacks to ensure device interoperability and reduce risk and time to market. Compliance to the Thread certification protocols and standards is administered and regulated by UL a global, independent, safety and certification company with more than a century of expertise in implementing certification solutions and standards.

The X-Ware IoT Platform contains no open source, is high performance, and boasts an extremely small footprint. The X-Ware IoT Platform automatically scales to use only what is needed by the application, making it well suited for the smallest low-power IoT devices. In addition to the performance and size advantages of the X-Ware IoT Platform, ThreadX and NetX Duo have attained the highest level of safety certifications. They include IEC 61508 SIL 4, IEC 62304 Class C, ISO 26262 ASIL D, EN 50128 SW-SIL 4, UL 60730-1 Annex H, CSA E60730-1 Annex H, IEC 60730-1 Annex H, 60335-1 Annex R and IEC 60335-1 Annex R, 1998.

Thread certification will also allow developers to confidently leverage the entire X-Ware IoT Platform solution, including the safety-certified FileX, GUIX, and USBX solutions and technologies, knowing it will seamlessly connect to other Thread-certified devices.

Express Logic | www.rtos.com

Thread Group | www.threadgroup.org

MCU Vendors Embrace Amazon FreeRTOS

In a flurry of announcements concurrent with Amazon’s release of its new Amazon FreeRTOS operating system, microcontroller vendors are touting their collaborative efforts to support the OS. Amazon FreeRTOS extends the FreeRTOS kernel, a popular open source RTOS for microcontrollers, and includes software libraries for security, connectivity and updateability. Here’s a selection of announcements from the MCU community:

Microchip PIC32MZEF MCUs Support Amazon FreeRTOS
curiosityMicrochip Technology has expanded its collaboration with Amazon Web Services (AWS) to support cloud-connected embedded systems from the node to the cloud. Microchip’s PIC32MZ EF series of microcontrollers now support Amazon FreeRTOS.

STMicro Adds Amazon FreeRTOS to its IoT MCU Tool Suit
STMicroelectronics has announced its collaboration with Amazon Web Services (AWS) on Amazon FreeRTOS, the latest addition to the AWS Internet of Things (IoT) solution.


NXP MCU IoT Card with Wi-Fi Supports Amazon FreeRTOS
OM40007-LPC54018-IoT-ModuleNXP Semiconductors has introduced the LPC54018 MCU-based IoT module with onboard Wi-Fi and support for the new Amazon FreeRTOS on Amazon Web Services (AWS), offering developers universal connections to AWS.


TI SimpleLink™ MCU platform now supports new Amazon FreeRTOS (PRNewsfoto/Texas Instruments Incorporated)

TI Integrates SimpleLink MCU Platform with Amazon FreeRTOS
Texas Instruments (TI) has announced the integration of the new Amazon FreeRTOS into the SimpleLink microcontroller platform.

NXP MCU IoT Card with Wi-Fi Supports Amazon FreeRTOS

NXP Semiconductors has introduced the LPC54018 MCU-based IoT module with onboard Wi-Fi and support for newly launched Amazon FreeRTOS on Amazon Web Services (AWS), offering developers universal connections to AWS. Amazon FreeRTOS provides tools for users to quickly and easily deploy an MCU-based connected device and develop an IoT application without having to worry about the complexity of scaling across millions of devices. Once connected, IoT device applications can take advantage of the capabilities of the cloud or continue processing data locally with AWS Greengrass.

Amazon FreeRTOS enables security-strong orchestration with the edge-cluster to further leverage low latencies in edge computing configurations, which extends AWS Greengrass core devices’ reach to the nodes. Distributed and autonomous computing architectures become possible through the consistent interface provided between the nodes and their gateways, in both online and offline scenario.

OM40007-LPC54018-IoT-ModuleNXP’s IoT module, co-developed with Embedded Artists and based on the LPC54018 MCU, offers unlimited memory extensibility, a root of trust built on the embedded SRAM physical unclonable functions (PUF) and on-chip cryptographic accelerators. Together, LPC and Amazon FreeRTOS, with easy-to-use software libraries, bring multiple layers of network transport security, simplify cloud on-boarding and over-the-air device management.

NXP enables node-to-cloud AWS connectivity with its LPC54018-based IoT module available on Amazon.com and EmbeddedArtists.com at $35 direct to consumers.

NXP Semiconductors | www.nxp.com

Microchip PIC32MZEF MCUs Support Amazon FreeRTOS

Microchip Technology has expanded its collaboration with Amazon Web Services (AWS) to support cloud-connected embedded systems from the node to the cloud. Supporting Amazon Greengrass, Amazon FreeRTOS and AWS Internet of Things (IoT), Microchip provides all the components, tools, software and support needed to rapidly develop secure cloud-connected systems.

Microchip’s PIC32MZ EF series of microcontrollers now support Amazon FreeRTOS, an operating system that makes compact low-powered edge devices easy to program, deploy, secure and maintain. These high-performance MCUs incorporate industry-leading connectivity options, ample Flash memory, rich peripherals and a robust toolchain which empower embedded designers to rapidly build complex applications. Amazon FreeRTOS includes software libraries which make it easy to securely deploy over-the-air updates as well as the ability to connect devices locally to AWS Greengrass or directly to the cloud, providing a variety of data processing location options.

For systems requiring data collection and analysis at a local level, developers can use Microchip’s SAMA5D2 series of microprocessors with integrated AWS Greengrass software. This will enable systems to run local compute, messaging, data caching and sync capabilities for connected devices in a secure way. This type of execution provides improved event response, conserves bandwidth and enables more cost-effective cloud computing. The SAMA5D2 devices, also available in System-in-Package (SiP) variants, offer full Amazon Greengrass compatibility in a low-power, small form factor MPU targeted at industrial and long-life gateway and concentrator applications. Additionally, the integrated security features and extended temperature range allows these MPUs to be deployed in physically insecure and harsh environments.

In any cloud-connected design, security and ease of use are vital pieces of the puzzle. Microchip’s ATECC608A CryptoAuthentication device enables enhanced system security as well as easy-to-use registration. The secure element provides a unique, trusted and protected identity to each device that can be securely authenticated to protect a brand’s intellectual property and revenue. In addition to enhancing system security, the ATECC608A allows AWS customers to instantly connect to the cloud through the device’s Just-in-Time-Registration (JITR) powered by AWS IoT.

curiosityMicrochip has an extensive toolchain for rapid and reliable development. The Curiosity PIC32MZ EF development board (shown), to kick-start Amazon FreeRTOS-based designs, is a fully integrated 32-bit development platform which also includes two mikroBUS expansion sockets, enabling designers to easily add additional capabilities, such as Wi-Fi with the WINC1510 click board, to their designs. The SAMA5D2 Xplained Ultra board, which can be used for AWS Greengrass designs, is a fast prototyping and evaluation platform for the SAMA5D2 series of MPUs. Additionally, the CryptoAuth Xplained Pro evaluation and development kit is an add-on board for rapid prototyping of secure solutions on AWS IoT and is compatible with any Microchip Xplained or XplainedPro evaluation boards. AWS is also a part of Microchip’s Design Partner Program which provides technical expertise and cost-effective solutions in a timely manner.

PIC32MZ EF MCUs are available starting at $5.48 each in 10,000 unit quantities. The PIC32MZ EF Curiosity board (DM320104) is available for $47.99 each. SAMA5D2 MPUs are available starting at $4.42 each in 10,000 unit quantities. The SAMA5D2 Xplained Ultra board (ATSAMA5D2C-XULT) is available for $150 each. ATECC608A secure elements are available starting at $0.56 each in 10,000 unit quantities. The CryptoAuth Xplained Pro evaluation and development kit (ATCryptoAuth-XPRO-B) is available for $10 each.

Microchip Technology | www.microchip.com

STMicro Adds Amazon FreeRTOS to its IoT MCU Tool Suite

STMicroelectronics has announced its collaboration with Amazon Web Services (AWS) on Amazon FreeRTOS, the latest addition to the AWS Internet of Things (IoT) solution. Amazon FreeRTOS provides everything one needs to easily and securely deploy microcontroller-based connected devices and develop an IoT application without having to worry about the complexity of scaling across millions of devices. Once connected, IoT device applications can take advantage of all of the capabilities the cloud has to offer or continue processing data locally with AWS Greengrass.

ST’s collaboration with AWS speeds designers’ efforts to create easily connectable IoT nodes with the combination of ST’s semiconductor building blocks and Amazon FreeRTOS, which extends the leading free and open-source real-time operating-system kernel for embedded devices (FreeRTOS) with the appropriate libraries for local networking, cloud connectivity, security, and remote software updates.

For the STM32, ST’s family of 32-bit Arm Cortex-M microcontrollers, the modular and interoperable IoT development platform spans state-of-the-art semiconductor components, ready-to-use development boards, free software tools and common application examples. At the official release of Amazon FreeRTOS, a version of the OS and libraries were immediately made available to run on the ultra-low-power STM32L4 series of microcontrollers.

The starter kit for Amazon FreeRTOS is ST’s B-L475E-IOT01A Discovery kit for IoT node, a fully integrated development board that exploits low-power communication, multiway sensing, and a raft of features provided by the STM32L4 series microcontroller to enable a wide range of IoT-capable applications. The Discovery kit’s support for Arduino Uno V3 and PMOD connectivity ensures unlimited expansion capabilities with a large choice of specialized add-on boards.

STMicroelectronics | www.st.com

TI Integrates SimpleLink MCU Platform with Amazon FreeRTOS

Texas Instruments (TI) has announced the integration of the new Amazon FreeRTOS into the SimpleLink microcontroller platform. Amazon Web Services (AWS) has worked with TI in the development of an integrated hardware and software solution that enables developers to quickly establish a connection to AWS IoT service out-of-the-box and immediately begin system development.

TI SimpleLink™ MCU platform now supports new Amazon FreeRTOS (PRNewsfoto/Texas Instruments Incorporated)

TI’s SimpleLink Wi-Fi CC3220SF wireless MCU LaunchPad development kit, which now supports Amazon FreeRTOS, offers embedded security features such as secure storage, cloning protection, secure bootloader and networking security. Developers can now take advantage of these security features to help them protect cloud-connected IoT devices from theft of intellectual property (IP) and data or other risks.

TI offers a broad portfolio of building blocks for IoT nodes and gateways spanning wired and wireless connectivity, microcontrollers, processors, sensing technology, power management and analog solutions, along with a community of cloud service providers, such as AWS, to help developers get connected to the cloud faster.

The SimpleLink MCU platform from Texas Instruments is a single development environment that delivers flexible hardware, software and tool options for customers developing Internet of Things (IoT) applications. With a single software architecture, modular development kits and free software tools for every point in the design life cycle, the SimpleLink MCU ecosystem allows 100 percent code reuse across the portfolio of microcontrollers, which supports a wide range of connectivity standards and technologies including RS-485, Bluetooth low energy, Wi-Fi, Sub-1 GHz, 6LoWPAN, Ethernet, RF4CE and proprietary radio frequencies. SimpleLink MCUs help manufacturers easily develop and seamlessly reuse resources to expand their portfolio of connected products.

Texas Instruments | www.ti.com

eMCOS Scalable POSIX-Compliant RTOS

eSOL recently released eMCOS POSIX, which is a POSIX-compliant profile for eMCOS. The eMCOS POSIX accelerates R&D and shortens product development time with Linux software assets and engineering resources, including open source software (OSS) such as the Robot Operating System (ROS) framework for robotic control and the Autoware software for autonomous driving systems.

eMCOS POSIX provides superior real-time capabilities for embedded systems that require a high level of computing power and operate on an autonomous and distributed basis. Applications include autonomous driving systems, industrial IoT systems, advanced driver assistance systems (ADAS), AI, and computer vision.

eMCOS is a POSIX-compliant RTOS that complies with POSIX 1003.13 PSE 53. It provides full support for multiple processes and threads, loadable processes, and shared libraries. It also offers a multiprocessing environment for multicore systems with distributed memory, allowing the use of POSIX inter-process communications (IPC) for communication with different scheduling clusters and hardware clusters.

Conventional RTOSs use a single kernel to manage multiple cores. In contrast, the eMCOS employs a distributed microkernel architecture with a separate microkernel installed on each core. Thus, it can support different numbers of cores as well as heterogeneous hardware configurations with a variety of device architectures (e.g., FPGAs, GPUs, and microcontrollers with on-chip flash memory). Along with eMCOS POSIX, eMCOS is made up of a number of profiles, including the eMCOS AUTOSAR profile for AUTOSAR. By selecting the appropriate profile to suit system requirements, it is easy to configure distributed systems that combine POSIX and AUTOSAR applications running on separate processors. Supported devices include the Kalray MPPAR-256 and Renesas Electronics RH850 series. Because eMCOS is not designed for particular processor architectures or instruction sets, support for other processors will be added in the future.

Source: eSOL 

Tracealyzer 3.1 Offers Support for Trace Streaming Over USB

Percepio AB recently released Tracealyzer 3.1, which is a trace tool that supports RTOS trace using just a standard USB cable. You can increase your development speed by using Tracealyzer for debugging, validation, profiling, documentation, and training. Percepio-Tracealyzer

The trace recorder library is now easier to configure for streaming over custom interfaces, and includes support for USB streaming on STM32. (It can be adapted for other microcontrollers.) USB offers excellent performance for RTOS tracing and over 600 KB/s has been measured on an STM32 using USB 2, several times more than required. Other stream ports include TCP/IP and SEGGER J-Link debug probes. Tracealyzer 3.1 can also receive trace streams via Windows COM ports (e.g., from USB CDC connections), UART connections, or any virtual COM port provided by other target interfaces.

Tracealyzer 3.1 can identify memory leaks in systems that use dynamic memory allocation. It can record memory allocation events (e.g. malloc, free) from multiple operating systems, and it can display such allocations that have not been released. Since the memory allocation events are linked to the task trace, you quickly find the context of the allocation and investigate the problem. The recorder library simplifies integration and now provides a common API for both streaming and snapshot recording.


Source: Percepio AB


Silicon Labs Acquires Micrium

Silicon Labs recently announced its acquisition of of Micrium, an RTOS software supplier. The strategic acquisition it intended to strengthen Silicon Labs’s position in the IoT market.

The following statement from Daniel Cooley, Senior Vice President and General Manager of Silicon Labs’s IoT products, was presented in a release:

IoT products are increasingly defined by software. Explosive growth of memory/processor capabilities in low-end embedded products is driving a greater need for RTOS software in connected device applications… The acquisition of Micrium means that connected device makers will have easier access to a proven embedded RTOS geared toward multiprotocol silicon, software and solutions from Silicon Labs.

Source: Silicon Labs

mbOS for MicroEJ Opens Embedded Systems to Java

SEGGER recently announced that its embOS real-time operating system now supports MicroEJ’s platform, thereby giving Java developers the ability to work on ARM Cortex-M based embedded applications. You get a complete Java platform with a virtual machine, which is a 32-bit processor that manages Java threads. It is executed as a task controlled by SEGGER’s embOS kernel . Thus, you get all the benefits of both ANSI-C and Java in a single embedded target.

Developers can focus on their Java applications and do not need to have any deeper knowledge of ANSI-C. For more information about embOS’s support for the MicroEJ Platform, visit www.segger.com/embos-microej.html.

Source: SEGGER

Embedded SOM with Linux-Based RTOS

National Instruments has introduced an embedded system-on-module (SOM) development board with integrated Linux-based real-time operating system (RTOS).NIsom

Processing power in the 2” x 3” SOM comes from a Xilinx Zync-7020 all programmable SOC running a dual core ARM Cortex-A9 at 667 MHz. A built-in, low-power Artix-7 FPGA offers 160 single-ended I/Os and Its dedicated processor I/O include Gigabit Ethernet USB 2.0 host, USB 2.0 host/device, SDHC, RS-232, and Tx/Rx. The SOM’s power requirements are typically 3 to 5 W.

The SOM integrates a validated board support package (BSP) and device drivers together with the National Instruments Linux real-time OS. The SOM board is supplied with a full suite of middleware for developing an embedded OS, custom software drivers, and other common software components.

The LabVIEW FPGA graphical development platform eliminates the need for expertise in the design approach using a hardware description language.

[Via Elektor]


Autonomous Mobile Robot (Part 2): Software & Operation

I designed a microcontroller-based mobile robot that can cruise on its own, avoid obstacles, escape from inadvertent collisions, and track a light source. In the first part of this series, I introduced my TOMBOT robot’s hardware. Now I’ll describe its software and how to achieve autonomous robot behavior.

Autonomous Behavior Model Overview
The TOMBOT is a minimalist system with just enough components to demonstrate some simple autonomous behaviors: Cruise, Escape, Avoid, and Home behaviors (see Figure 1). All the behaviors require left and right servos for maneuverability. In general, “Cruise” just keeps the robot in motion in lieu of any stimulus. “Escape” uses the bumper to sense a collision and then 180 spin with reverse. “Avoid” makes use of continuous forward looking IR sensors to veer left or right upon approaching a close obstacle. Finally “Home” utilizes the front optical photocells to provide robot self-guidance to a strong light highly directional source.

Figure 1: High-level autonomous behavior flow

Figure 2 shows more details. The diagram captures the interaction of TOMBOT hardware and software. On the left side of the diagram are the sensors, power sources, and command override (the XBee radio command input). All analog sensor inputs and bumper switches are sampled (every 100 ms automatically) during the Microchip Technology PIC32 Timer 1 interrupt. The bumper left and right switches undergo debounce using 100 ms as a timer increment. The analog sensors inputs are digitized using the PIC32’s 10-bit ADC. Each sensor is assigned its own ADC channel input. The collected data is averaged in some cases and then made available for use by the different behaviors. Processing other than averaging is done within the behavior itself.

Figure 2: Detailed TOMBOT autonomous model

All behaviors are implemented as state machines. If a behavior requests motor control, it will be internally arbitrated against all other behaviors before motor action is taken. Escape has the highest priority (the power behavior is not yet implemented) and will dominate with its state machine over all the other behaviors. If escape is not active, then avoid will dominate as a result of its IR detectors are sensing an object in front of the TOMBOT less than 8″ away. If escape and avoid are not active, then home will overtake robot steering to sense track a light source that is immediately in front of TOMBOT. Finally cruise assumes command, and takes the TOMBOT in a forward direction temporarily.

A received command from the XBee RF module can stop and start autonomous operation remotely. This is very handy for system debugging. Complete values of all sensors and battery power can be viewed on graphics display using remote command, with LEDs and buzzer, announcing remote command acceptance and execution.

Currently, the green LED is used to signal that the TOMBOT is ready to accept a command. Red is used to indicate that the TOMBOT is executing a command. The buzzer indicates that the remote command has been completed coincident with the red led turning on.

With behavior programming, there are a lot of considerations. For successful autonomous operation, calibration of the photocells and IR sensors and servos is required. The good news is that each of these behaviors can be isolated (selectively comment out prior to compile time what is not needed), so that phenomena can be isolated and the proper calibrations made. We will discuss this as we get a little bit deeper into the library API, but in general, behavior modeling itself does not require accurate modeling and is fairly robust under less than ideal conditions.

TOMBOT Software Library
The TOMBOT robot library is modular. Some experience with C programming is required to use it (see Figure 3).

Figure 3: TOMBOT Library

The entire library is written using Microchip’s PIC32 C compiler. Both the compiler and Microchip’s 8.xx IDE are available as free downloads at www.microchip.com. The overall library structure is shown. At a highest level library has three main sections: Motor, I/O and Behavior. We cover these areas in some detail.

TOMBOT Motor Library
All functions controlling the servos’ (left and right wheel) operation is contained in this part of the library (see Listing1 Motor.h). In addition the Microchip PIC32 peripheral library is also used. Motor initialization is required before any other library functions. Motor initialization starts up both left and right servo in idle position using PIC32 PWM peripherals OC3 and OC4 and the dual Timer34 (32 bits) for period setting. C Define statements are used to set pulse period and duty cycle for both left and right wheels. These defines provide PWM varies from 1 to 2 ms for different speed CCW rotation over a 20-ms period and from 1.5 ms to 1 ms for CC rotation.

Listing 1: All functions controlling the servos are in this part of the library.

V_LEFT and V_RIGHT (velocity left and right) use the PIC32 peripheral library function to set duty cycle. The other motor functions, in turn, use V_LEFT and V_RIGHT with the define statements. See FORWARD and BACKWARD functions as an example (see Listing 2).

Listing 2: Motor function code examples

In idle setting both PWM set to 1-ms center positions should cause the servos not to turn. A servo calibration process is required to ensure center position does not result in any rotation. For the servos we have a set screw that can be used to adjust motor idle to no spin activity with a small Philips screwdriver.

TOMBOT I/O Library

This is a collection of different low level library functions. Let’s deal with these by examining their files and describing the function set starting with timer (see Listing 3). It uses Timer45 combination (full 32 bits) for precision timer for behaviors. The C defines statements set the different time values. The routine is noninterrupt at this time and simply waits on timer timeout to return.

Listing 3: Low-level library functions

The next I/O library function is ADC. There are a total of five analog inputs all defined below. Each sensor definition corresponds to an integer (32-bit number) designating the specific input channel to which a sensor is connected. The five are: Right IR, Left IR, Battery, Left Photo Cell, Right Photo Cell.

The initialization function initializes the ADC peripheral for the specific channel. The read function performs a 10-bit ADC conversion and returns the result. To faciliate operation across the five sensors we use SCAN_SENSORS function. This does an initialization and conversion of each sensor in turn. The results are placed in global memory where the behavior functions can access . SCAN_SENOR also performs a running average of the last eight samples of photo cell left and right (see Listing 4).

Listing 4: SCAN_SENOR also performs a running average of the last eight samples

The next I/O library function is Graphics (see Listing 5). TOMBOT uses a 102 × 64 monchrome graphics display module that has both red and green LED backlights. There are also red and green LEDs on the module that are independently controlled. The module is driven by the PIC32 SPI2 interface and has several control lines CS –chip select, A0 –command /data.

Listing 5: The Graphics I/O library function

The Graphics display relies on the use of an 8 × 8 font stored in as a project file for character generation. Within the library there are also cursor position macros, functions to write characters or text strings, and functions to draw 32 × 32 bit maps. The library graphic primitives are shown for intialization, module control, and writing to the module. The library writes to a RAM Vmap memory area. And then from this RAM area the screen is updated using dumpVmap function. The LED and backlight controls included within these graphics library.

The next part of I/O library function is delay (see Listing 6). It is just a series of different software delays that can be used by other library function. They were only included because of legacy use with the graphics library.

Listing 6: Series of different software delays

The next I/O library function is UART-XBEE (see Listing 7). This is the serial driver to configure and transfer data through the XBee radio on the robot side. The library is fairly straightforward. It has an initialize function to set up the UART1B for 9600 8N1, transmit and receive.

Listing 7: XBee library functions

Transmission is done one character at a time. Reception is done via interrupt service routine, where the received character is retrieved and a semaphore flag is set. For this communication, I use a Sparkfun XBee Dongle configured through USB as a COM port and then run HyperTerminal or an equivalent application on PC. The default setting for XBee is all that is required (see Photo 1).

Photo 1: XBee PC to TOMBOT communications

The next I/O library function is buzzer (see Listing 8). It uses a simple digital output (Port F bit 1) to control a buzzer. The functions are initializing buzzer control and then the on/off buzzer.

Listing 8: The functions initialize buzzer control

TOMBOT Behavior Library
The Behavior library is the heart of the autonomous TOMBOT and where integrated behavior happens. All of these behaviors require the use of left and right servos for autonomous maneuverability. Each behavior is a finite state machine that interacts with the environment (every 0.1 s). All behaviors have a designated priority relative to the wheel operation. These priorities are resolved by the arbiter for final wheel activation. Listing 9 shows the API for the entire Behavior Library.

Listing 9: The API for the entire behavior library

Let’s briefly cover the specifics.

  • “Cruise” just keeps the robot in motion in lieu of any stimulus.
  • “Escape” uses the bumper to sense a collision and then 180° spin with reverse.
  • “Avoid” makes use of continuous forward looking IR sensors to veer left or right upon approaching a close obstacle.
  • “Home” utilizes the front optical photocells to provide robot self-guidance to a strong light highly directional source.
  • “Remote operation” allows for the TOMBOT to respond to the PC via XBee communications to enter/exit autonomous mode, report status, or execute a predetermined motion scenario (i.e., Spin X times, run back and forth X times, etc.).
  • “Dump” is an internal function that is used within Remote.
  • “Arbiter” is an internal function that is an intrinsic part of the behavior library that resolves different behavior priorities for wheel activation.

Here’s an example of the Main function-invoking different Behavior using API (see Listing 10). Note that this is part of a main loop. Behaviors can be called within a main loop or “Stacked Up”. You can remove or stack up behaviors as you choose ( simply comment out what you don’t need and recompile). Keep in mind that remote is a way for a remote operator to control operation or view status.

Listing 10: TOMBOT API Example

Let’s now examine the detailed state machine associated with each behavior to gain a better understanding of behavior operation (see Listing 11).

Listing 11:The TOMBOT’s arbiter

The arbiter is simple for TOMBOT. It is a fixed arbiter. If either during escape or avoid, it abdicates to those behaviors and lets them resolve motor control internally. Home or cruise motor control requests are handled directly by the arbiter (see Listing 12).

Listing 12: Home behavior

Home is still being debugged and is not yet a final product. The goal is for the TOMBOT during Home is to steer the robot toward a strong light source when not engaged in higher priority behaviors.

The Cruise behavior sets motor to forward operation for one second if no other higher priority behaviors are active (see Listing 13).

Listing 13: Cruise behavior

The Escape behavior tests the bumper switch state to determine if a bump is detected (see Listing 14). Once detected it runs through a series of states. The first is an immediate backup, and then it turns around and moves away from obstacle.

Listing 14: Escape behavior

This function is a response to the remote C or capture command that formats and dumps (see Listing 15) to the graphics display The IR left and right, Photo left and Right, and battery in floating point format.

Listing 15: The dump function

This behavior uses the IR sensors and determines if an object is within 8″ of the front of TOMBOT (see Listing 16).

Listing 16: Avoid behavior

If both sensors detect a target within 8″ then it just turns around and moves away (pretty much like escape). If only the right sensor detects an object in range spins away from right side else if on left spins away on left side (see Listing 17).

Listing 17: Remote part 1

Remote behavior is fairly comprehensive (see Listing 18). There are 14 different cases. Each case is driven by a different XBee received radio character. Once a character is received the red LED is turned on. Once the behavior is complete, the red LED is turned off and a buzzer is sounded.

Listing 18: Remote part 2

The first case toggles Autonomous mode on and off. The other 13 are prescribed actions. Seven of these 13 were written to demonstrate TOMBOT mobile agility with multiple spins, back and forwards. The final six of the 13 are standard single step debug like stop, backward, and capture. Capture dumps all sensor output to the display screen (see Table 1).

Table 1: TOMBOT remote commands

Early Findings & Implementation
Implementation always presents a choice. In my particular case, I was interested in rapid development. At that time, I selected to using non interrupt code and just have linear flow of code for easy debug. This amounts to “blocking code.” Block code is used throughout the behavior implementation and causes the robot to be nonresponsive when blocking occurs. All blocking is identified when timeout functions occur. Here the robot is “blind” to outside environmental conditions. Using a real-time operating system (e.g., Free RTOS) to eliminate this problem is recommended.

The TOMBOT also uses photocells for homing. These sensitive devices have different responses and need to be calibrated to ensure correct response. A photocell calibration is needed within the baseline and used prior to operation.


The TOMBOT was successfully demoed to a large first-grade class in southern California as part of a Science, Technology, Engineering and Mathematics (STEM) program. The main behaviors were limited to Remote, Avoid, and Escape. With autonomous operation off, the robot demonstrated mobility and maneuverability. With autonomous operation on, the robot could interact with a student to demo avoid and escape behavior.

Tom Kibalo holds a BSEE from City College of New York and an MSEE from the University of Maryland. He as 39 years of engineering experience with a number of companies in the Washington, DC area. Tom is an adjunct EE facility member for local community college, and he is president of Kibacorp, a Microchip Design Partner.