Small Plug-In Embedded Cellular Modem

Skywire plug-in modem

Skywire plug-in modem

The Skywire is a small plug-in embedded cellular modem. It uses a standard XBee form factor and 1xRTT CDMA operating mode to help developers minimize hardware and network costs. Its U.FL port ensures antenna flexibility.

The Skywire modem features a Telit CE910-DUAL wireless module and is available with bundled CDMA 1xRTT data plans from leading carriers, enabling developers to add fully compliant cellular connectivity without applying for certification. Future versions of the Skywire will support GSM and LTE. Skywire is smaller than many other embedded solutions and simple to deploy due to its bundled carrier service plans.

Skywire is available with a complete development kit that includes the cellular modem, a baseboard, an antenna, a power supply, debug cables, and a cellular service plan. The Skywire baseboard is an Arduino shield, which enables direct connection to an Arduino microcontroller.

Skywire modems cost $129 individually and $99 for 1,000-unit quantities. A complete development kit including the modem costs $262.

NimbeLink, LLC
www.nimbelink.com

Q&A: Jeremy Blum, Electrical Engineer, Entrepreneur, Author

Jeremy Blum

Jeremy Blum

Jeremy Blum, 23, has always been a self-proclaimed tinkerer. From Legos to 3-D printers, he has enjoyed learning about engineering both in and out of the classroom. A recent Cornell University College of Engineering graduate, Jeremy has written a book, started his own company, and traveled far to teach children about engineering and sustainable design. Jeremy, who lives in San Francisco, CA, is now working on Google’s Project Glass.—Nan Price, Associate Editor

NAN: When did you start working with electronics?

JEREMY: I’ve been tinkering, in some form or another, ever since I figured out how to use my opposable thumbs. Admittedly, it wasn’t electronics from the offset. As with most engineers, I started with Legos. I quickly progressed to woodworking and I constructed several pieces of furniture over the course of a few years. It was only around the start of my high school career that I realized the extent to which I could express my creativity with electronics and software. I thrust myself into the (expensive) hobby of computer building and even built an online community around it. I financed my hobby through my two companies, which offered computer repair services and video production services. After working exclusively with computer hardware for a few years, I began to dive deeper into analog circuits, robotics, microcontrollers, and more.

NAN: Tell us about some of your early, pre-college projects.

JEREMY: My most complex early project was the novel prosthetic hand I developed in high school. The project was a finalist in the prestigious Intel Science Talent Search. I also did a variety of robotics and custom-computer builds. The summer before starting college, my friends and I built a robot capable of playing “Guitar Hero” with nearly 100% accuracy. That was my first foray into circuit board design and parallel programming. My most ridiculous computer project was a mineral oil-cooled computer. We submerged an entire computer in a fish tank filled with mineral oil (it was actually a lot of baby oil, but they are basically the same thing).

DeepNote Guitar Hero Robot

DeepNote Guitar Hero Robot

Mineral Oil-Cooled Computer

Mineral Oil-Cooled Computer

NAN: You’re a recent Cornell University College of Engineering graduate. While you were there, you co-founded Cornell’s PopShop. Tell us about the workspace. Can you describe some PopShop projects?

Cornell University's PopShop

Cornell University’s PopShop

JEREMY: I recently received my Master’s degree in Electrical and Computer Engineering from Cornell University, where I previously received my BS in the same field. During my time at Cornell, my peers and I took it upon ourselves to completely retool the entrepreneurial climate at Cornell. The PopShop, a co-working space that we formed a few steps off Cornell’s main campus, was our primary means of doing this. We wanted to create a collaborative space where students could come to explore their own ideas, learn what other entrepreneurial students were working on, and get involved themselves.

The PopShop is open to all Cornell students. I frequently hosted events there designed to get more students inspired about pursuing their own ideas. Common occurrences included peer office hours, hack-a-thons, speed networking sessions, 3-D printing workshops, and guest talks from seasoned venture capitalists.

Student startups that work (or have worked) out of the PopShop co-working space include clothing companies, financing companies, hardware startups, and more. Some specific companies include Rosie, SPLAT, LibeTech (mine), SUNN (also mine), Bora Wear, Yorango, Party Headphones, and CoVenture.

NAN: Give us a little background information about Cornell University Sustainable Design (CUSD). Why did you start the group? What types of CUSD projects were you involved with?

