Rapid prototyping for MCUs

By Chris Edwards |  No Comments  |  Posted: December 1, 2009
Topics/Categories: Embedded - Integration & Debug  |  Tags: , ,

The increasing capability and performance of microcontrollers suggests that they can now reach markets for which they were never previously envisioned, particularly as 32-bit devices move into the mainstream.

However, prototyping and even researching new application spaces is difficult with existing tools. These are highly optimized for existing uses, but as such very unwieldy when used to explore new ones.

In response, ARM and NXP have developed mbed, an online/USB-based rapid prototyping technology. Its features and use are described in the article, and some illustration of how it can be used to get an initial take on a potential new market is provided.

Microcontrollers (MCUs) are getting smaller, becoming more powerful, consuming less energy, and adding more connectivity, yet the prices keep falling. All this progress potentially opens up huge opportunities in markets where MCUs were not previously seen as an option.

The keys to exploiting those opportunities will be the tools available to help identify new applications and then build from proof-of-concept prototypes through to highly profitable products. This sounds easy enough. But while we have excellent tools for productizing MCU designs where the target is known from the get-go, even experienced engineers often find it too risky or time-consuming to try to prove a concept or define a specification from the ground up.

The result is that new ideas do not get explored and there is little iteration or design space exploration so that the prototype becomes the final design with a specification that is overly cautious. Given that in many cases other observations and insights that would help define and enhance these applications would be coming from engineers in other problem domains, these limitations are amplified.

It is partly in response to this problem that microprocessor specialist ARM and semiconductor group NXP have launched mbed, a rapid prototyping service aimed at allowing engineers to uncover new market opportunities in a timely and cost-effective manner.

Source: ARM/NXP

eda0912_armnxp1.ai

FIGURE 1 The mbed strategy

Strategy

The underlying goal of mbed is to enable the efficient evaluation of 32-bit MCU capabilities and prototyping for various applications to which they might be applied. Doing this efficiently is achieved via a strategy that works through technologies and trade-offs that can optimize the time to get to a working prototype rather than immediately plunging into the complexity of optimizing the design itself.

For example, the trend in microcontrollers is toward increasing performance and memory capacity for a fixed price. While most tools focus on enabling users to exploit this in the end capability of the applications that can be created, mbed instead focuses on using this performance and capacity to reduce the design challenge (Figure 1). A good example is the use of high-level abstractions to make the functionality accessible at the cost of implementation efficiency and increased code size.

Another key objective is to overcome barriers to entry. As defined by Fred Davis and Richard Bagozzi, the Technology Acceptance Model (Figure 2) provides a clear framework to achieve this, highlighting concepts such as ‘perceived usefulness’ and ‘ease of use’.

Perceived usefulness was defined by Davis as “the degree to which a person believes that using a particular system would enhance his or her job performance.” It is driven by insights into a technology, gained through experimentation and education. In this context, the mbed prototyping approach naturally supports user exploration, while making it easy for both marketing and application engineering professionals to demonstrate and showcase the technology.

Source: Davis et al., 89

eda0912_armnxp2.ai

FIGURE 2 Technology acceptance

Davis defined ease of use as “the degree to which a person believes that using a particular system would be free from effort.” As a result, this concept is very dependent on context: most good tools are easy to use for the task they were intended. But for a different task, the results are unlikely to be the same. By defining clearly the context of rapid prototyping, it becomes much more meaningful to make design trade-offs focused on notions of ease of use.

Remember, any MCU developer in the industry is likely to be familiar with an existing proprietary architecture and tool chain, and change can appear daunting. Simply making an engineer feel as though he is about to go from ‘expert’ to ‘learner’ can be enough to make him avoid exploring the benefits of moving to a modern solution. For a new user, the fear, uncertainty and doubt can be equally prohibitive.

This makes the user’s initial experience with the tools critical. They must deliver sound results quickly and with little investment or difficulty.

Getting started

Consequently, an important objective in mbed’s development was that a new user should be able to run a first program as quickly as possible, thus building confidence and trust in the hardware and software tool chain. The mbed tools have applied some novel technology to achieve this, and the results speak for themselves; you can get started in 60 seconds.

