TEM Logo The Embedded Muse
 Issue Number 263, June 16, 2014
Copyright 2014 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.

Go here to sign up for The Embedded Muse.
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.

Embedded Video

I've posted two new videos:

Episode 2: The Perils of Probing: What's Inside That Scope Probe? Why anyone who uses a scope needs to understand that the probe is far more than a wire.

Episode 3: LabTool: A Fairly-Decent Low-Cost Scope/Logic Analyzer. This is a review of the LabTool USB scope/logic analyzer/function generator.

There will always be a link to the latest video here. A complete list is here.

Quotes and Thoughts

The number of defects found in production use will be inversely proportional to the percent of defects removed prior to integration, system, and acceptance testing. - Girish Seshagiri
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.

Miro Samek has a free set of videos on YouTube which explain the basics (and more) of writing in C for the ARM Cortex-M series of parts. This is one of the more important microprocessor families around today. If you buy the suggested $12.95 board, you can use IAR's free IDE (Miro shows exactly how to obtain and configure it) and work in parallel with the lessons. Unlike other C classes, in this series you'll get exposed to both the C code and what the processor is really doing behind the scenes. That's critical info for any embedded developer. Highly recommended.

We've had no recommendations for FileZilla, so here's a plug for that free FTP tool. It's small, fast, and doesn't continually nag for updates. Linux and Mac versions are available, though I have not used those. It will queue multiple file transfer and can even be configured to limit bandwidth usage. I find FileZilla so useful it's pinned to my task bar. There is a server version available as well, also for free.

Jon Titus had a debugging suggestion:

A few years ago I bought a small thermal receipt printer on Ebay for $50 or so. The printer required only a serial input for complete control of printing, fonts, and so on. When working with small MCUs, the printer provided an easy way to get a hard copy of information at specific points in my code. And because the printer didn't require a printer library with all its overhead, I could easily do bit-bashing if the MCU didn't have an open serial output. I still see serial receipt printers on Ebay for under $100. Tip: Instead of buying a caseload of thermal paper rolls, ask a local store for a roll. It will last a long time.

It's an Ithaca Series 80PLUS-S-AC. It came with a separate power-supply module and cables. And it has a standard 9-pin serial connector that provides all the RS-232 signals. People can find the setup and programmer's guide at: http://www.transact-tech.com/drivers/series-80. I like this printer because it has a "Hexadecimal Dump" mode that displays received bytes as hex values and equivalent ASCII characters. That mode eliminates the need to convert a byte to ASCII before it prints a hex value. Many other modes, fonts, graphics, etc., available with a few commands via the serial input.

The printer has two RJ-45 connectors for cash-drawer outputs, but I haven't used those signals for debugging MCU circuits or code. The outputs on these connectors supply a +24V DC signal under software control (via a serial command), so someone might use them to control a relay, buzzer, solenoid, etc.
On Computing Worst-Case Execution Time

In its early years, Embedded Systems Programming magazine had a very strong anti-vendor bias. They never ran articles or even useful information, other than press releases and ads, from manufacturers. I have always disagreed, thinking that the vendors often know far more about a particular problem than any individual engineer. One does have to strike a balance, of course, between the informational and the self-serving.

In response to articles in Muses 261 and 262, Andrew Coombes from Rapita had what I feel are very worthwhile thoughts about figuring worst-case execution time, and in this case his affiliation is helpful:

Declaration up front: "I've got a dog in this fight". I work for Rapita Systems who provide a WCET tool based on the hybrid approach, as opposed to AbsInt, who use static analysis for WCET.

It's generally not possible to give an exact value for WCET - Despite academic research over the last thirty years, there currently is no way to find the "actual WCET" for any reasonably large piece of code running on a modern processor (especially in the presence of cache, pipelines and increasingly, multicore). Instead, the aim of WCET analysis when applied in the context of real, live, engineering projects must be to find a useful and valid approximation of the actual WCET. Although it seems reasonable to err on the side of caution, performing WCET analysis that is guaranteed never to be optimistic typically results in a predicted WCET value that is so pessimistic that it is of no practical use. For example, if your WCET analysis assumes that every cache access results in a cache miss, either your system will be unable to meet its deadlines or there's no point in deploying your system with the cache enabled.

Although the static analysis approach to WCET has been the favoured approach of academia for many years, the use of measurements tends to be the more practical approach, and consequently the approach used by many systems currently in development (and for a large number of deployed systems). In practice, the optimism of a measurement-based approach is reduced by adding a "safety margin". For example, adding 20% to the longest observed execution time. Because of the vast number of possible paths through the code, that could be taken, there is still the concern that you could miss a long execution time.

I would be derelict in my job if I didn't mention RapiTime as a tool for supporting the measurement based approach to WCET. It uses measurements of execution time, combined with a model of the code to predict paths through the code that lead to the worst-case execution time.

Sources:
* http://www.dit.upm.es/~str/papers/pdf/garrido&13a.pdf (Jorge Garrido, Juan Zamorano, and Juan A. de la Puente, Static analysis of WCET in a satellite software subsystem, 13th International Workshop on Worst-Case Execution Time Analysis (WCET 2013) -- shows static WCET gives a predicted WCET of 72366 cycles vs 8400 cycles for a measured approach

 
Open Offices

The January issue of The New Yorker has an article titled "The Open-Office Trap" by Maria Konnikova which I recommend for people condemned to an open office arrangement. The article cites studies (unfortunately mostly paywalled) that conclude:

  • Employees in an open office environment feel more laid back and innovative, but in fact their attention spans are degraded as is productivity, creative thinking and satisfaction.

  • Stress levels are higher and motivation suffers.

  • One survey of 38k workers found interrupts are productivity-killers, which backs up DeMarco and Lister's work described in the book Peopleware. In fact, DeMarco and Lister found interruptions utterly destroy the productivity of software engineers.

  • Workers in offices with two people per room take 50% more sick leave than those with private offices; in fully open offices the rate goes to 62%.

Generalizing is fraught with peril, but in engineering much of our work is defined by deep individual concentration. Interrupts and high noise levels makes that hard.

Open office environments are taking over from the cube farms so many companies use. Robert Propst invented the Action Office, the predecessor to the cube, to reduce interruptions and communications since, in the 60s, most offices featured a big room filled with desks. Propst wanted workers to have individual control over their spaces, and now says "The cubicle-izing of people in modern corporations is monolithic insanity."
Jobs!

Let me know if you’re hiring embedded engineers. I reserve the right to edit ads to fit the format and intents of this newsletter. Please keep it to 100 words.
Joke For The Week

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

David Paulson sent this:

"Arguing with an engineer is like wrestling a pig in mud, after a couple hours you realize the pig likes it"
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.