CUSD11JEREMY: When I first arrived at Cornell my freshman year, I knew right away that I wanted to join a research lab, and that I wanted to join a project team (knowing that I learn best in hands-on environments instead of in the classroom). I joined the Cornell Solar Decathlon Team, a very large group of mostly engineers and architects who were building a solar-powered home to enter in the biannual solar decathlon competition orchestrated by the Department of Energy.

By the end of my freshman year, I was the youngest team leader in the organization.  After competing in the 2009 decathlon, I took over as chief director of the team and worked with my peers to re-form the organization into Cornell University Sustainable Design (CUSD), with the goal of building a more interdisciplinary team, with far-reaching impacts.

CUSD3

Under my leadership, CUSD built a passive schoolhouse in South Africa (which has received numerous international awards), constructed a sustainable community in Nicaragua, has been the only student group tasked with consulting on sustainable design constraints for Cornell’s new Tech Campus in New York City, partnered with nonprofits to build affordable homes in upstate New York, has taught workshops in museums and school, contributed to the design of new sustainable buildings on Cornell’s Ithaca campus, and led a cross-country bus tour to teach engineering and sustainability concepts at K–12 schools across America. The group is now comprised of students from more than 25 different majors with dozens of advisors and several simultaneous projects. The new team leaders are making it better every day. My current startup, SUNN, spun out of an EPA grant that CUSD won.

CUSD7NAN: You spent two years working at MakerBot Industries, where you designed electronics for a 3-D printer and a 3-D scanner. Any highlights from working on those projects?

JEREMY: I had a tremendous opportunity to learn and grow while at MakerBot. When I joined, I was one of about two dozen total employees. Though I switched back and forth between consulting and full-time/part-time roles while class was in session, by the time I stopped working with MakerBot (in January 2013), the company had grown to more than 200 people. It was very exciting to be a part of that.

I designed all of the electronics for the original MakerBot Replicator. This constituted a complete redesign from the previous electronics that had been used on the second generation MakerBot 3-D printer. The knowledge I gained from doing this (e.g., PCB design, part sourcing, DFM, etc.) drastically outweighed much of what I had learned in school up to that point. I can’t say much about the 3-D scanner (the MakerBot Digitizer), as it has been announced, but not released (yet).

The last project I worked on before leaving MakerBot was designing the first working prototype of the Digitizer electronics and firmware. These components comprised the demo that was unveiled at SXSW this past April. This was a great opportunity to apply lessons learned from working on the Replicator electronics and find ways in which my personal design process and testing techniques could be improved. I frequently use my MakerBot printers to produce custom mechanical enclosures that complement the open-source electronics projects I’ve released.

NAN: Tell us about your company, Blum Idea Labs. What types of projects are you working on?

JEREMY: Blum Idea Labs is the entity I use to brand all my content and consulting services. I primarily use it as an outlet to facilitate working with educational organizations. For example, the St. Louis Hacker Scouts, the African TAHMO Sensor Workshop, and several other international organizations use a “Blum Idea Labs Arduino curriculum.” Most of my open-source projects, including my tutorials, are licensed via Blum Idea Labs. You can find all of them on my blog (www.jeremyblum.com/blog). I occasionally offer private design consulting through Blum Idea Labs, though I obviously can’t discuss work I do for clients.

NAN: Tell us about the blog you write for element14.

JEREMY: I generally use my personal blog to write about projects that I’ve personally been working on.  However, when I want to talk about more general engineering topics (e.g., sustainability, engineering education, etc.), I post them on my element14 blog. I have a great working relationship with element14. It has sponsored the production of all my Arduino Tutorials and also provided complete parts kits for my book. We cross-promote each-other’s content in a mutually beneficial fashion that also ensures that the community gets better access to useful engineering content.

NAN: You recently wrote Exploring Arduino: Tools and Techniques for Engineering Wizardry. Do you consider this book introductory or is it written for the more experienced engineer?

JEREMY: As with all the video and written content that I produce on my website and on YouTube, I tried really hard to make this book useful and accessible to both engineering veterans and newbies. The book builds on itself and provides tons of optional excerpts that dive into greater technical detail for those who truly want to grasp the physics and programming concepts behind what I teach in the book. I’ve already had readers ranging from teenagers to senior citizens comment on the applicability of the book to their varying degrees of expertise. The Amazon reviews tell a similar story. I supplemented the book with a lot of free digital content including videos, part descriptions, and open-source code on the book website.

NAN: What can readers expect to learn from the book?

