Issue 270: EQ Answers

The answers to the Circuit Cellar 270 Engineering Quotient are now available. The problems and answers are listed below.

Problem 1: Given a microprocessor that has hardware support for just one level of priority for interrupts, is it possible to implement multiple priorities in software? If so, what are the prerequisites that are required?

Answer 1: Yes, given a few basic capabilities, it is possible to implement multiple levels of interrupt priority in software. The basic requirements are that it must be possible to reenable interrupts from within an interrupt service routine (ISR) and that the different interrupt sources can be individually masked.

Question 2: What is the basic scheme for implementing software interrupt priorities?

Answer 2: In normal operation, all the interrupt sources are enabled, along with the processor’s global-interrupt mask.

When an interrupt occurs, the global interrupt mask is disabled and the “master” ISR is entered. This code must (quickly) determine which interrupt occurred, disable that interrupt and all lower-priority interrupts at their sources, then reenable the global-interrupt mask before jumping to the ISR for that interrupt. This can often be facilitated by precomputing a table of interrupt masks for each priority level.

Question 3: What are some of the problems associated with software interrupt priorities?

Answer 3: For one thing, the start-up latency of all the ISRs is increased by the time spent in the “master” ISR. This can be a problem in time-critical systems. This scheme enables interrupts to be nested, so the stack must be large enough to handle the worst-case nesting of ISRs, on top of the worst-case nesting of non-interrupt subroutine calls.

Finally, it is very tricky to do this in anything other than Assembly language. If you want to use a high-level language, you’ll need to be intimately familiar with the language’s run-time library and how it handles interrupts and reentrancy, in general.

Answer 4: Yes, on most such processors, you can execute a subroutine call to a “return from interrupt” instruction while still in the master ISR, which will then return to the master ISR, but with interrupts enabled.

Check to see whether the “return from interrupt” affects any other processor state (e.g., popping a status word from the stack) and prepare the stack accordingly.

Also, beware that another interrupt could occur immediately thereafter, and make sure the master ISR is reentrant beyond that point.

 

Contributed by David Tweed

Q&A: Stephan Lubbers (Sensory Innovation)

Stephan Lubbers enjoys sensing technology. He is a creative engineer and inventor whose designs often build on his need to monitor data and figure out how things work. Steve and I recently discussed some of his designs, his contest-entry process, his thoughts on the future of embedded technology, and what’s currently happening on his workbench.—Nan Price, Associate Editor

NAN: Where are you located?

Stephan Lubbers

Stephan Lubbers in his workspace

STEVE: I live in Dayton, OH.

NAN: Where did you go to school and what did you study?

STEVE: My formal education is a BS in Computer Science from Wright State University, Fairborn, OH. Outside of schools, I’ve taught myself many things ranging from radio electronics to achieving an extra class amateur radio license, to assorted computer languages, to FPGA programming—all from just sitting down and saying, “Let’s learn this.”

NAN: Tell us about your current occupation.

STEVE: I am employed as a Senior Software Engineer at Beijing West Industries, where I develop embedded systems that go under the hood of high-end automobiles. (BWI is the owner of what was once General Motors’s Suspension and Brakes components company.) If your “Service Vehicle Soon” light comes on, I may have written the code behind it.

NAN: Tell us about your technical interests.

STEVE: My technical interests fall into two categories. I like to build systems around new sensing technologies and I build systems to support ham radio.

I never really thought about specific technical interests until I was asked this question. Looking at the Circuit Cellar contests I’ve entered and exploring my parts closet, I discovered that I have an abundance of sensors and sensor systems. When a new sensing device comes out, I often get one, play with it, and then look around for something to do with it. That usually results in an invention of some kind. I’ve analyzed the motion of rodeo bulls and dogs with microelectromechanical (MEMS) accelerometers, tracked eyeball movements with optical sensors, and computed automobile speeds using both GPS and microwave electronics. I don’t know if it is cause or effect, but I was always amazed by the “tricorder” on Star Trek. Do I like sensors because of Scotty and Mr. Spock? Or did I watch Star Trek because of the gadgets? I don’t know.

My love of electronics led me to amateur radio at a young age. I wasn’t as much interested in talking to other people as I was in exploring the technology that enables people to talk. I had a little success building RF devices but found that I had a real knack for digital systems. I’ve used that ability to create satellite tracking controllers, antenna switchers, and computer-to-radio interfaces.

NAN: How long have you been reading Circuit Cellar?

STEVE: I’ve subscribed to Circuit Cellar since Issue 1. I still believe the tagline that said “Inside the Box Still Counts.”

NAN: You’ve written four articles for Circuit Cellar. Some focus on data logging, monitoring, and analysis. For example, your article “Precision Motion-Sensing System Analyzer” (Circuit Cellar 192, 2006) is about a microcontroller-based, motion-sensing system for bull riders. What inspired you to create this system?

