JackGanssle

image
consultant

Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. Contact him at jack@ganssle.com. His website is www.ganssle.com.

JackGanssle

's contributions
Articles
Comments
    • Adieu dear friends. It's time to move on.

    • College is terrifying. Thankfully, trigger warnings reduce the risk of feeling bad.

    • Is reading becoming passé? What are your book habits?

    • The most dangerous activity we engage in is the one too many of us are too casual about.

    • Clinton is a shoo-in, since statistics never lie. Unless Trump wins.

    • Patent litigation, shady deals, Eros, and brilliant inspirations all contributed to the history of radio.

    • Fancy digital displays, smart phone apps, and other high tech tools give way to the perfect UI.

    • A new C book is a welcome addition to the literature.

    • Writing software is easy. Software engineering, though, is hard.

    • Are you a packrat? I'm not, and sometimes wish that wasn't the case.

    • There's never enough time to attend more than a handful of the presentations I want to see, but here are a few highlights.

    • What would you change if you could fix one thing about the C language?

    • What got you into this field? And what would you recommend for a young person wanting to get into electronics?

    • Names are a critical part of writing clear code.

    • Modules should start with great comment headers. Too many don't.

    • Alice Though the Looking Glass, Still Alice. There are a lot of Alices. Jack remembers one.

    • Virtual instruments are great, but give me knobs.

    • Automatic firmware upgrades are both a bane and a boon.

    • A resume has to be a compelling sales document; here are some pointers.

    • Why wouldn't you use an MPU in your next design?

    • Whither AI? Will the machines take over the world or will they destroy labor?

    • Just do it. Now. Life is shorter than you think.

    • It's time to dust off the textbooks and bone up on FETs operating below Vth because when Vgs is less than Vth, the world changes.

    • Ada Lovelace -- she never had access to any sort of computer but was she nevertheless the first programmer?

    • What language would you choose for your firmware?

    • I'm sure you, gentle reader, are the best software developer on your team. Heck, maybe in the world.

    • Schedules are vitally important. But they are not always the most important thing.

    • Bill Maher has his new rules. But there's an old rule: When in doubt, petition the Federal government for a solution.

    • Ints have limited ranges. Floats can be slow and memory hogs. Are there any alternatives?

    • The VW admission should cause us to think deeply about engineering ethics.

    • ST's ART accelerator gives near-zero wait state operation out of slow flash.

    • Protect the family jewels. Jack runs experiments EMI-Safe underwear.

    • An enormous engineering disaster rocked Louisiana ten years ago. Jack visited soon after.

    • How accurate are your requirements? Do you track this? There's plenty of historical data available.

    • The new book Real-Time Embedded Systems is dry, pretty mathy, but very complete with some important topics one rarely sees covered.

    • Here's part 2 of an interview with Datalight, a long-time provider of software products to the embedded industry. We discuss their approach to software engineering.

    • Here's part 1 of an interview with Datalight, a long-time provider of software products to the embedded industry. Old-timers will remember their ROM-DOS.

    • Robert Dewar, Ada pioneer, passed away last week. I only knew Dr. Dewar peripherally but had marveled at his intellect.

    • Are you an EE who spends all day writing firmware? A test engineer? A CS graduate who somehow found yourself in the embedded space?

    • That nervous twitch of the left hand to save files may be obsolete.

    • IT people live in a different world from firmware developers.

    • EEMBC is now scoring MCUs for energy consumption. Here’s a look at the tool they use.

    • Lusting for those early microprocessor days? Here’s a site guaranteed to sate your passion.

    • Did the paperless-office ever happen? To a first approximation, yes.

    • A tiny impurity in the fuel can damage a diesel. The answer: filters.

    • Software is inherently fragile. An MMU can prop it up.

    • Your hard disk will fail. What’s your backup strategy?

    • Your computer is infected. Follow these instructions.

    • Do you get components from RadioShack? That may not be an option much longer.

    • Flying is incredibly safe because accidents are analyzed. How about firmware engineering?

    • Bertrand Meyer’s latest book won’t make many agile enthusiasts happy.

    • How does a TV work? Just press the ‘on’ button.

    • Why your brown-out reset circuit is probably no good.

    • If there's one language that has gotten a bad rap, it's BASIC

    • Schematics.com offers a free schematic editor for those who wish to share their designs.

    • Hacker, Maker… do these neologisms imply only a facile level of understanding?

    • Agile luminary Ron Jeffries thinks it’s wrong to estimate schedules. Is it?

    • snprintf() is generally preferable to sprintf().

    • The new education mantra is “Learn to code.” I disagree.

    • In engineering we try to do things right, but more important is to do the right things.

    • Jonathan Franzen isn't keen on the Internet. Ganssle isn't so keen on Franzen, but agrees that some social media is a time sink.

    • We live in the age of screens: display screens are everywhere and each one has a graphical user interface. How are all these GUIs being designed?

    • A recent Embedded.com article assumes way too much about batteries.

    • Here are some tips to get embedded systems to market faster.

    • With keynote on Colossus -- possibly best computer-related talk Jack has heard -- ESC Brazil was bigger and better than ever.

    • Does a "typical" parameter in a datasheet have any meaning?

    • Every nanoampere counts in ultra-low powered MCU circuits. What about PCB contaminants?

    • The space program needed computers, lots of computers. Here's a new find about their history.

    • The sleep current war between MCU vendors is bogus.

    • Debugging is hard. We need to seed our code with constructs that find bugs automatically.

    • The Amish are said to want to manage, rather than reject, technology. That's not a bad idea to emulate.

    • The annual Coverity Scan Report is out, and has some interesting data.

    • Get any group of engineers together and see what they'll complain about . . . Embedded.com's parent company has released the results of a new survey with some fascinating data.

    • "Building Parallel, Embedded, and Real-Time Applications with Ada" is a new and important book I recommend even to those who will never write a line of Ada.

    • Stability and security are the least important career drivers when young. Go for the wild and crazy!

    • Here's a cool kit of parts for folks who want to experiment with analog circuits.

    • Benchmarking is like statistics; it's easy to fiddle with the results. CoreMark strives to be more quantitative.

    • My Ada article generated lots of discussion. Here are some answers to your questions.

    • Low-pin count, low-cost MCUs always interest me. Now NXP has 32 bit parts in this category.

    • It's over. Nothing really changed. Do we need more engineers in elected office?

    • The holy grail of battery-powered devices is 20 years on a single cell. But is that really achievable?

    • There’s a scientific way to compute the lower bound of how many tests on a function are enough

    • Need an MCU with on-board USB controller? Microchip has upped the ante by lowering the cost and form factor.

    • The latest version, Ada 2012, includes some important improvements.

    • A new Microsoft motto aims to inspire but misses the mark.

    • Sequence points are one of C’s dark corners that trip people up.

    • Testing is important. But it’s just one quality gate.

    • A column by Micheal Barr got readers and Jack Ganssle thinking about the future of 8 bits. Will 32 bitters take over?

    • The world runs on GPS, but only in recent years.

    • Some numbers illustrate the cost of ignoring quality.

    • Building a safe system requires a level of systems thinking that may be impossible.

    • Jack Ganssle, the MVP of ESD and Embedded.com, reflects on how a good concept 24 years ago touched his life and those of other developers.

    • Our hobbies often define our careers.

    • Ham radio, and the ESC, are now both paths into engineering.

    • We all hate sales, but must be good at one aspect of selling.

    • The wrong probe can cause your circuit to fail or even physically destroy components. Here are some of the issues.

    • Jack has fun describing some of his favorite quirky chips from the past; some of these are still around.

    • A nearly-perfect display technology already sits on our noses.

    • Finally, there’s a book about patterns for firmware.

    • Some smart phone apps do some amazing things. Others are designed to distance us from humanity, or turn us into sociopaths.

    • Before the microprocessor, it was absurd to consider adding a computer to a product; now, in general, only the quirky build anything electronic without embedded intelligence.

    • Vampire devices suck up an awful lot of power, often for no good reason.

    • In part 3 of Jack's series honoring the 40th anniversary of the microprocessor, the minis create a new niche—the embedded system.

    • Sometimes a puddle of gates makes a lot more sense than a sea of gates.

    • Firmware is the most expensive part of engineering a product. Tools reduce those costs. Yet developers have a hard time getting management to pony up the cash.

    • From Patent 307,031 to a computer laden with 100,000 vacuum tubes, these milestones in first 70 years of electronics made the MCU possible.

    • Tony Sale, who built a replica of Colossus, passed away this month at 80.

    • The electronics market is set to drastically expand… or fail. Take your pick.

    • The old ways of developing embedded systems just don’t scale. ESC Boston is the place to go to learn better approaches.

    • Heathkit, the fabled electronics kits company, is going back into that business after a two-decade hiatus.

    • Two hugely important inventions were introduced this week, 20 and 30 years ago.

    • An engineer's duty is to assume nothing, think of everything, and be humble. After all, building an embedded system is a humbling experience.

    • Debugging is a learned skill, not one acquired by accident. Here’s a good book on the subject.

    • If robots do all our work, what will happen to us? And a tiny oscilloscope sparks the imagination.

    • The Embedded Systems Conference often offers some wild and fun activities.

    • Fun with failure: The spectacular failures of others are spectacular lessons for engineers. Jack Ganssle recounts the riveting lore of engineering failures.

    • GPS is becoming as ubiquitous as the power grid – which is both good and bad.

    • After pressing, twisting, and pushing knobs, Jack Ganssle likes what he sees in a new mixed-signal scope series from Agilent Technologies.

    • Vendors and researchers are trying some new tricks with watchdog timers. Here are some notable attempts to improve the old dog.

    • From Microchip’s eXtreme Low Power to TI’s OMAP, new chips contain some interesting and complex power management techniques.

    • Win valuable prizes in a 555 timer contest!

    • Linux and Android are the future. Or are they?

    • Science and technology: It’s a growing trend in America’s basements.

    • Four bits is still around, though seems to be as stealthy as an F-117

    • Lifetime employment died decades ago. How often do you change jobs?

    • Conventional wisdom is that low-end processors are a dead-end.

    • Catching up with the incoming product announcements, Jack Ganssle finds a few gems (and some horror stories) to share.

    • In a two part series, Jack Ganssle, editor of “Embedded Systems: World Class Designs,” passes on some tips about embedded systems design gained from his experiences as both a designer and a manager of hardware and software projects.

    • The modern era is nearly defined by the devices that clamor for our attention. One, though, is guiltier than most.

    • What’s most important? Schedule? Cost? Maybe none of these.

    • The old paper and pencil are your most important (and easy to use) tools to help you remember the how and why of your system design.

    • Cubicles are productivity-killers. Yet they’re here to stay.

    • David Alan Grier's book "When Computer Were Human" is a fascinating read on the precomputer era of human computation.

    • Multitasking during sex? That makes as much sense as multitasking while developing.

    • The first installation of Breakpoints appeared June 1990, 20 years ago this month. Jack looks back.

    • Hacking a car sounds farfetched, but it’s possible today.

    • How much is enough? Rockefeller said “just a little more.” Engineers do well compared to other Americans.

    • Are developers starting to think about moving beyond C and C++?

    • Jack Ganssle explores the agony and ecstasy of developing embedded systems.

    • Jack Ganssle puts the Agile Manifesto's James Grenning on the hot seat about test-driven development's suitability for embedded systems.

    • Jack's 2009 salary survey is now out, and the data is interesting.

    • Jack Ganssle takes a look at Tektronix's MSO2024, the oscilloscope being given away at the ESC SV 2010.

    • Board testing is harder than you think, but there are solutions

    • A trip down memory lane reveals more about how memory radically changed the nature of digital electronics.

    • Jack Ganssle presents some of the best programming-related quips for your enjoyment . . . and instruction.

    • The Embedded Systems Conference is the best event for our industry. Did you go?

    • Though raises are seriously off, most of us are happy with our career choice.

    • How can we know if a system, and in particular the software, is dependable? An interesting, well-written book tackles this question.

    • A new OS has been proven to be correct using mathematical proofs. The cost: astronomical.

    • Linux is the solution to all engineering problems. Or is it?

    • In an interesting exchange at the ESC, attendees had useful thoughts on finding jobs in bad times

    • The fastest and most effective way to debug hardware or software involves using a disciplined process. Here are six steps for debugging.

    • From oral tradition and clay tablets all the way to modern memory devices, Jack Ganssle traces the history of memory.

    • What role did Wernher von Braun play in getting us to the moon?

    • Embedded work is increasing looking like conventional programming. But it isn't and never will be conventional.

    • Deep Agile 2009 explored using agile methods in embedded development

    • Amazon's Kindle 2 gets the ebook just about right

    • Virginia loses a pile of data. How could this happen?

    • Apollo 13 astronaut Ken Mattingly stresses teamwork as the real hero of the famous space saga: thousands of people doing their absolute best. It's a good lesson for a hard time.

    • Engineers are no longer immune from the recession. What's your job-seeking strategy?

    • Few of us collect metrics. That's not what engineering is all about.

    • No one cares about your career except you. Or, do you?

    • Will embedded systems engineering be a viable career in the United States in the near future? A trip to Asia made Jack ponder.

    • Language is important. That includes spelling and grammar, whether "your" writing ad copy or comments. (The word misuse is intentional).

    • 8 bits will never go away. In fact, various vendors have some pretty cool new parts available.

    • Last week's column on the Ada language generated a lot of comment. Here's more on the lack of adoption of this language - and on career inertia.

    • Max Maxfield has ruined my year. Unless I fail to keep the resolution.

    • Inspecting code is an important group exercise that's painless if you follow etiquette and stay within its narrow scope.

    • Security is usually neglected in the embedded space. Now there are some options.

    • What's the cheapest way to get rid of bugs? Inspect code early and often.

    • The iPod was designed to be beautiful. Many mundane products weren't but are.

    • Bell Labs, sadly, is refocusing to concentrate on near-term problems rather than basic research.

    • Experts tell us interesting facts about our work lives that we may know but deny: programmers have human limitations.

    • We're counting the dollars as the financial mess expands. Has anyone counted how much code we're produced?

    • WARNING! Do not insert neck into sawblade! Do not start car before adjusting seatbelts!

    • A new book describes the creation of the Apollo Guidance Computer in the detail only an engineer can love...and engineers WILL love it.

    • More stories abound about electronics steering us wrong. Both users and developers need to step up to the plate.

    • Prototyping software is an essential step in creating quality embedded systems and a sane work environment. Here's why.

    • A new survey pegs software as recession-proof. Does that scale to embedded development?

    • When will an ASIC project cost a billion bucks? You might be surprised.

    • We're drowning in information. One way to capture it is the use of Brain Books.

    • Too many supposedly educated people feel the modern world of science and technology to be utterly inaccessible.

    • When there's not an absolute expectation that products will be correct, they won't be.

    • Do CS departments come even close to producing graduates that meet the needs of the firmware community?

    • What will life be like for the embedded systems developer in 2028, especially if certain trends continue?

    • New grads learn on huge systems. Are they prepared for resource-constrained system development?

    • Wouldn't it be nice to see the A/D's output all the time? A continuous graph might be even nicer. Or watch all of the stack pointers' high water marks? Here's a tool that does just that.

    • Studies suggest overtime is counterproductive. But it's still commonplace.

    • Despite all of the promises of the e-age, most engineers continue to commute to the office every day.

    • In the days of guilds craftspeople were expected to serve a long apprenticeship. Is this appropriate for engineers as well?

    • Programs on the scale of a million lines of code are getting more common. But how big is that?

    • Twenty years is a long time in human terms and even longer in the microprocessor industry. Here's a look at what's transpired.

    • Research and Development. R&D. It's the lifeblood of tech companies, and it's what we engineers do all day, every day. Nonsense.

    • How much math do you use in your job?

    • Data has no value. That's my conclusion based on how poorly we take care of it.

    • Google Trends suggests a declining interest in embedded subjects.

    • Isaac Asimov's Three Laws are neither sufficient nor applicable only to traditional human-like robots

    • The first-ever Embedded Systems Conference in India exceeded all expectations

    • Consulting can be a very rewarding job, but be prepared: it's not for the faint of heart. Here's what you need for success.

    • Is it impossible to build a warranted product from components that disclaim any sort of guarantee?

    • Engineers are telling me they're unhappy being compromised by offshoring and guest worker visas.

    • Are you an East Coastie? Don't you dare miss the Boston ESC!

    • The Boston ESC is around the corner. This year we have some fantastic talks segmented into a number of tracks.

    • The Agile 2007 conference catered mostly to PC types, but some embedded heads showed up.

    • Ads: Love 'em? Hate 'em? Some are great

    • H-1B Visas are always a hot topic. Here's a fascinating link about the issue.

    • A survey suggests we waste 20% of the workday. Can this be true?

    • Is a watchdog timer a crutch for lousy developers or a wise bit of insurance?

    • Once it was possible to fall into an engineering job without a lot of credentials. Now one needs an appropriate degree.

    • The agile community's primary conference occurs in August, and looks to be quite interesting.

    • There are some 7,000 languages used today on this planet, suggesting a veritable Babel of poor communication.

    • Engineers are usually curious about the world. But is that a recessive trait?

    • Legacy code, no matter how bad, will be the foundation for most products of the future.

    • Does your company block access to parts of the Internet? Why?

    • What's in your toolbox? Do you favor proprietary tools or those that are open source?

    • When selecting a software tool, the only important consideration seems to be price.

    • Telecommuting still has a small presence in the embedded space. Why?

    • What is a superprogrammer? An undisciplined hacker with social failings or someone with another set of characteristics?

    • Preemptive multitasking is inherently non-deterministic, but RMA can change that. But does anyone use it?

    • Nohau USA is dead. Long live Nohau USA.

    • It's the project's end. Do you know where your resources are?

    • Reformat hard drive. Lose $39 billion.

    • Duane, I'm with you, especially on the multiple tries thing. Once it took me 5 trips to Home Depot to get the right parts to fix a plumbing problem! Gads, I was ticked. Jack

    • Bob, It might be hard to do - how do you know what direction the wind is coming from unless referenced to, say, a compass heading? However, as a backup to the backup systems we carry an old autopilot meant for tiller-steered boards that uses a linear actuator to follow a compass course. I can connect that to the sail. Since the sail is so easy to move the system takes almost no power.

    • Dennis, I had forgotten Bucky's prediction. He was such an interesting guy. I met him once and was floored by his energy, even though he was in his 80s. Jack

    • Steve, So that means transistors have gotten so cheap they can add gobs to a chip... and not use them! It's sort of like early transistor radios. They'd advertise "8 transistors!" but 3 would be failed parts not used in the circuit.

    • Interesting idea. To my knowledge there's no exposed API. But the Windows application can take a .csv file so I suppose one could (painfully!) create a CAN packet in Excel and important that.

    • There are a lot of variations (see Karl Weiger's book on the subject) but the idea is to have multiple people in defined roles work through the code, line by line, BEFORE it is ever tested. Studies show this is much cheaper, and more effective, than testing (though testing remains hugely important). Even better: the code being reviewed is already of a higher quality than most, because the author is more careful in writing it. Who wants their mistakes pointed out? This is what we want: carefully constructed mostly correct code, rather than code which is beaten into submission by frantic debug sessions.

    • Garry, Here we cherish our first amendment rights. I'm sorry you got locked out of the site for expressing an opinion!

    • John, I have used the original uCurrent and like it, and reviewed it here: http://www.ganssle.com/reviews/review_of_ucurrent.html The bandwidth was only a couple of KHz, though I'm told the newer unit is faster. There are three ranges you select with a switch, which may be a pain for systems whose consumption changes rapidly. But you get more gain than with the AMPERE so it's easier to measure lower currents. Everything is a tradeoff...

    • Bob, Rule 5 is the bane of the singlehander. We do our best to keep a decent lookout, but the bottom line is we're in violation of the COLREGs; should an accident happen a court would not be happy. But at sea we're the smallest thing around and can't possibly damage a ship. That's a great article. I was in New Orleans a week ago watching ships on the river making a turn in a severe current, and every time it looked like they were going to hit the river banks. Those pilots are amazing, and one can only think of Mark Twain's stories.

    • That's about $14 in today's dollars, or roughly a penny a bit. I bought a 128 GB thumb drive recently for $45, or about one microcent/bit.

    • Charles, I don't see a lot of R series parts in use. Automotive is using some. Agreed that the M0 and M0+ are incredible parts. They can fit in 0.01 mm**2 in a 40 nm process (CPU only). But the M3 and M4 are no slouches and offer a ton of performance for an MCU. The lockstep is in part driven by various standards, which in some cases require extreme testing during normal operation. For example, 60370 requires that the CPU's registers and instructions be tested periodically. One would think that a register (say, SP or PC) failure would make such testing impossible.

    • Rich, If you ever get out this way look me up. We're in Finksburg. Carroll County is still agrarian and is a great place to live.

    • I will put together a piece about this. Basically, an MCU activated transistors to put various loads on the cells. The voltages were measured, as was the Vce drop on the transistors. All was fed through analog muxes to an A/D. A precision voltage reference was also fed through the mux so the software could calibrate out errors from temperature, etc.

    • This morning I got an ad/email from Saelig - they are selling this scope for a limited time for $299. It says to use coupon code S1407. http://www.saelig.com/PSBE1002/PSBE1002017.htm

    • Bob, I talked to several IC vendors and they tell me the min/max specs are guaranteed. However, there's sometimes a disclaimer in the datasheets about using their components in life-critical applications. I imagine this is to provide shielding from lawsuits.

    • Dale was unable to post, so asked me to do this for him: We build products to stringent ATEX Intrinsically Safe certification. I scoured the planet and found a Schottky diode with a low Vf. The MBR1020V has a typical Vf of 0.25 V at 100 mA and 25 C. Usually, low Vf diodes have higher leakage currents, although this one is typically under 30 uA at a Vr of 5V and 25 C. (Has any one found anything better?) And, if this leakage is too high for your circuit requirements (e.g., parallel battery legs), you may be able to use two different Schottky diodes in series, one with very low Vf and one with low reverse leakage. I would guess that UL, like ATEX, doesn't allow "active" protection circuitry such as MOSFETs. And, any comments on the feasibility of germanium Schottky diodes for this purpose? ---------

    • Steve, I haven't had much interest from the MCU vendors, but it's possible my contacts are the wrong people. Jack

    • Oh, and I should say alert reader Bob Snyder informed me about the UL rules, which I was clueless about.

    • Interesting idea about paralleling the batteries, Charles. Nice systems engineering! If the voltages are different current will flow, reducing capacity. And UL has some strong and onerous rules about letting current flow into a coin cell, which is in an article to come shortly. I have to think this through.

    • Thanks, Doug. The subject is quite interesting. I have three more articles about this in the queue, but it will have to go on hiatus for a bit after that. I have collected a ton of new data and it'll take weeks to reduce it. And, I've just started more experiments to sort out some odd battery behavior, but each experiment takes a month to run and longer for me to find the time to reduce the data.

    • Yes, I'm assuming a LiMnO2 coin cell. A supercap won't help - see last week's column: http://www.embedded.com/electronics-blogs/break-points/4430050/Using-a-capacitor-to-sustain-battery-life

    • Bob, In other experiments I found that for a mostly-sleeping system, infrequent pulse loads up to 30 mA didn't make any measurable difference in total capacity. I did find the Nordic study interesting, but the paper was not very descriptive of their experimental methods, and multiple attempts to contact the authors failed.

    • I removed it on purpose as the numbers aren't important. It's time, assuming some constant-ish rate of discharge. For a system with a ten year life, consider the left side 0 years and the far right 10 years.

    • AAAs are a great solution as they have around 4x the capacity of a CR2032. But, you'll either need two to get enough voltage to power most MCUs, or a boost converter. Some people are put off by the required inductor, but often those are surprisingly inexpensive. Also, the IR of an AAA doesn't go up nearly as fast as it does for coin cells.

    • That paper is part of what initially spawned my interest in the subject. Unfortunately there's no data about how many batteries were tested or other aspects of the experimental setup. The graphs look awfully smooth, like someone drew them with a crayola. I have attempted on multiple occasions to contact the two authors with no success. Still, it's quite interesting and worth reading.

    • The harder you load a battery, the less capacity it has. Pull 100 mA from a CR2032 and you will get much less than the rated 220 mAh. Some of my other experiments confirm published data that for a load of 0.5 mA on average or less you can get the full 220 mAh. So, if your load is less than that, you can compute available mA from a battery vs time; no experiment is needed. As you can see from the graphs here, the IR will go up. But if your load is low the drop in V from IR will be low. Most RTCs need very little juice. For a ten year life from a CR2032 you cannot pull, on average, more than 2.5 uA.

    • Thanks, everyone, for your interest in this fascinating and fun subject. The TI paper looks at loss of capacity due to discharging the batteries relatively quickly. Their sleep times are very short. My data is all for the opposite situation, where discharge time takes 10 years, mirroring these sorts of very long lived, ultra low power applications where the MCU is nearly always asleep. I have no data for batteries discharged as the paper's authors did, so can't comment. However, the devil is in the details and the solution presented in the paper is not entirely practical. I had planned to write about another subject for next week, but will instead try to get my results for using a capacitor together for that article. Stay tuned!

    • A BR2032 only has 190 mA of capacity, and that drops a lot if it is used in a cold environment. 190 mA over 10 years means the system's average draw cannot exceed 2 uA. It sounds like your system will be hot; you may have to assume the worst case power-down current of 4 uA, so the system can't last more than 5 years, even if it never wakes up. Note the 4 uA spec is with T1OSC and all peripherals off; will the timer even run? The frustrating part of the two bad batteries is that they tested OK. They were "bad" simply because they only delivered half their rated capacity. That sounded like a mixup with a smaller battery, but I examined them under a microscope and with a micrometer and found them marked exactly like the other CR2032s with the same dimensions. Strange! More coming on this subject in coming weeks and months.

    • Rich, A lot of it was ground bounce that caused incorrect latching. As an electronics technician in high school in the late 60s I was taught that "ground is ground the world around." Unfortunately, it's not. Reactance in PCB tracks limits how fast energy can be transferred. Jack

    • That's a great link! Thanks for making my day.

    • By this I mean that one should not count errors detected by the compiler. Compile the code, fix all of the problems it finds, and count all subsequent errors.

    • Charles, You're right. The 10**-15 error is some sort of transcription mistake going from Word to HTML. The 0.18 nA is my goof. Thanks! Jack

    • This is a very difficult issue. Some on-chip brownout detectors require far more current than the MCU core does in sleep mode. Writing to flash usually takes quite a lot of energy. And holding up the power using a capacitor will (probably) not work. If you do the time constant math, it will take a sizable cap, and the cap's leakage is proportional to it's size in Farads. So a big enough cap will probably leak more microamps than the MCU uses when sleeping. You'll have to use a ceramic cap (tantalums leak like an NSA whistleblower), and for some of the analysis I have done either it's impossible to get a cap of the required size, or it will cost $10 or more. I'll cover these issues more deeply in a future article.

    • Good question! The batteries go to low-R analog switches, which then feed a non-inverting voltage follower before going to the A/D. The voltage follower's input impedance is extremely high.

    • Yes, Marcus tells me their ISP is having trouble this week. I know he and his people are working furiously to get it back up.

    • I walked into the house today and my wife told me her sister-in-law had called from the car, but suddenly, while talking, sideswiped a car, on a high bridge over a river. 5 minutes later she called again: now she was still on the bridge, still driving, following the other car and a cop to a safe spot!

    • For some reason I remember Goldwater's callsign - K7UGA. When he ran for president my dad had a bumpersticker that read AuH20.

    • I just learned that the 8X300 was used in more than 30% of fixed disk controllers for a while. So it did have some decent market share. Thanks for the correction, Eric.

    • UPDATE: A reader sent me this link (http://www.infoage.org/html/tiros1-2.html ). A group of volunteers are maintaining and improving the 60 foot dish antenna that received TIROS's signals. Fascinating site, and a worthy place to support.

    • Patrick, Good point. But I disagree about English. It's notoriously imprecise. It's like C - a tiny change greatly alters the meaning. Consider: Eats, shoots, and leaves. Vs Eats shoots and leaves. (Think panda bears) One reason we have so many problems with software is the code is derived from an imprecise English-language specification. I suppose the alternative is formal methods, but they probably won't make many inroads in the near future. Jack

    • Sure, Dave, I'd love to read it (though it takes me forever to get to a book, as my input stack is so high). Drop me an email at jack@ganssle.com. Also do check out Steve Litt's site: troubleshooters.com. Jack

    • Null, The surveys are still coming in. It'll take a couple of weeks to get them all, and then to digest the data (this is a part-time pro bono project). I'll post a link to the results in early December. Jack

    • A reader passed along this link: http://www.embedded.com/columns/technicalinsights/208404177?_requestid=694574 which says there are exemptions in TX for engineers working as employees of companies. So maybe it is OK for non-PEs in TX to use the word "engineer" in their titles. Jack

    • Roberto, Sure, I've zipped up the 50 or so pics I took at the Park. It's a 160MB file available at www.ganssle.com/misc/bp.zip. But the best ones are those in this article. Jack

    • The problem with the Google maps picture is that the latitude was converted to 19' 60", which is mathematically correct but absolutely wrong. 60 seconds of arc must roll over to 59, just like seconds of time. Jack