Two innovations fuel this rapid execution time: the presence of a USB drive-based programmer on the hardware, and access to compiler tools as cloud-computing-based applications that run in a Web browser. These solutions have some obvious benefits, but also some that might not be immediately apparent. Let’s consider the first group.

  1. There is nothing to set up or install. At the most basic level, this offers instant access without any administrative duties. However, for those using locked-down computer systems (as found in many colleges, universities and offices), this feature could make the difference between being able to test out an MCU and not.
  2. The IDE is simple but functional, and briskly gets on with the job of editing and compiling code. Everything is preconfigured so that it will work out-of-the-box on any platform—PC, Mac or Linux. Users can have confidence that the tools will be there, ready to use whenever they need them or to run a demonstration.
  3. The online cloud computing features mean that you can access your workspace from anywhere and on any machine. You no longer need to manage and synchronize multiple installations if, as is increasingly the case, you work from several different computers. So, an engineer or student may resume his work at home picking up from exactly where he was at work or university. An obvious analogy here is how we already taken universal webmail access for granted.

But what about those more subtle advantages?

  1. There are the decisions you don’t have to make, because the options and configurations that will give the most appropriate results for the task have been identified already.
  2. The tools are so lightweight that you can login from any machine, create a project from scratch and run tests in a matter of minutes, or approach any modifications in the same way. Such flexibility can have a significant impact on working style. Having a simplified setup means everything is easily reproduced.
  3. Combined with the single hardware and library model, every other mbed developer works in an identical environment. That makes community support much easier, as people can share problems and questions within a common context.

Rapid prototyping

The mbed MCU hardware packages an NXP LPC1768 device, support components and smart USB interface in a practical 40-pin 0.1” pitch DIP form factor, ideal for experiments involving solderless breadboard, stripboard and through-hole PCBs. To support the exposed interfaces, an mbed C/C++ library provides high-level interfaces to MCU peripherals, enabling a compact, API-driven approach to coding. The combination gives immediate connectivity to peripherals and modules for prototyping and subsequent iterations of MCU-based system designs. Figure 3 shows the basic mbed pinout, including the availability and location of the interface resources.

Source: ARM/NXP

Interface

Function

DigitalIn

DigitalOut

DigitalInOut

InterruptIn

AnalogIn

AnalogOut

PwmOut

Serial

SPI

12C

CAN

Ethernet

Timer

Ticker

Timeout

Read the state of a digital input pin

Write the state of a digital output pin

Read and write a bi-directional digital pin

Trigger a function on a pin rising/falling edge

Read the voltage on an analog input pin

Control the voltage on an analog output pin

Control a pulse-width modulation output pin

Communicate with serial (UART) devices

Communicate with SPI slave devices

Communicate with 12C slave devices

Communicate on a CAN bus

Read and write Ethernet packets

A general purpose timer

Call a function at a recurring interval

Call a function at a point in the future

TABLE 1 The mbed Library interfaces

The interfaces indicated match those found in the mbed Library (Table 1). This highlights some of the key benefits of their being developed together. The API provides an abstract peripheral interface, rather than one that is implementation specific. The libraries use object orientation that maps well to tangible physical hardware resources. The hardware, libraries and documentation share the same naming and concepts for interfaces.

The alignment between hardware and software is meant to enable a natural programming style that captures intent, essential for fast experiments and iteration. For example, mbed avoids requiring the multiple levels of indirection that are usually needed for pinout and resource allocation. These tend to lose meaning and introduce bugs.

The following example demonstrates how you could set up an SPI master interface:

#include “mbed.h”

SPI myspi(p5, p6, p7); // mosi, miso, sclk

int main() {

// Setup 9-bit SPI @ 1MHz

myspi.frequency(1000000);

myspi.format(9);

int response = myspi.write(0x8F);

}

First, an SPI object has been created and tied to the desired pins (‘mosi’, ‘miso’, and ‘sclk’) as seen in Figure 3. Notice that this expression could be equally useful when it comes to physically wiring up the device—the specification has captured the physical connectivity.

Source: ARM/NXP