STEVE: Several things came together to spark the creation of the “Precision Motion-Sensing System Analyzer,” a.k.a. the BuckyMeter. I had already begun work on a motion-logging system but had no clear goal in mind. Shortly after the logger started working, Circuit Cellar announced its 2005 design contest. I had a short-term goal of entering the contest with my data logger. But what should I log?

My dad provided the suggestion to strap the logger onto the back of a rodeo bull. My parents had become fascinated by the sport of professional bull riding and thought it would be fun to get behind the scenes by doing this science experiment. One of the questions I had when designing the system was: “What kind of maximum G force can I expect to see?” Nobody had an answer, but the doctors responsible for repairing bull riders thought it was an interesting question. They, too, wanted to know that answer. That question opened a few doors to give us access to some bulls. EE Times printed a humorous article about my experience strapping an electronic device on the back of 1,200 lb of angry cow. It was definitely an experience!

The BuckyMeter hardware went through several iterations. In the end, an off-the-shelf Motorola Z-Star evaluation module could be used to instrument the bull with the added bonus of wireless data logging.

The project died out after a trip to instrument competition-grade bulls from American Bucking Bull, Inc. (ABBI). In hindsight, I learned an important lesson about managing customer expectations. I went to Oklahoma on a mission to collect data and try out an engineering prototype. I think the people I met with were expecting to see a polished product. Their impression, after our meeting, was that an electronic scoring aid was too slow and too complicated.

NAN: Another article, “Electronic Data Logging and Analysis: A How-To Guide for Building a Seizure-Monitoring System” (Circuit Cellar 214, 2008), describes an Atmel ATmega32-based electronic monitoring system that enables pet owners and vets to monitor epileptic seizure patterns in dogs. How does the microcontroller factor into the design?

STEVE: My seizure monitor was an offshoot of the rodeo bull motion-sensing system. The original processor had way more power than was needed and it was difficult to hand solder the part. With a working baseline from the BuckyMeter, it was easy to pick a different chip to work with. I had some experience with Atmel AVRs from a previous Circuit Cellar contest, so I looked at its product line. I had a good estimate for RAM/ROM requirements, and I decided it would be nice to have additional SPI channels to interface with the accelerometers. That led to the selection of the ATmega32. It didn’t hurt that another Atmel contest popped up in 2006 when I was in the middle of the design.

I have always wanted to expand my data beyond a single patient to see if my theory held up, so I supplied systems to some other people with epileptic dogs. This required continuous design updates mostly to keep up with outdated parts. Unfortunately, I never got any data back from the systems I gave away. My pet (and science guinea pig) passed away a few years ago, so I don’t have a subject to continue with this project.

NAN: At the end of your article, “Doppler Radar Design” (Circuit Cellar 243, 2010), you note that upgrades to the project (e.g., an enclosure and a portable power supply) could make the system “an easy-to-use mobile device.” Tell us about the design. Did you end up implementing any of those upgrades?

STEVE: Doppler Radar Design has been my most popular project. I get e-mails all the time asking how to reproduce it. As I stated in the article, the RF section is now hard to come by and expensive. Not being an RF engineer, I haven’t been able to recommend replacement parts.

The project started when my dad loaned me the microwave electronics to play with. He had wired them up for two-way ham radio communications. I couldn’t manage to make any radio contact with anybody but myself, so I started looking for other experiments to perform. In one of the experiments, I learned how to make a motion detector. From that, I decided to try to turn the project into a speed radar.

This project took help from a lot of other people because I really didn’t know what I was doing. Some radar discussions on the Internet outlined the basic design for Doppler speed radar, so I followed the suggestions, essentially a transmitter/receiver pair supplied by my borrowed Gunnplexer and a frequency detector (FFT) to show the Doppler shift of the returned signal. Accounting for the radio frequency in use gives you the speed of the reflected target, which in my case was a car.

When I discovered Ramsey Electronics sells a radar kit for $100, I decided that my Doppler radar was really just a science experiment. It was educational for me, but for everyone who contacted me just wanting to have their own radar, the Ramsey option was cheaper, more accurate, and already packaged for portability.

I did get some helpful hints from Alan Rutz at SHF Microwave Parts Company, who suggested something called a dielectric resonator oscillator (DRO) could be used in place of the Gunnplexer I used. The advantage of his approach is that DROs are available and cost about $20. I have not yet been successful with this upgrade.

NAN: The Renesas Electronics RX62N development board is at the heart of your KartTracker’s monitoring system (“KartTracker: A GPS-Based Vehicle Timing & Monitoring System,” Circuit Cellar 259, 2012). Tell us about the design and how the KartTracker functions.

