Go here to sign up for The Embedded Muse.
logo The Embedded Muse
 Issue Number 246, October 7, 2013
Copyright 2013 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. To subscribe or unsubscribe go to https://www.ganssle.com/tem-subunsub.html or drop Jack an email.

Contents
Editor's Notes

Ad

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.

Better Firmware Faster Seminar

No ESC East? No Problem!

What? No Embedded Systems Conference in Boston?

We'll sure miss the cancelled ESC, but you can still come to my one-day Better Firmware Faster class near Boston November 1. It will be held at a hotel near Routes 90 and 495, about 38 miles from Boston's Logan airport and 39 from Providence's TF Green. This is the first public version of the class in two years.

This is a very fast-paced (and fun!) full-day course that teaches better ways to produce firmware. I'll show how to drastically cut bug rates and shorten schedules. Plus, I cover technical issues that are unique to embedded systems, like dealing with real-time issues.

There's more information here, and this is the course's brochure.

Seating is very limited so sign up today.
Quotes and Thoughts

The best programmers are not marginally better than merely good ones. They are an order-of-magnitude better, measured by whatever standard: conceptual creativity, speed, ingenuity of design, or problem-solving ability. - Randall E. Stross
Tools and Tips

Please submit neat ideas or thoughts about tools, techniques and resources you love or hate.

An article on EDN has a nice list of tools.

What I'm Reading

The Balancing Act of Choosing Nonblocking Features, September 2013 Communications of the ACM. An interesting look at nonblocking code.

Could the tunneling FET lead us past 6 nm?
Overpaid? Compared to What?

Mike Perkins had an interesting take on two things in the last Muse:

