TEM Logo The Embedded Muse
Issue Number 276, January 19, 2015
Copyright 2015 The Ganssle Group

Editor: Jack Ganssle, jack@ganssle.com
   Jack Ganssle, Editor of The Embedded Muse

You may redistribute this newsletter for noncommercial purposes. For commercial use contact jack@ganssle.com.

Contents
Editor's Notes

Did you know it IS possible to create accurate schedules? Or that most projects consume 50% of the development time in debug and test, and that it’s not hard to slash that number drastically? Or that we know how to manage the quantitative relationship between complexity and bugs? Learn this and far more at my Better Firmware Faster class, presented at your facility. See https://www.ganssle.com/onsite.htm.

Freebies! We're giving away some Freescale Kinetis Cortex-M0+ development boards. More info in the article about a strange IDE later in this Muse.

Quotes and Thoughts

Harold Kraus sent this:

"Without requirements or design, programming is the art of adding bugs to an empty text file." - Louis Srygle

Tools and Tips

Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past.

Professor Erich Styger sent this:

While I teach the students that they should request from their employer budget and professional tools, it is always good to have a free/inexpensive open source solution at hand :-).

As for Tools and Tips, I would like to point to a recent article I have published on my blog recently:
http://mcuoneclipse.com/2014/12/26/code-coverage-for-embedded-target-with-eclipse-gcc-and-gcov/
It is about using GNU tools to create coverage/profiling information. They are widely used on Linux, but to my surprise not much for Embedded, even if they are very helpful. Yes, it needs a way to dump off the data from the device (debugger, serial, ...), but this technique does not require expensive hardware or tools: it is free. And it is definitely better than nothing ;-)

The other useful tool is an open source package which can turn any inexpensive board (e.g. a Freescale FRDM-KL25Z for $15) into a low cost/low speed logic analyzer:http://mcuoneclipse.com/2013/02/03/turning-the-freedom-board-into-a-logic-analyzer/

Jonathan Seidmann wrote:

As a firmware developer, I frequently need to send serial data back and forth between a micro and another device (usually a PC).  In the past I have used many different protocols, most of which have been custom for that application.  Recently I ran across Google's Protocol Buffers (https://developers.google.com/protocol-buffers/docs/overview) and thought it was a great idea.  Someone has taken the idea a step further and implemented it with embedded systems in mind (https://code.google.com/p/nanopb/).  Do you have any experience with or advice on the topic of serialization protocols?  It would be great to get feedback from other engineers via The Embedded Muse.

Ray Keefe likes Saleae's Logic Pro:

On the tools front, we are using the new Saleae digital+analog USB LSA + MSO and finding it very useful. Any pin can be digital or analog and that gives you 8 channels in a small form factor USB device. The sample rate is low so it doesn't suit high speed design and the analog range is 0-5V on the standard part but the Pro version does +/-10V which is very useful (you don’t have to pad and offset the data). They also have a 16 channel version. See https://www.saleae.com/

A Strange and Interesting IDE

The mbed people are getting a lot of press recently. It seems they are going in the direction of the cloud now, but their baseline tools remain really interesting. I wrote about this on embedded.com a couple of years ago, and here's an updated view.

IDEs are all pretty much the same. Sure, an IDE may be based on Eclipse, or could be proprietary, but basically they all consist of an enormous installable that gobbles as many resources as possible on your PC. In the embedded world most are PC-centric, though a few do support Linux or the Mac. In general these tools offer a huge wealth of resources for building and debugging firmware.

Then there's the mbed IDE.

mbed (yes, spelled with a lower-case "m") is an ARM-sponsored outfit that supports a number of low-cost development boards based on a variety of ARM Cortex-M series cores. The boards cost as little as $13. As is common today these cores have gobs of I/O ranging from simple analog to USB and Ethernet (depending on the board).

The following picture shows an mbed board I've used a lot recently. It has an NXP LPC-1768 core which is a Cortex M3 with 512KB of flash and 32 KB of RAM. It's the size of a 40 pin DIP and has a DIP pinout, which makes it easy to use it on solderless breadboards. And it connects to the development host via a USB cable which also provides power.

An embed eval board

The LPC1768 eval board.

mbed is in the IDE business but they won't sell you an IDE. Instead, the compiler is web-hosted and access to the environment is free.

Unpack the board and connect it to your computer. The thing looks just like a USB flash drive; click on the file named MBED.HTM and it will take your browser to their site. You'll have to register, but this gives you your own sandbox for storing code. Go to the compiler window, cut and paste one of their many examples and press "compile." Save the binary to the mbed board pseudo-drive and hit the reset on the board.

That's it. Your program is now running on the Cortex CPU.

Figure on ten minutes, tops, to get your first program going. I have never experienced such an easy-to-use development environment.

Being web-hosted the tools don't care what sort of host computer you're using. PC, Linux, Mac, heck, I imagine they'd run fine on a VAX if it had a web browser.

The IDE isn't a toy; that web interface is connected to the full ARM compiler.