KartTracker

KartTracker: A GPS-Based Vehicle Timing & Monitoring System

STEVE: The KartTracker came about one day when the neighborhood NASCAR fans went out racing karts. We wondered how fast we went, so the local engineer (me) set about finding out.

I started with a GPS receiver and a data logger and drove around the track to see what happened. As it turns out, GPS receivers automatically give you your speed! That was too easy, so I started looking for more features.

The next couple of races I watched, I tried to pay attention to more than just the action and saw that teams were very concerned with lap times. Well, I could time my laps, but that didn’t seem very interesting or complicated enough. Then I saw a qualifying session where the TV showed a continuous real-time comparison between two cars. That seemed cool! If I could build that, I could race myself to see if I was doing better or worse.

So, the KartTracker concept was born. A GPS receiver feeds continuous position data into a Renesas RX62N board. The software continuously compares my time at some location against the last time I was there. It’s like looking at the lap time, but it updates every couple of seconds so you have continuous feedback.

All the timing data is retained so later we can compare times against each other and brag about who went the fastest. I would like to broadcast the times back to the spectators, but that radio is a project for another day.

NAN: You received an Honorable Mention for your 2010 Texas Instruments DesignStellaris Design Contest entry, “Hands-Free USB Mouse.” Tell us about the project and your contest-entry process.

Hands-Free USB Mouse

2010 Texas Instruments DesignStellaris Design Contest Honorable Mention “Hands-Free USB Mouse”

STEVE: My eyePOD hands-free USB Mouse is a head-mounted motion sensor that controls the mouse cursor on a PC. By moving your head, the mouse moves around the screen. You wink your eyes to click the mouse buttons. The goal was to produce a PC interface for someone who couldn’t use a typical mouse, with a secondary goal of teaching me about USB. There are some problems in certain lighting conditions, but overall it works pretty well.

After about a dozen contest entries, I have a bit of a process for creating an entry. I hope I don’t hurt my future chances by sharing my secrets, but since you asked, three things need to line up for me to start a project (contest or otherwise): I need an idea, I need some technology, and I need motivation.

Author James Rollins says, “Don’t ask where the ideas come from.” But, if you have to know, his story ideas come from a box. My contest ideas come from a little red notebook. In reality, we don’t know where the actual ideas come from, but when we get ideas we put them in the box (or book) and make a withdrawal when we need to use an idea.

Part two is that there needs to be a technology that will support the idea. I couldn’t build a rodeo bull monitor until there were cheap accelerometers available. I couldn’t build the KartTracker without a GPS. So, keep a list of technologies you like in your box of ideas.

Finally, you need motivation to execute the project. At work, your boss provides the motivation in the form of a paycheck. At home, you might have a dog that needs help or a neighbor who supplies beer for the answer of how fast his kart is. When I put the three pieces together, I have the starting point for a project. Apply your abilities and start building.

The only biggie after that is time management. Somewhere there is a deadline you need to meet. Do consistent work on your project and prioritize what needs to be done. I have a knack for drawing a line through the critical parts of a project to make sure I have something working when the end is near. You can always go back and improve a working project, but if you have too many half-built features, you have nothing to fall back on when time runs out. A good example is the radio link for the KartTracker. Without GPS and timing software, the project would be nothing. When I had time remaining, I added file I/O and data storage on an SD card. Nice features, but they weren’t necessary to demonstrate the project. The radio link fell by the wayside when entry time came up.

Finally, don’t forget the book report at the end. The judges need to know what you did, so you need to write about it. Who knows? Circuit Cellar might like what you wrote and decide to turn it into an article.

NAN: Have you recently purchased any embedded technology tools to help you with your data logging, monitoring, and analysis projects?

STEVE: My most recent tech purchase was an iPod Touch funded from a recent Circuit Cellar publication. Before you say, “That’s not embedded,” let me explain. I tend to make the user interfaces to my projects simple and to the point. Circuit Cellar contest deadlines don’t lend themselves to creating a new fancy interface for each project. Instead, I would offload debugging, control, and extra features to an external system. I started out using RS-232 serial to a PC. For portability and speed, I moved to a PalmPilot with an infrared data access  (IrDA) interface. A Bluetooth or Wi-Fi interface seems like a logical progression to me. The iPod Touch has these interfaces and it leaves me with a new gadget to play with.

A more embedded acquisition is the Texas Instruments MetaWatch. If you haven’t seen one of these, it’s a stylish digital watch that talks to your smartphone. For the more adventurous, the source code is available so you can add your own features. There must be something great that I can do with a wrist-mounted computer, I just haven’t had the “ah-ha” moment yet.

NAN: Are you currently working on or planning any embedded-design-related projects?