JEREMY: I wrote the book to serve as an engineering introduction and as an idea toolbox for those wanting to dive into concepts in electrical engineering, computer science, and human-computer interaction design. Though Exploring Arduino uses the Arduino as a platform to experiment with these concepts, readers can expect to come away from the book with new skills that can be applied to a variety of platforms, projects, and ideas. This is not a recipe book. The projects readers will undertake throughout the book are designed to teach important concepts in addition to traditional programming syntax and engineering theories.

NAN: I see you’ve spent some time introducing engineering concepts to children and teaching them about sustainable engineering and renewable energy. Tell us about those experiences. Any highlights?

JEREMY: The way I see it, there are two ways in which engineers can make the world a better place: they can design new products and technologies that solve global problems or they can teach others the skills they need to assist in the development of solutions to global problems. I try hard to do both, though the latter enables me to have a greater impact, because I am able to multiply my impact by the number of students I teach. I’ve taught workshops, written curriculums, produced videos, written books, and corresponded directly with thousands of students all around the world with the goal of transferring sufficient knowledge for these students to go out and make a difference.

Here are some highlights from my teaching work:

bluestamp

I taught BlueStamp Engineering, a summer program for high school students in NYC in the summer of 2012. I also guest-lectured at the program in 2011 and 2013.

I co-organized a cross-country bus tour where we taught sustainability concepts to school children across the country.

indiaI was invited to speak at Techkriti 2013 in Kanpur, India. I had the opportunity to meet many students from IIT Kanpur who already followed my videos and used my tutorials to build their own projects.

Blum Idea Labs partnered with the St. Louis Hacker Scouts to construct a curriculum for teaching electronics to the students. Though I wasn’t there in person, I did welcome them all to the program with a personalized video.

brooklyn_childrens_zoneThrough CUSD, I organized multiple visits to the Brooklyn Children’s Zone, where my team and I taught students about sustainable architecture and engineering.

Again with CUSD, we visited the Intrepid museum to teach sustainable energy concepts using potato batteries.

intrepid

NAN: Speaking of promoting engineering to children, what types of technologies do you think will be important in the near future?

JEREMY: I think technologies that make invention more widely accessible are going to be extremely important in the coming years. Cheaper tools, prototyping platforms such as the Arduino and the Raspberry Pi, 3-D printers, laser cutters, and open developer platforms (e.g., Android) are making it easier than ever for any person to become an inventor or an engineer.  Every year, I see younger and younger students learning to use these technologies, which makes me very optimistic about the things we’ll be able to do as a society.

Processing, Wiring, and Arduino (EE Tip 101)

Processing is a language and an open-source programming environment for programming images, animations, and interactions. The project, an initiative from Ben Fry and Casey Reas, is based on ideas developed by the Aesthetics and Computation Group of the MIT Media Lab. Processing was created in order to teach the fundamentals of programming in a visual context and to serve as a sketchbook or professional software production tool. Processing runs under GNU/Linux, Mac OS X, and Windows. Several books have already been written on Processing.

Source: Clemens Valens, “Microcontrollers for Dummes,” 080931-I, Elektor, 2/2009.

Source: Clemens Valens, “Microcontrollers for Dummes,” 080931-I, Elektor, 2/2009.

Just like Arduino, Wiring is a programming environment with microcontroller board for exploring electronic arts, teaching programming, and quick prototyping. Wiring, programmed in Processing, is an initiative by Hernando Barragán and was designed at the Interaction Design Institute Ivrea (IDII) in Italy.

Arduino is a fast, open-source electronic prototyping platform. Arduino is aimed at DIYers, electronics enthusiasts, and anyone interested in creating objects or interactive environments. Created by Massimo Banzi, Gianluca Martino, David Cuartielles, and David Mellis, Arduino uses a programming language based on Processing. Arduino may be regarded as a simplification of Wiring.

For more information, refer to Clemens Valens’s article, “Microcontrollers for Dummies,” 080931-I, Elektor, 2/2009.

CC278: Serial Displays Save Resources (BMP Files)

In Circuit Cellar’s September issue, columnist Jeff Bachiochi provides his final installment in a three-part series titled “Serial Displays Save Resources.” The third article focuses on bitmap (BMP) files, which store images.

Photo1

A BMP file has image data storage beginning with the image’s last row. a—Displaying this data as stored will result in an upside-down image. b—Using the upsidedown=1 command will rotate the display 180°. c—The mirror=1 command flips the image horizontally. d—Finally, an origin change is necessary to shift the image to the desired location. These commands are all issued prior to transferring the pixels, to correct for the way the image data is stored.

