Tag Archives: microcontroller

Do Small-RAM Devices Have a Future? (CC 25th Anniversary Preview)

Posted on by

What does the future hold for small-RAM microcontrollers? Will there be any reason to put up with the constraints of parts that have little RAM, no floating point, and 8-bit registers? The answer matters to engineers who have spent years programming small-RAM MCUs. It also matters to designers who are hoping to keep their skills relevant as their careers progress in the 21st century.

In the upcoming Circuit Cellar 25th Anniversary Issue—which is slated for publication in early 2013—University of Utah professor John Regehr shares his thoughts on the future of small-RAM devices. He writes:

For the last several decades, the role of small-RAM microcontrollers has been clear: they are used to perform fixed (though sometimes very sophisticated) functionality in environments where cost, power consumption, and size need to be minimized. They exploit the low marginal cost of additional transistors to integrate volatile RAM, nonvolatile RAM, and numerous peripherals into the same package as the processor core, providing a huge amount of functionality in a small, cheap package. Something that is less clear is the future of small-RAM microcontrollers. The same fabrication economics that make it possible to put numerous peripherals on a single die also permit RAM to be added at little cost. This was brought home to me recently when I started using Raspberry Pi boards in my embedded software class at the University of Utah. These cost $25 to $35 and run a full-sized Linux distribution including GCC, X Windows, Python, and everything else—all on a system-on-chip with 256 MB of RAM that probably costs a few dollars in quantity.

We might ask: Given that it is already the case that a Raspberry Pi costs about the same as an Arduino board, in the future will there be any reason to put up with the constraints of an architecture like Atmel’s AVR, where we have little RAM, no floating point, and 8-bit registers? The answer matters to those of us who enjoy programming small-RAM MCUs and who have spent years fine-tuning our skills to do so. It also matters to those of us who hope to keep our skills relevant through the middle of the 21st century. Can we keep writing C code, or do we need to start learning Java, Python, and Haskell? Can we keep writing stand-alone “while (true)” loops, or will every little MCU support a pile of virtual machines, each with its own OS?

Long & Short Term

In the short term, it is clear that inertia will keep the small-RAM parts around, though increasingly they will be of the more compiler-friendly varieties, such as AVR and MSP430, as opposed to earlier instruction sets like Z80, HC11, and their descendants. But will small-RAM microcontrollers exist in the longer term (e.g., 25 or 50 years)? I’ll attempt to tackle this question by separately discussing the two things that make small-RAM parts attractive today: their low cost and their simplicity.

If we assume a cost model where packaging and soldering costs are fixed but the marginal cost of a transistor (not only in terms of fabrication, but also in terms of power consumption) continues to drop, then small-RAM parts will eventually disappear. In this case, several decades from now even the lowliest eight-pin package, costing a few pennies, will contain a massive amount of RAM and will be capable of running a code base containing billions of lines…

Circuit Cellar’s Circuit Cellar 25th Anniversary Issue will be available in early 2013. Stay tuned for more updates on the issue’s content.

CC269: Break Through Designer’s Block

Posted on by

Are you experiencing designer’s block? Having a hard time starting a new project? You aren’t alone. After more than 11 months of designing and programming (which invariably involved numerous successes and failures), many engineers are simply spent. But don’t worry. Just like every other year, new projects are just around the corner. Sooner or later you’ll regain your energy and find yourself back in action. Plus, we’re here to give you a boost. The December issue (Circuit Cellar 269) is packed with projects that are sure to inspire your next flurry of innovation.

Turn to page 16 to learn how Dan Karmann built the “EBikeMeter” Atmel ATmega328-P-based bicycle computer. He details the hardware and firmware, as well as the assembly process. The monitoring/logging system can acquire and display data such as Speed/Distance, Power, and Recent Log Files.

The Atmel ATmega328-P-based “EBikeMeter” is mounted on the bike’s handlebar.

Another  interesting project is Joe Pfeiffer’s bell ringer system (p. 26). Although the design is intended for generating sound effects in a theater, you can build a similar system for any number of other uses.

You probably don’t have to be coerced into getting excited about a home control project. Most engineers love them. Check out Scott Weber’s garage door control system (p. 34), which features a MikroElektronika RFid Reader. He built it around a Microchip Technology PIC18F2221.

The reader is connected to a breadboard that reads the data and clock signals. It’s built with two chips—the Microchip 28-pin PIC and the eight-pin DS1487 driver shown above it—to connect it to the network for testing. (Source: S. Weber, CC269)

Once considered a hobby part, Arduino is now implemented in countless innovative ways by professional engineers like Ed Nisley. Read Ed’s article before you start your next Arduino-related project (p. 44). He covers the essential, but often overlooked, topic of the Arduino’s built-in power supply.