It would be interesting to put these two articles together: "Are (US) STEM Workers Overpaid?" (What I'm Reading) and "Compared to What"?

The assertion by others is that STEM workers are making too much. Ok. Compared to what? Compared to STEM workers in China? Or compared to factory workers in the US?

In China, a factory worker averages $1.36 per hour; in the US, the average (the link Mike supplied is now broken) is $23.32. That's a factor of 17. Also in China, a senior software engineer has a range from $16K -- 24K+. If we work the factor of 17, then the US software engineer's average income should be $20K x 17, or $340K.

Yes, it's crazy logic. Because fiddling with income is like fiddling with the US dollar - reality always gets down to the Principle of Supply and Demand.

The article you cited certainly was meant to evoke discussion. But to the larger readership of "Are STEM Workers Overpaid," the article is nothing more than a bid to make managers unhappy with what they pay US engineers. Maybe "they" should be talking about reducing US factory labor by the following formula: ($CHINA.SW.ENG / $US.SW.ENG) *
$US.FACTORY.LABOR where $US.FACTORY.LABOR = $23.32. That would certainly bring back the manufacturing sector to the US! Well, that would be a happy thought. All except for the now-poverty-stricken US factory workers.

The immutable fact is that it's a world market, and manufacturing drives any market, not engineering. So if the US wants to return to its stature of the 1950's where manufacturing was king, then the guys in Warshingtun have to fiddle with the manufacturing sector, not the engineering sector. That's because the manufacturing sector (the driver) automatically places demands on the engineering sector that perfectly follow the Principle of Supply and Demand.

But when we lose US manufacturing as we have and then gripe about engineering costs, the servo's shoe is on the wrong foot.
Working Overtime

Jan Woellhaf had a very original and thought-provoking idea about overtime work:

When I was a software engineer at Ampex in the mid 80's, I was up against a tight deadline. As an experiment, I asked the engineers working with me on the project to work for six hours a day. My observation was that when we worked twelve or more hours a day, we felt justified in goofing off, taking long lunch breaks, and working at less than full effort. But when we worked just six hours -- and got paid for eight -- we felt we had to work diligently every minute.

Reinhard Kopka reports from Austria:

As I'm working in Austria it's a clear thing. Most of it is regulated by law. And we are advised to act accordingly because the company might get in trouble if there are violations.

If not officially ordered every hour above my contract time get's summed up and I can take them 1:1 afterwards. Not more than 100 hours are allowed to sum up. Not more than 10 hours of work a day or 60 h/week are allowed.
If ordered, all time above the contract time (for the week) is "Überstunden" and get's an higher value of 1,5:1 . Everything on sundays or at night (after 20:00?) may even get 2:1 . I get time or money or a combination for that. But these hours are higher taxed, so in the end you get just a little bit more than regular.

Some of the (project) managers have all-inclusive contracts which include overtime, but they still fall under the legal boundaries of time limits and must get more money if the average value over a longer time (year) is higher than the contract says.

Nancy Blair wrote:

Working overtime is a topic near and dear to my heart. I, too, pulled all night shifts and sacrificed weekends in my early career. That is until the memorable year when I worked right through Christmas Eve, Christmas Day, etc. to meet an end of the year deadline and then, surprise, the company decided to wait until Q3 of the following year to release the product.

Ever since, the only overtime I've done for more than a brief spurt is when I've been at startups where the fate of the company really did hang on getting the job done.

Sadly, there is way too much "just work more hours" going on as a substitute for good project planning (including planning contingencies). If there is a study that shows that workers really are more productive after months of mandatory six day work weeks (often of ten hour days), I have yet to see it.

I recently had a management job where I would regularly butt heads with senior management. They would make proclamations about having people "work more hours!" I would respond with a reasonable question "is your goal to have cars in the parking lot on Saturday or is it to get a certain amount of work done?" Of course that never went over well, but seriously, how often have I heard from senior managers "I went home at 6:00 last night and the parking lot was empty!" Um, hello? Sounds to me like the problem you're trying to solve is cars in the parking lot which is a very different problem than a program behind schedule.

As for overtime compensation. Absolutely. I wouldn't have said that 20 years ago, but many tech companies are now using fear of job loss to keep driving their employees with no reward other than "you get to keep your job."

An anonymous reader had some information about working overtime in Germany:

Maximum working time limits established by the Working Time Act (Arbeitszeitgesetz )

The Arbeitszeitgesetz governs in § 3 sentence 2 a maximum working time of 10 hours . To prevent violations of this statutory limit, the following provision applies to the site of [company location] from 01.10.2013:

Attendance times > 10 hrs. / Day are cut automatically in future time management system. (Excepted from this employees meeting, fire-fighting operations, work/travel time on business trips )

The working day can be set in accordance with § 3 sentence 2 Working Time Act (Arbeitszeitgesetz ) up to 10 hours only extended when within 6 calendar months or within 24 weeks on average 8 hours per working day are not exceeded.

Therefore we would like to point out that a daily work more than 10 hours constitutes a violation of the Working Time Act ( Arbeitszeitgesetz ) and is only possible in special circumstances and under strict conditions:

This includes temporary work in emergencies (eg fire, explosion , flood ).

No exceptional circumstances within the meaning of § 14 Working Time Act ( Arbeitszeitgesetz ) are:

* Urgent project work to be done
* Urgent deadlines to be observed , delivery

In justified cases of emergency ( see above ) your employee has the opportunity to apply for a permit through the employee portal of excess (> 10 hours).

For the approval of these timeouts justification on your (meant is the addressed manager) part is required on the following points :

* why the employee in question has exceeded the maximum working time limit ,
* Why was the work at this time compelling and carried out by the employees concerned and
* what would otherwise have been the consequences.

Your reasoning may possibly be used as a basis for an audit by the "labor inspectorate" (Gewerbeaufsichtsamt: Office who controls that labour laws are respected). Keep in mind please, that you as a manager are also personally liable for subsequent approval for breaches of Working Time Act ( Arbeitszeitgesetz ) .

Please have your staff responsible for ensuring compliance of maximum working time limits under Working Time Act ( Arbeitszeitgesetz ) .

Note:
Requests of your coworkers for permission of a daily work time of more than 10 hr. cannot be released by a group authorization. Additional corrections of a requesting, a permission or a refusal of exceeding are not possible. Additional corrections of a requesting, a permission or a refusal of an excess are not possible. For an authorized exceeding
an additionally reservation has to take place of flexible working hours or additional work (over time message) in SAP.
Sleepy MCUs

Intel's FinFETs are helping push Moore's Law to sub-20 nm geometries, and recently TSMC showed their roadmap to 10 nm. FinFETs have a number of useful attributes, not the least offering a reduction in transistor power consumption. Intel's Atom processors can run on just a few watts of power.

A "few watts" is an enormous power budget compared to a lot of embedded MCUs that run on just 150-200 microamps/MHz. Even more astonishing are the sleep modes which can keep an MCU dormant but alive on tens of nanoamps. The goal is to run small systems for years (some foolishly claim decades) on just a small battery, like a CR2032 coin cell. These systems sleep nearly all of the time, waking once in a while to perform some action. Think smoke alarms, remote controls, and the like.

A CR2032 has about 220 mAh of capacity (quoted capacities vary a little depending on the vendor), which means it can source one mA for 220 hours. (There is some dependency on capacity vs. how fast one discharges the battery). Its nominal voltage is 3.0, perfect for these 1.8 to 2V min MCUs, and the discharge curve has a sharp knee. For some reason the vendors claim they run at 3.0 to 3.3 volts; my experiments show otherwise. The following curve is for 9 Energizers discharged at a 0.5 mAh rate. The load is then removed and various loads depicted by the curves momentarily applied. Batteries from Duracell, Maxell and Panasonic behave similarly.

Curve of Coin cells discharging

Batteries discharging at a 0.5 mA rate.

Some of the vendors claim their MCUs can run for 20-30 years from a single CR2032. That's may be true in theory, but not in practice. The vendor debate centers around how long a system can sleep on a coin cell, but that's simply irrelevant. The right question is: how much useful work can the system do while awake?

"Useful work" translates into a lot of things (clock rate, instruction set efficiency, etc), but is ultimately bounded by how much current the system (MCU and other components) can consume while awake. It's is the budget we have to work with, and cannot be exceeded (on average).

I came up with the following curve, which assumes a ten year battery life. It shows the number of mA available while awake as a function of time spent sleeping and amount of current consumed while sleeping.

Curve of current available from a coin cell
mA available as a function of sleep time and sleep current.

Here's a blowup for systems that sleep practically all of the time:

Curve of current from a coin cell when deeply sleeping

mA available for deeply-sleeping systems

Here's the key takeaway: Sleep currents are essentially irrelevant. And another important point: there's very little energy available for work when the processor is awake. Internet of Things? No chance, due to the power needed by communication, unless the system sleeps at least 99.99% of the time. In other words, it's awake 9 seconds per day or less.

The two sleeping graphs are theoretical. In practice the situation is much worse due to the batteries' discharge characteristics. More on that to come.

Board used to profile coin cells
Nine-cell battery profiler using an mbed ARM controller board. Transistors switch different loads on each battery to run various current and time profiles. Loads are low tempco, 1% resistors. An A/D reads battery voltages and Vce of the transistors. A precision reference and software calibrates the entire analog path.
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.
Joke For The Week

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

Patrick Wong writes: I found my Yahoo menu upside down (when I hover on my user ID). It was consistently upside down. I was joking myself Marissa Mayer/Yahoo must be pushing the boundaries (and teasing our brain or marketing ploy??).

joke
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.