How to Support 10,000 Devices

The low-level code available from MCU providers is increasing in sophistication and, in some cases, is capable of providing a foundation for multi-task systems, as Microchip's Harmony framework illustrates.

The number of choices facing embedded developers seeking to establish the hardware platform for their next project is staggering. Most MCU providers offer a collection of different device families, and each of these families may incorporate hundreds of part numbers. Clear evidence of the vastness of the MCU pool was given recently by longtime Micrium partner IAR Systems, with the announcement that the popular Embedded Workbench IDE has achieved a new milestone: it now supports over 10,000 devices.

Viewed in most lights, the availability of a massive quantity of different MCUs is a major plus for the embedded systems field. In theory, at least, it enables developers to pick a hardware platform that offers processing power and I/O capabilities perfectly tuned to the needs of their project, thereby reducing the tendency, on the one hand, to spend too much money on an excessively powerful chip, and, on the other, to opt for a cheap but ill-equipped part that forces its users to resort to all sorts of programming acrobatics to attempt to meet challenging requirements. This flexibility, though, is not without its negative consequences, particularly in the realm of low-level software support.

To RTOS vendors like Micrium, the release of an MCU can be something of a double-edged sword. A new MCU represents an additional platform via which developers could leverage the capability of a quality RTOS, but only if sufficient low-level software, in the form of a kernel port and BSP, is available. Of course, as a company consisting primarily of software engineers, Micrium can certainly develop such software for a single platform—but not for 10,000. How, then, do we at Micrium ensure that developers interested in running our software have the widest possible selection of hardware platforms from which to choose? Much like IAR, we get by with a little help from our friends.

Most MCU providers are well aware of the need for low-level software that their products create. Accordingly, many of these companies offer complete sets of drivers for the numerous peripheral devices existing on their chips. Such drivers are regularly leveraged by tool vendors, like IAR, in the example code they provide, and they can also be found in projects from Micrium.

It was once the case that the use of code from hardware providers in an RTOS-based project was not a very appealing proposition. At the time, the drivers furnished with an MCU were usually not written to be run in a multi-tasking environment, so special measures, often including modification of the code, had to be taken in order to use the drivers effectively. (Such modifications were the subject of an article that I wrote for IAR's newsletter a few years ago.) The time and effort that MCU providers devote to their drivers and BSP code seem to have increased dramatically over the past few years, however, and it is now commonplace for this code to include provisions for use in multi-task applications. A perfect example is the Harmony software framework now available from Microchip.

Harmony is a collection of not just drivers, but also a variety of protocol stacks and even RTOSes, including Micrium's µC/OS-II and µC/OS-III. The idea behind the collection, and the motivation for its name, is that all of these software components should run together, without need for the sort of modifications that were once required to use hardware providers' low-level code with an RTOS. To enable the components of Harmony to operate smoothly alongside one another, Microchip developed an operating system abstraction layer (OSAL) that provides a common interface for leveraging RTOS services. As the below diagram shows, this interface is used only within the Harmony components themselves. In other words, at the application level, developers make calls to familiar RTOS and driver API functions without worrying about the mechanisms that ensure the peaceful coexistence of the underlying modules.

harmony_stack

While the OSAL frees developers from low-level software compatibility concerns, another part of Harmony, the MPLAB Harmony Configurator (MHC) substantially reduces the amount of work required to configure software components and add them to a new project. With MHC, a complete and fully configured RTOS-based project, incorporating numerous different drivers for peripheral devices, can be put together from scratch in just a matter of minutes. As indicated by the below screenshot, the tool provides a simple and intuitive interface through which parameters pertaining to various software features and services can be configured.

harmony_config

A package like Harmony can be a major asset to an embedded developer facing a new project. Although we take great pride in our ability to write quality software at Micrium, it's simply impossible for us to write low-level code for every peripheral on each of the thousands of MCUs currently available, and Harmony helps us to extend our reach. It presents developers with a streamlined approach to using either µC/OS-II or µC/OS-III alongside a wide variety of drivers that were written by experts in the underlying hardware. If you're interested in starting a new project in the Harmony environment, then we highly recommend that you consult the µC/OS-III for Harmony tutorial available on the Micrium web site. This document provides all of the information you'll need to lay the foundation for a Microchip-based project that leverages the proven multi-tasking capabilities of Micrium's software.

Tags: , ,

Questions or Comments?

Have a question or a suggestion for a future article?
Don't hesitate to contact us and let us know!
All comments and ideas are welcome.