LCDs are inexpensive and simple to use, so they are essential to many interesting projects, Jeff says. The handheld video game industry helped popularize the use of LCDs among DIYers.

Huge production runs in the industry “made graphic displays commonplace, helping to quickly reduce their costs,” Jeff says. “We can finally take advantage of lower-cost graphic displays, with one caveat: While built-in hardware controllers and drivers take charge of the pixels, you are now responsible for more than just sending a character to be printed to the screen. This makes the controllers and drivers not work well with the microcontroller project. That brings us to impetus for this article series.

“In Part 1 (‘Routines, Registers and Commands,’ Circuit Cellar 276, 2013), I began by discussing how to use a graphic display to print text, which, of course, includes character generation. In essence, I showed how to insert some intelligence between a project and the display. This intermediary would interpret some simple commands that enable you to easily make use of the display’s flexibility by altering position, screen orientation, color, magnification, and so forth.

“Part 2 (‘Button Commands,’ Circuit Cellar 277) revealed how touch-sensitive overlays are constructed and used to provide user input. The graphic display/touch overlay combination is a powerful combination that integrates I/O into a single module. Adding more commands to the interface makes it easier to create dynamic buttons on the graphic screen and reports back whenever a button is touched.

The prototype PCB I used for this project mounts to the reverse side of the thin-film transistor (TFT) LCD. The black connector holds the serial and power connections to your project. The populated header is for the Microchip Technology MPLAB ICD 3 debugger/programmer.

“Since I am using a graphic screen, it makes sense to investigate graphic files. This article (Part 3, ‘BMP Files,’ Circuit Cellar 277) examines the BMP file makeup and how this relates to the graphic screen.”

To learn more about the BMP graphical file format and Jeff’s approach to working with a graphic icon’s data, check out the September issue.

 

Q&A: Jack Ganssle, Electronics Entrepreneur

Jack Ganssle is a well-known engineer, author, lecturer, and consultant. After learning about oscilloscopes, transistors, and capacitors in his father’s engineering lab, Jack went on to write hundreds of articles and several books about embedded development-related topics. He also started and sold three electronics companies, worked on classified government projects, and founded The Ganssle Group, based in Reisterstown, MD. I recently spoke with Jack about some of his career highlights, his current work, and what’s next in the embedded design industry.—Nan Price, Associate Editor

NAN: You’ve been interested in electronics since the age of 9. Give us a little background information. What was your first project?

Jack Ganssle

Jack Ganssle

JACK: My first project was a crystal radio with the inductor wound on the quintessential Quaker oatmeal box! It was really exciting to get AM reception over that. Back then, pretty much no one had FM. AM was it.

Later I learned to repair TVs and made pocket money doing that. Those sets were all vacuum tubes. Usually there was just a bad tube or dried out capacitor. But from there, my friends and I learned to design amplifiers (the Beatles were very hot and everyone was starting a band). For graduation from eighth grade, my dad gave me an old oscilloscope he had built from a kit years earlier.

He was part of a startup when I was in my early teens. We kids were coerced into being the (unpaid) janitors for the place. That was annoying at first. But, we were allowed to keep anything we swept up. The engineering lab’s floor was always covered in resistors, capacitors, transistors, and the like, so my parts collection grew. (ICs existed then, but were rare.)

When I was 16 I got a ham license, built  various transmitters, and used WWII surplus receivers. One day an angry letter arrived from the Federal Communications Commission (FCC). They had picked me up on my second harmonic clear across the country. I was really proud of that contact.

But it wasn’t long before some resistor-transistor logic (RTL) digital ICs came my way. Projects included controls for tube transmitters, Estes model rocket telemetry, and even a crude TV camera that used a photomultiplier tube to scan a spiral set of holes in a spinning disk. A couple of us worked on a ham radio moon bounce, but I accidentally shorted out a resistor and my only hydrogen thyratron (sort of a tube version of an SCR) blew up. There was no money for a replacement, so that project died. The transmitter used a little lighthouse tube that had a maximum rating of a couple of watts, but it worked OK when pulsing it for a few microseconds at 1 kW.

Senior year of high school a friend and I hitchhiked from Maryland to Boston to go to a surplus store. I bought a core memory plane that was 13,000 bits in a 6 in2 cube. Long hair didn’t help. We were picked up on the New Jersey Turnpike and strip searched. The cops never believed my explanation that the thing was computer memory.