A heatsink epoxied atop the linear regulator on this Arduino MEGA board helped reduce the operating temperature to a comfortable level. This is certainly not recommended engineering practice, but it’s an acceptable hack. (Source: E. Nisley, CC269)

Need to extract a signal in a noisy environment? Consider a lock-in amplifier. On page 50, Robert Lacoste describes synchronous detection, which is a useful way to extract a signal.

This month, Bob Japenga continues his series, “Concurrency in Embedded Systems” (p. 58). He covers “the mechanisms to create concurrently in your software through processes and threads.”

On page 64, George Novacek presents the second article in his series, “Product Reliability.” He explains the importance of failure rate data and how to use the information.

Jeff Bachiochi wraps up the issue with a article about using heat to power up electronic devices (p. 68). Fire and a Peltier device can save the day when you need to charge a cell phone!

Set aside time to carefully study the prize-winning projects from the Reneas RL78 Green Energy Challenge (p. 30). Among the noteworthy designs are an electrostatic cleaning robot and a solar energy-harvesting system.

Lastly, I want to take the opportunity to thank Steve Ciarcia for bringing the electrical engineering community 25 years of innovative projects, essential content, and industry insight. Since 1988, he’s devoted himself to the pursuit of EE innovation and publishing excellence, and we’re all better off for it. I encourage you to read Steve’s final “Priority Interrupt” editorial on page 80. I’m sure you’ll agree that there’s no better way to begin the next 25 years of innovation than by taking a moment to understand and celebrate our past. Thanks, Steve.

Microcontroller-Based Markov Music Box

Posted on by

Check out the spectrogram for two FM notes produced by FM modulation. Red indicates higher energy at a given time and frequency.

Cornell University senior lecturer Bruce Land had two reasons for developing an Atmel AVR micrcontroller-based music box. One, he wanted to present synthesis/sequencing algorithms to his students. And two, he wanted the challenge of creating an interactive music box. Interactive audio is becoming an increasingly popular topic among engineers and designers, as we recently reported.

Land writes:

Traditional music boxes play one or two tunes very well, but are not very interactive. Put differently, they have a high quality of synthesis, but a fixed-pattern note sequencer and fixed tonal quality. I wanted to build a device which would play an interesting music-like note sequence, which constantly changed and evolved, with settable timbre, tempo, and beat… To synthesize nice sounding musical notes you need to control spectral content of the note, the rise time (attack), fall time (decay), and the change in spectral content during attack and decay.  Also it is nice to have at least two independent musical voices. And all of this has to be done using the modest arithmetic capability of an 8-bit microcontroller.

Land’s students subsequently used the music box for other projects, such as an auto-composing piano, as shown in the following video.

In early 2013 Circuit Cellar will run Land’s in-depth article on the Markov music box project. Stay tuned for more information.

Embedded Security Tips (CC 25th Anniversary Preview)

Posted on by

Every few days we you a sneak peek at some of the exciting content that will run in Circuit Cellar‘s Anniversary issue, which is scheduled to be available in early 2013. You’ve read about Ed Nisley’s essay on his most memorable designs—from a hand-held scanner project to an Arduino-based NiMH cell tester—and Robert Lacoste’s tips for preventing embedded design errors. Now it’s time for another preview.

Many engineers know they are building electronic systems for use in dangerous times. They must plan for both hardware and software attacks, which makes embedded security a hot topic for 2013.  In an essay on embedded security risks, Virginia Tech professor Patrick Schaumont looks at the current state of affairs through several examples. His tips and suggestions will help you evaluate the security needs of your next embedded design.

Schaumont writes:

As design engineers, we should understand what can and what cannot be done. If we understand the risks, we can create designs that give the best possible protection at a given level of complexity. Think about the following four observations before you start designing an embedded security implementation.

First, you have to understand the threats that you are facing. If you don’t have a threat model, it makes no sense to design a protection—there’s no threat! A threat model for an embedded system will specify what can attacker can and cannot do. Can she probe components? Control the power supply? Control the inputs of the design? The more precisely you specify the threats, the more robust your defenses will be. Realize that perfect security does not exist, so it doesn’t make sense to try to achieve it. Instead, focus on the threats you are willing to deal with.

Second, make a distinction between what you trust and what you cannot trust. In terms of building protections, you only need to worry about what you don’t trust. The boundary between what you trust and what you don’t trust is suitably called the trust boundary. While trust boundaries where originally logical boundaries in software systems, they also have a physical meaning in embedded context. For example, let’s say that you define the trust boundary to be at the chip-package level of a microcontroller. This implies that you’re assuming an attacker will get as close to the chip as the package pins, but not closer. With such a trust boundary, your defenses should focus on off-chip communication. If there’s nothing or no one to trust, then you’re in trouble. It’s not possible to build a secure solution without trust.

