You may redistribute this newsletter for noncommercial purposes. For commercial use contact firstname.lastname@example.org. To subscribe or unsubscribe go to http://www.ganssle.com/tem-subunsub.html or drop Jack an email.
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 http://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.
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
|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:
I'll present my Better Firmware Faster seminar in Melbourne and Perth, Australia February 20 and 26th. All are invited. More info here. The early registration discount ends January 20.
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.
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.
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
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 ,
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 ) .
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.
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.
mA available as a function of sleep time and sleep current.
Here's a blowup for systems that sleep practically all of the time:
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.
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.
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.
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??).
Advertise in The Embedded Muse! Over 23,000 embedded developers get this twice-monthly publication. For more information email us at email@example.com.
The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at firstname.lastname@example.org.
The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at email@example.com for more information.