A few years later, I had a 6501 microprocessor in the glove compartment of my Volkswagen bus (which I lived in for a year while saving for a sailboat). Coming into a sleepy Maine town from Canada that event was repeated when the border cops searched the bus and found the chip. They didn’t believe in computers on a chip. But the PC was years away and computers were mostly seen in science fiction films.

Freshman year of college, I designed and built a 12-bit computer using hundreds of TTL chips soldered together using phone company wire on vectorboards. For I/O there was an old Model 15 teletype using 5-bit Baudot codes that my software drove via bit banging. The OS, such as it was, lived in a pair of 1702 EPROMs, which each held 256 bytes. The computer worked great! And then the 8008, the first 8-bit microcontroller, came out and the thing was obsolete. I junked it, and now I wish I had saved at least the schematics.

But by then I had been working part-time as an electronics technician for a few years and the company needed to update its analog products to digital. No one knew anything about computers, so they promoted me to engineer. Eventually I ran the digital group there. We designed one of the first floppy disk controllers, insanely high-resolution graphics controllers, and a lot of other products. We also integrated minicomputers (Data General Novas and DEC PDP-11s) into systems with microprocessors. We bought a 5-MB disk drive for a Nova. It cost $5,000 (back when that was a lot of money) and weighed 500 lb. How things have changed.

NAN: Tell us about The Ganssle Group (www.ganssle.com). When and why did you start the company? What types of services do you provide?

JACK:  I formed The Ganssle Group in 1997 after 15 years of running an in-circuit emulator company. Working 70 h a week was getting old and I wanted more time with my kids. So my objective was to reverse the usual model. Instead of fitting life around a job, I wanted to fit the job into life.

Goal 1: Four months of vacation a year. It turns out that is elusive, in no small part due to the cool stuff going on around here, but most years we do manage two to three months off. My wife, Marybeth, works with me. She takes care of all of the administrative/travel and the like.

Goal 2: No commute. So we work out of the house (for the first few years, we worked out of the houseboat where we raised two kids).

Now the kids are grown, so there’s a Goal 3: Have as much fun as possible with Marybeth, so when I travel to new or interesting places she often accompanies me. There’s a lot more to life than work. Some of my side projects are available at www.ganssle.com/jack.

I’m not really sure what I do. I write—a lot. Readers are incredibly smart and vocal. The dialogue with them is a highlight of my day. I also give one- and two-day seminars on pretty much every continent (except Antarctica—so far!) about ways to get better firmware done faster. Sometimes I do an expert witness gig. Those are always fascinating as one gets to dig deeply into products and learn about the law. On rare occasions, I’ll do a day or three of consulting if the problem is particularly interesting. And there’s always some experiment I’m working on, which sometimes gets written up as an article.

NAN: Speaking of articles, you’ve written hundreds—including nine for Circuit Cellar magazine—on topics ranging from the history of the embedded systems programming industry, to memory management, to using programmable logic devices (PLDs). You also write a column for Embedded (www.embedded.com) and you are editor of the biweekly newsletter The Embedded Muse. Tell us about the types of projects you enjoy constructing and writing about.

The breadboard is discharging batteries. To the left, a battery is soldered to some coax. Using the waveform generator in the oscilloscope I’m measuring the battery's reactance (which, it turns out, is entirely capacitive). The IAR tool is profiling current consumption of an evaluation board.

The breadboard is discharging batteries. To the left, a battery is soldered to some coax. Using the waveform generator in the oscilloscope I’m measuring the battery’s reactance (which, it turns out, is entirely capacitive). The IAR tool is profiling current consumption of an evaluation board.

JACK: I have one experiment that’s running right now. For the last four months I’ve been discharging coin cells. It sounds dull, but some microcontroller vendors are making outrageous claims about battery life that are on the surface true but irrelevant in real circuits. This circuit runs a complex profile on the batteries, tossing different loads on for a few milliseconds, and an ARM microcontroller samples the batteries’ voltage (as well as the transistors, VCE drop) into a log file. That data goes into a spreadsheet for further analysis. I’m making a much bigger version of this now, which will handle far more batteries at a time. I recently gave some preliminary results at a talk in Asilomar, CA, which garnered a lot of interest. More results will be forthcoming soon…I promise!

Another aspect of this is leakage. Does handling a battery leave finger oils that can affect the decades-long life claimed by the vendors? To test this, I built a femtoammeter. A polypropylene capacitor is charged and feeds a super-low bias current op-amp. Another ARM board monitors the op-amp voltage to watch the capacitor discharge as various contaminants are electrically connected to the capacitor. With no contaminants connected, even after 48 h, the cap discharged less than 1 mV. The thing resolves to better than 10 fA. (One fA is a millionth of a nanoamp, or about 6,000 electrons/second).