Third, security has a cost. You cannot get it for free. Security has a cost in resources and energy. In a resource-limited embedded system, this means that security will always be in competition with other system features in terms of resources. And because security is typically designed to prevent bad things from happening rather than to enable good things, it may be a difficult trade-off. In feature-rich consumer devices, security may not be a feature for which a customer is willing to pay extra.

The fourth observation, and maybe the most important one, is to realize is that you’re not alone. There are many things to learn from conferences, books, and magazines. Don’t invent your own security. Adapt standards and proven Circuit Cellar’s Circuit Cellar 25th Anniversary Issue will be available in early 2013. Stay tuned for more updates on the issue’s content.techniques. Learn about the experiences of other designers.

Schaumont then provides lists of helpful embedded security-related resources, such as Flylogic’s Analytics Blog and the Athena website at GMU.

Prevent Embedded Design Errors (CC 25th Anniversary Preview)

Posted on by

Attention, electrical engineers and programmers! Our upcoming 25th Anniversary Issue (available in early 2013) isn’t solely a look back at the history of this publication. Sure, we cover a bit of history. But the issue also features design tips, projects, interviews, and essays on topics ranging from user interface (UI) tips for designers to the future of small RAM devices, FPGAs, and 8-bit chips.

Circuit Cellar’s 25th Anniversary issue … coming in early 2013

Circuit Cellar columnist Robert Lacoste is one of the engineers whose essay will focus on present-day design tips. He explains that electrical engineering projects such as mixed-signal designs can be tedious, tricky, and exhausting. In his essay, Lacoste details 25 errors that once made will surely complicate (at best) or ruin (at worst) an embedded design project. Below are some examples and tips.

Thinking about bringing an electronics design to market? Lacoste highlights a common error many designers make.

Error 3: Not Anticipating Regulatory Constraints

Another common error is forgetting to plan for regulatory requirements from day one. Unless you’re working on a prototype that won’t ever leave your lab, there is a high probability that you will need to comply with some regulations. FCC and CE are the most common, but you’ll also find local regulations as well as product-class requirements for a broad range of products, from toys to safety devices to motor-based machines. (Refer to my article, “CE Marking in a Nutshell,” in Circuit Cellar 257 for more information.)

Let’s say you design a wireless gizmo with the U.S. market and later find that your customers want to use it in Europe. This means you lose years of work, as well as profits, because you overlooked your customers’ needs and the regulations in place in different locals.

When designing a wireless gizmo that will be used outside the U.S., having adequate information from the start will help you make good decisions. An example would be selecting a worldwide-enabled band like the ubiquitous 2.4 GHz. Similarly, don’t forget that EMC/ESD regulations require that nearly all inputs and outputs should be protected against surge transients. If you forget this, your beautiful, expensive prototype may not survive its first day at the test lab.

Watch out for errors

Here’s another common error that could derail a project. Lacoste writes:

Error 10: You Order Only One Set of Parts Before PCB Design

I love this one because I’ve done it plenty of times even though I knew the risk.

Let’s say you design your schematic, route your PCB, manufacture or order the PCB, and then order the parts to populate it. But soon thereafter you discover one of the following situations: You find that some of the required parts aren’t available. (Perhaps no distributor has them. Or maybe they’re available but you must make a minimum order of 10,000 parts and wait six months.) You learn the parts are tagged as obsolete by its manufacturer, which may not be known in advance especially if you are a small customer.

If you are serious about efficiency, you won’t have this problem because you’ll order the required parts for your prototypes in advance. But even then you might have the same issue when you need to order components for the first production batch. This one is tricky to solve, but only two solutions work. Either use only very common parts that are widely available from several sources or early on buy enough parts for a couple of years of production. Unfortunately, the latter is the only reasonable option for certain components like LCDs.

Ok, how about one more? You’ll have to check out the Anniversary Issue for the list of the other 22 errors and tips. Lacoste writes:

Error 12: You Forget About Crosstalk Between Digital and Analog Signals

Full analog designs are rare, so you have probably some noisy digital signals around your sensor input or other low-noise analog lines. Of course, you know that you must separate them as much as possible, but you can be sure that you will forget it more than once.

Let’s consider a real-world example. Some years ago, my company designed a high-tech Hi-Fi audio device. It included an on-board I2C bus linking a remote user interface. Do you know what happened? Of course, we got some audible glitches on the loudspeaker every time there was an I2C transfer. We redesigned the PCB—moving tracks and adding plenty of grounded copper pour and vias between sensitive lines and the problem was resolved. Of course we lost some weeks in between. We knew the risk, but underestimated it because nothing is as sensitive as a pair of ears. Check twice and always put guard-grounded planes between sensitive tracks and noisy ones.

Circuit Cellar’s Circuit Cellar 25th Anniversary Issue will be available in early 2013. Stay tuned for more updates on the issue’s content.