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.

TOMBOT Demo

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.

Tech Highlights from Design West: RL78, AndroPod, Stellaris, mbed, & more

The Embedded Systems Conference has always been a top venue for studying, discussing, and handling the embedded industry’s newest leading-edge technologies. This year in San Jose, CA, I walked the floor looking for the tech Circuit Cellar and Elektor members would love to get their hands on and implement in novel projects. Here I review some of the hundreds of interesting products and systems at Design West 2012.

RENESAS

Renesas launched the RL78 Design Challenge at Design West. The following novel RL78 applications were particularly intriguing.

  • An RL78 L12 MCU powered by a lemon:

    A lemon powers the RL78 (Photo: Circuit Cellar)

  • An RL78 kit used for motor control:

    The RL78 used for motor control (Photo: Circuit Cellar)

  • An RL78 demo for home control applications:

    The RL78 used for home control (Photo: Circuit Cellar)

TEXAS INSTRUMENTS

Circuit Cellar members have used TI products in countless applications. Below are two interesting TI Cortex-based designs

A Cortex-M3 digital guitar (you can see the Android connection):

TI's digital guitar (Photo: Circuit Cellar)

Stellaris fans will be happy to see the Stellaris ARM Cortex -M4F in a small wireless application:

The Stellaris goes wireless (Photo: Circuit Cellar)

NXP mbed

Due to the success of the recent NXP mbed Design Challenge, I stopped at the mbed station to see what exciting technologies our NXP friends were exhibiting. They didn’t disappoint. Check out the mbed-based slingshot developed for playing Angry Birds!

mbed-Based sligshot for going after "Angry Birds" (Photo: Circuit Cellar)

Below is a video of the project on the mbedmicro YouTube page:

FTDI

I was pleased to see the Elektor AndroPod hard at work at the FTDI booth. The design enables users to easily control a robotic arm with Android smartphones and tablets.

FTDI demonstrates robot control with Android (Photo: Circuit Cellar)

As you can imagine, the possible applications are endless.

The AndroPod at work! (Photo: Circuit Cellar)

Design West Update: Compilers Unveiled

IAR Systems announced Tuesday at Design West in San Jose, CA, that GainSpan selected IAR Embedded Workbench as its primary development tool chain for MCU drivers and next-generation chip. “By standardizing on IAR Systems’ embedded software development tool chain, GainSpan will more easily support a wide range of MCUs to communicate with their modules,” IAR publicized a in a release.

It’s an important aspect of a larger plan, IAR’s ARM Strategic Accounts Manager Mike Skrtic said. IAR has overall tool chain standardization goals aimed at giving designers’ more flexibility when choosing MCUs for product development.

Remember: IAR Systems is teamed with Renesas for the RL78 Green Energy Challenge, which is administered by Circuit Cellar and Elektor. Designers are challenged to transform how the world experiences energy efficiency by developing a unique, low-power application using the RL78 MCU and IAR toolchain.

In other compiler-related news, Microchip Technology announced Monday at Design West its new MPLAB XC C compiler line, which supports its approximately 900 microcontrollers. Microchip’s Joe Drzewiecki said the compilers reduce code size by about 35% and improve code execution speed by about 30%. But you can judge for yourself because Microchip offers 8-, 16-, and 32-bit free editions of MPLAB XC compilers. According to Microchip reps, they are” fully functional and have no license restrictions for commercial use.”

So, if you give MPLAB XC a try, let us know what you think!