eda0912_armnxp3.ai

FIGURE 3 The mbed microcontroller pinout

Next, the frequency and bit format of the SPI object (myspi) has been configured, before performing a write/read transaction. The methods on the SPI object are well defined, making the interface intuitive, and the operations are independent of the low-level settings or requirements of the underlying hardware. In fact, to change the SPI port being used in this example, only the pin names would need to be changed. This helps separate modification of the physical aspects of a design (the resources used and how they are pinned out) from the control (what they do).

Here is a similar example where we have captured intent:

#include “mbed.h”

InterruptIn button(p5);

DigitalOut led(LED1);

void flip() {

led = !led;

}

int main() {

button.rise(&flip); // attach flip to p5 edge

while(1); // hang around forever

}

In this case, a function is set up to be called every time a rising edge interrupt occurs on a digital input pin. Interrupts are a simple concept, but are notoriously complex to set up and get functioning correctly.

With mbed, the code is conceptually very simple; create a pin that can generate interrupts, and attach a function to the rising edge of that pin. The library is built using these approaches throughout, allowing developers to concentrate on application logic rather than implementation details.

The mbed Library is built on top of the low-level ARM Cortex Microcontroller Software Interface Standard (CMSIS), a vendor-independent hardware abstraction layer for the Cortex-M processor series (Figure 4).

In contrast to CMSIS, the mbed Library provides a very high-level API, focused on providing abstract interfaces for the basic control of peripherals. This structure provides a natural way for users to benefit from the mbed Library wherever they can, while allowing them to add bespoke code built on CMSIS where they need to support functionality not provided. In particular, this allows the user to concentrate effort on the critical or differentiated aspects of a prototype. In addition to the mbed Library, the mbed Community peripheral libraries provide an expanding base of contributed code for controlling peripherals that can be connected to the MCU (e.g., sensors, actuators, LCDs, etc.). These are usually built on top of the mbed Library, and enable systems to be connected quickly, focusing on the logic and functionality rather than the drivers. Anyone in the mbed community can contribute to these libraries, and will be expanded with middleware from third-party vendors over time.

Source: ARM/NXP

eda0912_armnxp5.ai

FIGURE 4 The mbed Library architecture

Application example

To demonstrate how easily a simple experiment can be realized with mbed, the following example shows a hardware device that is controlled by an Internet database. The program implements a system that displays a message on a screen and moves a servo motor based on the result of the HTTP request.

#include “mbed.h”

#include “HTTPClient.h”

#include “MobileLCD.h”

MobileLCD lcd(p5, p7, p8, p9); // SPI LCD

HTTPClient http; // Ethernet client

PwmOut servo(p21); // R/C Servo

int main() {

servo.period(0.020); // 20ms servo period

char result[128];

while(1) {

http.get(“http://a.com/stat.php”, result);

lcd.printf(“The status is %sn”, result);

// position the servo, 1-2ms pulsewidth

float percent = atof(result);

servo.pulsewidth(0.001 + 0.001 * percent);

wait(60); // update every minute

}

}

The solution is unlikely to be optimal, robust or complete, but what matters is that it is enough to prove the fundamental concept. The prototype may enable iteration of hardware, early development of the Internet application, exploration of new markets, or provide the case for committing to a project. By enabling an accessible way to test ideas, mbed helps reduce the risk associated with product development, and gets advanced MCUs designed into more applications more often.

Conclusion

Its focus on rapid prototyping gives mbed a broad appeal. For engineers new to target applications, mbed will enable them to experiment and test product ideas for the first time. For experienced engineers, mbed provides a way to be more productive in the proof-of-concept stages of development. And for marketing, distributors and application engineers, mbed provides a consistent platform for the demonstration, evaluation and support of MCUs. As a result, the mbed tools will help a diverse audience exploit the opportunities presented by advanced microcontrollers like the NXP LPC1768.

ARM

110 Fulbourn Road

Cambridge

CB1 9NJ

UK

T: (44) 01223 400400

W: www.arm.com

Comments are closed.

PLATINUM SPONSORS

Synopsys Cadence Design Systems Mentor - A Siemens Business
View All Sponsors