Debugging resources are just about non-existent. Don't count on trace or complex breakpoints. Your code can toggle the board's LEDs to provide some debugging feedback, or you can use printfs which goes back up the USB link to a terminal window, and works surprisingly well.

I don't know about you, but I hate digging through the CPU's manual to figure out how to configure all of the peripheral's registers. Sure, some vendors have tools that will automatically generate the interface code, but that's never a painless process. On the mbed board all of that goes away. They have resources predefined to drive devices. So, to toggle a pin one might write:

#include   "mbed.h"      // This library has all of the definitions used below.
DigitalOut signal(p4);   // Use pin 4 as a digital output.
AnalogIn   adc(p19);     // Pin 19 will be a 12 bit ADC input.
  int i;
  float analog;
  
void main()
  signal.write = 1;      // Write to pin 4.
  i=signal.read;         // Read from pin 4.
  analog = adc.read();   // Read ADC from pin 19.
  }
                

That's it -- the tools will do all of the work to properly multiplex and configure the pins. Much of the headaches of doing embedded work disappears. There's no link process, no memory maps to puzzle out, and no I/O configuration. Interrupts are supported but you don't have to set up the vectors, NVIC, and all of that.

Without separate compilation and with only very limited debugger functionality the mbed toolchain is not suited to production work of anything other than very simple applications. But it is a fantastic resource for kids and others who want to get acquainted with embedded programming. I have found myself using it a lot for doing small scale experiments comprising under 1000 or so lines of code. It makes a heck of a data logger/controller, and is what I used to gather the several million data points about battery behavior described in this report: Hardware and Firmware Issues in Using Ultra-Low Power MCUs.

Freescale's FRDM-KL25Z is also supported. Its a board with a Cortex M0+, 128KB of flash and 16 KB RAM:

FRDM evaluation board

This is the same board Professor Erich Styger used in the Tools article above to build a logic analyzer. Freescale generously sent me some of these. So here's a giveaway! What's the best use you'd put one of these to? Send your answer to contest@ganssle.com. We can't answer the emails as we're usually bombarded with replies. However, a distinguished (when they are sober) panel of judges will pick the two most deserving or fun answers, and the winners will get one of these boards. Submissions due by January 28th.

mbed's web site is http://developer.mbed.org/. There you'll also find a ton of code, all ready to go. Their main site (www.mbed.org) now seems devoted to the cloud, IoT, and an OS which isn't available. When it does come out prepare for screams of agony from their RTOS partners. One does wonder how such a complex product will get the kind of support most developers require.

An Interesting Bug

In the last issue a reader had an interesting story about a tough bug. Chris Fischer contributed another:

The interesting bug in the 1/5/2015 reminded me of a bug I had fought, maybe it's worthy of a paragraph in your column.

Back in 1995, I was working as a consultant for a company whose main business was stock markets terminals. They saw a problem, asked me to look into it because it was somewhat tied into what I was working on.

Berkshire Hathaway's stock was at $33,000, but our terminals were screwing up the price when it updated. The initial paint of the stock quote came from a server, then it was updated locally as trades came in. The obvious thing to check is whether the price was in an unsigned short, and went over 32768. Berkshire is a hassle because they haven't split their stock.

Everything was in double precision floating point numbers, so that wasn't the problem.

Next day, Berkshire was around $31,000, everything worked fine. A few days later, it was around $33,000, and again it was failing.

Trolling through the floating point library, I noticed a lot of basic functions, i.e. one would be fdiv x; fwait;. Eventually I noticed that the multiply one didn't have an fwait command.

Turns out, the floating point co-processor executed most multiplication commands quick enough that the fwait wasn't needed. When the operand went over 16 bits of "real" data (as opposed to zeroes), it took went through a longer calculation, needed the missing fwait. So on days when Berkshire's price was over $32768, the floating point calcs would fail. When it was under, it would work fine.

A One-Instruction Microprocessor?

Some may remember Motorola's one-bit microprocessor, which was really made. But how about a one-instruction microprocessor? The implication, of course, is that no op codes are needed, greatly simplifying the design. In one implementation the instruction is "subtract and branch if negative." Typically an instruction has just pointers to the source and destination operands, plus the destination address if the branch is taken. There's more information here and here.

Vlad Z sent in this amusing concept for an even more compact design.

Then there's the zero-instruction computer, which is really different. If there are zero instructions, how many programmers are needed?

Jobs!

Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intents of this newsletter. Please keep it to 100 words. No charge for the ads.

 

Joke For The Week

Note: These jokes are archived at www.ganssle.com/jokes.htm.

From Colin Walls:

A friend set his status on Facebook: "I love couriers. A delivery is on its way, split into three packages. All left NL together. All arrived in GB together. Two are now in Gloucester, one in Exeter."

Another friend commented: "Couriers now use TCP/IP."

Advertise With Us

Advertise in The Embedded Muse! Over 23,000 embedded developers get this twice-monthly publication. .

About The Embedded Muse

The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com.

The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster.