Tools for embedded, your opinions -

Tools for embedded, your opinions


Editor's note: A new blogger but a familiar participant on, Ken Wada has throwing out pithy comments on Jack Ganssle's columns for years. Last year, at DESIGN West 2011, he stepped into a Mentor Meetup, hosted by Suzanne Deffree, the managing news editor of EDN magazine and Naomi Price, formerly of EE Times' EE Life. I was there, too, and chatted with him for a while about FASTRAK and other projects he has worked on. When I finally realized he was Ken Wada–our Ken Wada on–it was exciting to see someone who has for so long been a fixture on the site. We decided to give him his own blog, so without further ado, here's his first installment.

–Susan Rambo, managing editor, 

Welcome to a new blog on called Embedded Round Table. My name is Ken Wada, and I'll be the humble commentator, facilitator, and host on this blog, where embedded systems engineers can debate techniques and trade useful tips about our profession.

About myself: I suppose you can say that I am an older “grizzled veteran” of the embedded scene. I started down the path of building and designing embedded systems since my university days in graduate school in the late 1970s/early 1980s. My first experience with designing and implementing embedded systems came to me as a graduate student in the engineering department at UC Berkeley. Professor Dornfeld, who later became the associate dean of interdisciplinary studies in the UCB's College of Engineering, encouraged me to submit one of my class projects in advanced robotics to the James F. Lincoln Arc Welding Foundation's International Design competition.

I found out that as I submitted my entry, that my wife had gone out and purchased a brand new bedroom set. I asked her why she did this, and she said, “I know you will get 1st place, and I figured I could get us a bedroom set.” To which I replied… “You do not know this. I am competing against several top-notch teams from several top-notch schools!” Anyways, I did wind up winning the 1st place prize. Prof. Dornfeld and the mechanical engineering department got a bunch of mentions in the engineering publications, and I wound up getting fully hooked on all things control, communications, and embedded!

This blog will be a true round table. I feel all of us are equals and have much to share in outlook and other things embedded. Mostly, I will present some of my views on concerning experiences with all things embedded. What I am looking for is for others to express and share their views on these topics.

The only rule here is to be polite and talk about anything you want concerning the topic at hand. I pretty much have an opinion on anything embedded and a multitude of viewpoints and personal experience with a many aspects of deeply embedded systems. All viewpoints, experiences, and opinions are welcome here.

I have dabbled in everything from the really ultra-small state machine stuff to the really large multi-engineer project teams with a full-blown operating system and where nobody really knows what the other is doing. Also, I can safely say that I've made every mistake in the book when it comes to embedded systems. I am also certain that there are more mistakes waiting for me to make in this domain.

A good topic to start with is very near and dear to my heart–tools and tool usage. All projects can benefit from tools. Tools are one of those things one can never seem to have enough of on hand. Also, if the right tool is not available, we as engineers will make one up. I suppose this practice is called fixturing, no?

Since we're all engineers here, let me put together a list. Here are my top must-have debugging tools in relative usage, (and maybe), use order:

1. Multimeter
2. DSO (digital storage oscilloscope)
3. Instrumenting your own code (Here, I am talking about printf(), blinking LED's, test headers, and other techniques.)
4. JTAG emulator
5. Spectrum or network analyzer
6. Signal generator or synthesizer
7. USB, I2 C, SPI, and other protocol analyzers
8. Wireshark (I know this is software, but it's an Ethernet packet analyzer … and a very good one too!)

So, what kind of tools do you most commonly use? If you cannot find something that does exactly what you want, what is your tendency towards building something that really does the job? What kind of specialty tools have you used? I know that a lot of us work in highly specialized industries that have very unique demands on equipment and function. Also, I believe that there are engineers here that would like to see unique solutions presented that may help in projects they are currently working on.

Many times, I have found that the printf() does tend to “cripple” the system. Therefore; I may build a queue that captures data on some type of stimulus, or trigger. Then, I will “dump” the result using printf() at a later time. I use this technique whenever I am attempting to debug a servo system.

I especially love blinking LEDs. I think the perverse nature of spending several tens of thousands of dollars to see something blink has a very gratifying nature to it. It's simply amazing to see engineers jump up and down when the little tiny light starts blinking. I know that I get that mad scientist feeling whenever I experience this.

Ken Wada is president and owner of Aurium Technologies, an independent product design and consulting firm in California's Silicon Valley. Ken has over 25 years of experience architecting and designing high-tech products and systems, including the FASTRAK vehicle-sensing system for toll roads and bridges. His expertise includes industrial automation, biotechnology, and high-speed optical networks. Ken holds four patents. You may reach him at .

14 thoughts on “Tools for embedded, your opinions

  1. The MSO is indeed a fantastic tool. Too many times, management requires us to make a choice between a DSO and an MSO. Too many times; management is under this strange impression that these two tools are identical.

    Go figure!

    Log in to Reply
  2. Yes, they certainly can be more economical, but there are tradeoffs between desktop scopes and USB scopes. In general, the USB scopes have slower sampling rates, but much more memory. On the other hand, the desktop scopes tend to have very fast sampling an

    Log in to Reply
  3. At the price points you talk about; it may be possible to have multiple units available for the embedded developers to use. Then, to have more expensive desktop units shared for more demanding applications.
    I need to look into the Cleverscope.


    Log in to Reply
  4. I am with you on the blinking LED issue. There is a cool feeling when a system “comes alive” – almost like you have breathed life into to it yourself.

    The amount of information that a single LED can provide is surprising, as there are many possible states

    Log in to Reply
  5. How about using that same timer ISR to pet a watchdog … while blinking that LED?

    Haw! I have seen it happen!

    All seems to be well, whilst the code is in a deep coma.

    Log in to Reply
  6. If there is an option between purchasing one or the other, the MSO is the best option. An MSO is a superset of the DSO as an MSO is, in most cases, just a DSO plus the additional digital channels and associated functionality…

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.