In fact, the ADC’s transfer function is a proxy for temperature. We heat the house with wood and you could see a perfect correlation of op-amp output and temperature throughout the day. (It’s lowest in the morning as the fire burns out overnight.)

NAN: You wrote the two-part Circuit Cellar article series, “Writing a Real-Time Operating System” (Issue 7 and 8, 1989) about the Hitachi HD64180 Z80-based embedded microprocessor nearly 15 years ago. Circuit Cellar also featured another HD64180-based article, “Huge Arrays on the HD64180: Taking Advantage of Memory Management” (Issue 16, 1990). What was your fascination with the HD64180? Also, is either of these projects still current? Have you changed any of the design components?

JACK: Gee, I have no idea. I wrote those using Microsoft Works, but the file format has changed and Works can no longer open those articles. Alas, the HD64180 is quite obsolete. It was a grown-up version of the Z80 and very popular in its day.

In 1974, Intel introduced the 8080, which was the first really decent 8-bit microprocessor. But it needed two clocks and three power supplies. The folks at Zilog came out with the Z80 a year later. It could run 8080 code, but had one clock, a single 5-V supply, and it offered additional instructions that massively improved code density. Intel responded with the 8085, but it was really an 8080 in drag. The couple of new instructions added just couldn’t give the Z80 a run for its money. Eventually Zilog came out with the Z180, and Hitachi the 64180 clone, which included on-board peripherals and a memory management unit to address 1 MB using standard Z80 instructions. It was a great idea, but since there was no on-board memory, it couldn’t compete with microcontrollers such as the ancient, and still-going-strong, 8051.

NAN: In addition to writing, you lecture and teach at conferences and symposiums worldwide. Tell us about your one-day “Better Firmware Faster” seminar. How did it begin? What can attendees expect to gain from it?

JACK: I’m completely frustrated with the state of firmware. It’s inevitably late and buggy. While there’s no doubt that crafting firmware is extremely difficult—after all, software is the most complex engineered product ever invented—we can and must do better. It’s astonishing that so few groups keep even the simplest metrics, yet engineering is all about numbers.

The seminar is a fast-paced event that shows developers better ways to get their code to market. It covers process issues, as well as a lot of technology areas unique to embedded systems, such as managing memory and dealing with tough real-time problems.

What can attendees get from it? It varies from very little to a lot. Some groups refuse to change anything, so will always maintain the status quo. Others do better. Some report 40% improvements to the schedule and up to an order of magnitude of reduction in shipped bugs.

NAN: You started three high-tech companies prior to The Ganssle Group. Tell us about your work experience. Any highlights?

JACK: Well, there was one instrument that used infrared light to measure protein in cow poop. Though it was interesting technology, it’s hard to call that a highlight. The design I’m most proud of was my first emulator, which had only 17 ICs and used insanely complex code. Eventually we offered emulators that required hundreds of chips, but those cost $7,000, while the first one sold for $600.

Some of the government work I’ve done was very interesting and used extremely sophisticated electronics. But I can’t talk about those projects. A buddy and I did the White House security system during the Reagan administration. It was fun to work in the basement there, but the bureaucracy was stifling. We lost our White House passes the same day Oliver North did, but he got more press.

NAN: What do you consider to be the “next big thing” in the embedded design industry? Is there a particular technology that you’ve used or seen that will change the way engineers design in the coming months and years?

JACK: Everything is going to change for us over the next five to 10 years. We will have tools that automatically find lots of bugs. Everyone is familiar (and has a love/hate relationship) with lint. But static analyzers can today find lots of runtime bugs. These are currently expensive and frustrating, but they demonstrate that such products can, and will, exist. When the issues are resolved, I expect they’ll be as common as IDEs. Debugging manually is hugely expensive.

Another tool is slowly gaining acceptance: so-called virtualization products (e.g., from Wind River and others). These are not the hypervisors people think about when using the word “virtualization.” Rather, they are complete software models of a target system. You can run all—and I mean all—of your code on the model. The hardware is always late. These tools will permit debugging to start at the beginning of the project. The tools are also expensive and somewhat clumsy, but will get better over time.

A modern smartphone has more than 10 million lines of code. Automobiles often have more. One thing is certain: Firmware will continue to grow in size and complexity. The current techniques we use to develop code will change as well.