STEVE: I call my current project the SeeingEye for a dog. The blind have used guide dogs since the 16th century. That’s a huge debt man owes his best friend! To help repay that debt, I’m creating a twist on the seeing eye dog by creating a seeing eye for a friend’s vision-impaired dog. Using the sensors and technology robots use for collision avoidance, the SeeingEye will detect obstacles in a dog’s path. The trick seems to be the user interface to convey the collision avoidance information and training the dog to respond correctly to the stimulus. I figure if microchips in robots can learn to avoid walls, then puppy neurons should be able to do the same thing. I still have more work to do to figure out how to get the sensor to stay in place.

SeeingEye board

SeeingEye for dogs, circuit board

SeeingEye

SeeingEye for dogs, in “use”

NAN: Do you have any thoughts on the future of embedded technology?

STEVE: As a builder of embedded systems, I am amazed at all of the things we can do with high-speed processors and multiple megabytes of memory. It seems like if we can imagine it, we can build it.

As a user of embedded technologies, it sometimes seems like the engineers are trying to be too clever by stuffing anything they can into the box whether those features are needed or not.

The complexity of some devices has skyrocketed to the point that stability has been affected and users don’t know what features they have or how to use them. We now take for granted a constant stream of software updates to our devices and press reset when it doesn’t work as desired.

Einstein is credited with saying, “Everything should be made as simple as possible, but no simpler.” I’d like to see the industry adopt Einstein’s advice and the “Keep it simple, stupid!” (KISS) principle to help us manage the growing complexities. We’d spend less time serving our devices by trying to make them work and more time being served by our devices as they flawlessly do the work we want done.

CC270: Forward Progress

As you might have noticed, parts of this issue look a bit different than the publication you’re used to reading. You can see a slightly updated layout, some different colors, and a few new sections. We’ve made these changes to reflect where we are today and where we’re taking this magazine in the months to come. It’s all about forward progress. Here are the broad strokes:

FRESHENED UP LAYOUT

We’re planning an exciting layout redesign for 2013. The layout will be modern, clean, and engaging, but its fonts and colors won’t distract you from what you’re reading—professional engineering content. Since the new layout is still an issue or two away, we’re presenting you with this freshened up issue to mark the transition to 2013. We hope you like the changes.

CLIENT PROFILES

On page 20 you’ll find a new section that will appear frequently in the coming months. The purpose of our client profiles is to shine a light on one company per month and bring you an exclusive offer for useful products or services.

TECH THE FUTURE

Last month we ran Steve Ciarcia’s final “Priority Interrupt” editorial. This month we’re introducing a new section, “Tech the Future.” The EE/ECE community is on the verge of major breakthroughs in the fields of microcomputing, wireless communication, robotics, and programming. Each month, we’ll use page 80 to present some of the fresh ideas, thought-provoking research projects, and new embedded design-related endeavors from innovators who are working on the groundbreaking technologies of tomorrow.

CC25

You’ll soon have Circuit Cellar’s 25th (“CC25”) anniversary issue in your hands or on your PCs or mobile devices. Here are just a few of the exciting topics in the issue: Circuit Cellar in 1988, design/programming tips, engineers’ thoughts on the future of embedded tech, and much more. It’s going to be a classic.

Well, there’s certainly a lot of publishing-related innovation going on at our headquarters. And I know you’re equally busy at your workbenches. Just be sure to schedule some quiet time this month to read the articles in this issue. Perhaps one of our authors will inspire you to take on your first project of the new year. We feature articles on topics ranging from an MCU-based  helicopter controller to open-source hardware to embedded authentication to ’Net-based tools for energy efficiency. Enjoy!

Member Profile: Thomas Struzik

Member Thomas Struzik at his bench.

 

  • Member Name: Thomas Struzik
  • Location: Houston, TX
  • Education: BSEE, Purdue University
  • Occupation: Software architect
  • Member Status: He has been a subscriber since day one. “I’ve got Issue 1 sitting in a box somewhere,” he said. Thomas adds that he was a BYTE magazine subscriber before Circuit Cellar.
  • Technical Interests: Thomas enjoys automation through embedded technology, robotics, low-level programming, and electronic music generation / enhancement.
  • Most Recent Embedded Tech-Related Purchase: He recently bought a CWAV USBee SX Digital Test Pod and an Atmel AVR Dragon.
  • Current and Recent Projects: Thomas is working on designing an isolated USB power supply for his car.
  • Thoughts on the Future of Embedded Technology: Ever-increasing complexity is becoming a stumbling block for the “average” user. “Few people even realize the technology embedded in everyday items,” he said. “How many people know that brand-new LCD TV they’ve got is actually running Linux under the covers? Fortunately, there seems to be a resurgence of ‘need-to-know how stuff works’ with the whole DIY/maker culture. But even that is still a small island compared to the population in general.”