Go here to sign up for The Embedded Muse.
The Embedded Muse Logo The Embedded Muse
Issue Number 385, November 4, 2019
Copyright 2019 The Ganssle Group

Editor: Jack Ganssle, jack@ganssle.com

   Jack Ganssle, Editor of The Embedded Muse

You may redistribute this newsletter for non-commercial purposes. For commercial use contact jack@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email.

Editor's Notes

Express Logic

Over 400 companies and more than 7000 engineers have benefited from my Better Firmware Faster seminar held on-site, at their companies. Want to crank up your productivity and decrease shipped bugs? Spend a day with me learning how to debug your development processes.

Attendees have blogged about the seminar, for example, here, here and here.

I'll present the Better Firmware Faster seminar in Melbourne and Perth, Australia February 20 and 26th. All are invited. More info here. As I noted in a recent blog, I'm cutting back significantly on travel, so this will be my last trip to Australia.

Jack's latest blog: 2019's Most Important Lesson

Quotes and Thoughts

"With the past coming down the road so fast, we are going to have to address it in the future" Perkins McGuire

Tools and Tips

SEGGER Embedded Studio The leading cross platform IDE

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

Bob Paddock submitted this idea for bi-directional comm using just an LED. Part of the secret sauce? Reverse-biasing an LED makes it a photoreceptor:

Back in 2003 Mitsubishi Electric Research Laboratories (MERL) came up with a way to use an LED for bidirectional communication.
While not fast, it is effectively free because most systems already have an LED for something. Good for configuration or debugging port where speed is not a high requirement.


Many micros have a comparator input that simplifies their method a bit.

Roy Tellason sent an excellent link to a paper about monitoring and balancing Li-ion cells in electric vehicles.

Stephen Bernhoeft sent in an idea from Bob Pease's book Troubleshooting Analog Circuits. It's another way to use a backwards FET to protect against an improperly-inserted batter.

And Joe Vandzura added this:

In regard to reverse polarity protection with a FET:

When you don't have to worry about a common reference potential, a N-channel FET on the bottom rail is even better than a P-channel on the top rail.

For any given current, they're cheaper, smaller and more efficient.

Chris Hemingway has a debugging tip:

Not quite a tool, but I found an article suggesting an interesting alternative to using the full MPU on Cortex-M3/4 to detect data overwrites, using data watchpoints to catch the write and trigger an interrupt.

This is a neat trick to find the cause of memory corruption errors on deployed devices I think, especially if you can't recreate the issue in the lab, but can push new firmware remotely to add this. Previously I just thought of breakpoints/watchpoints as something only useful with a debug probe attached: https://lb9mg.no/2018/08/25/cortex-m-debugging-runtime-memory-corruption/

A further article suggests changing the memory map, so that the key registers can be saved in RAM and survive the reboot, and hence some form of telemetry could report them back: https://lb9mg.no/2018/08/18/preserving-debugging-breadcrumbs-across-reboots-in-cortex-m/

Freebies and Discounts

Greg Wagner won last month's Amazon Echo.

This month's giveaway is a 30 V 10 A lab power supply:

Free lab power supply

Enter via this link.

More on Encoders

Last issue's comments on encoders engendered a lot of fascinating responses from readers.

Yassen Gorbounov wrote (and gave me permission to post) an excellent paper about eliminating the errors which may arise during direction reversal of a shaft.

Chris Gates commented:

Paul Carpenter had several thoughts:

I loved your primer on encoders, but you missed my favorite encoder, in th is case linear, not rotary.

A bunch of stacked ball bearings in a tube, inducing and then sensing via two separate coils.  It just doesn't get much easier than this. I have been told that this approach can give amazing accuracy results too, in the angstrom range. Here is a commercial version:  http://www.newall.com/technology/


Encoders more thoughts some very good encoders for small diameter shafts, but programmable or even in some cases DIP switch selectable

48 to 4096 PPR

Are the CUI range with capacitive sensing and highish speed operation

See https://www.cuidevices.com/amt-modular-encoders

Available for roughly $20 to $60 each in singles. See

Very useful even as 'incremental' Quadrature ABZ (A, B quadrature and IDX pulse).

Important point to remember is when using IDX (Z) pulse that the index is on usually the FALLING EDGE and when in reverse use the RISING edge to clock.

I find using two counters is easier some of which are in many controllers these days for doing A/B quadrature decoding and simple external logic to fake A/B on separate index counter to get absolute position.

Often I prefer a small FPGA set to my required resolution for PPR and max revolutions (signed or unsigned), then use various flags for movement interrupts at desired update rate. Add comparators for thresholds in direction interrupts to simplify things on higher speeds.

Getting absolute positioning often requires external limit detections for power up initially and seek to reference position, with fast shut off for motors.

Rob Milne sent some code:

Over a decade ago I implemented a quadrature encoder driver in the RISC co-processor of a Freescale S12X MCU.  Both rising and falling edges of two input capture pins were processed in their respective interrupt handlers for maximum resolution.  The ISR servicing period was less than 400 nsec.  Noise filtering (jitter) was via delay register and small high-pass cap.  The logic is very simple and yet I have never seen it presented elsewhere:

         if pin_a_val == pin_b_val
         if pin_a_val == pin_b_val

It really is that simple and it just works.  Whether an increasing count is CW or CCW is arbitrary and easily inverted in logic.  With the above logic and the quadrature signal illustration in your newsletter, an increasing count corresponds to a CW rotation.

Of course today I would simply source a micro with a QE hardware feature - there seems to be a lot of them.

Attila Kalinka suggested an interesting chip:

I have been working with magnetic encoders for some time, and I came across a very nice piece of magnetic encoder chip, the MPS (MonolithicPower) MA3xx and 7xx family. I am working on motor control , but these little magnetic encoder chips are usable for other stuff too...

These are really small ( MA302 is a QFN16 3x3 ), and they tick all the boxes someone wants from an encoder for use along a microcontroller > 3.3v supply, SPI communication, quadrature encoder output with index pulse, and even a commutation-output for running motor controller directly from the encoder signals ( UVW - simulated Hall-sensor output).

Also they only require a very small PCB, with only a filter capacitor and the chip itself. The PCB then can be placed anywhere close to the shaft with a rotating ( typically a diametrically magnetized cylinder) magnet, in end-of-shaft or side-shaft mounting configuration. The magnet can be really small too.

Angle between the shaft and the sensor can be compensated in settings via SPI, to compensate for angle-error. 

The position where you want the chip to read zero is also adjustable trough SPI. 

Refresh rate is 1MHz, and the resolution is 12bits for the MA302 version. 

The downside is, they typically require a bit of setting up trough SPI, but once you set the correct register values, then it will store the values in internal non-volatile memory, so it is possible to set it up trough SPI once, and then use only the quadrature encoder outputs for detecting position.


I have no interest in promoting them, it's just a nice piece of hardware I like. 

Bob Paddock sent:

NASA came up with a way to avoid quadrature encoders. They placed a disk on the shaft that had a Morse-code like pattern; a short hole, or slot, followed by a longer slot.

The direction of rotation would be determined by if the short slot came before or after the long slot in the time sampling. There can be more than one pattern and can be the same or different depending on the application.

Honesty in Scheduling

The nuns at Holy Redeemer elementary school on Long Island taught us that lying is a sin. As we got older they added a certain amount of nuance to that, differentiating between venial and mortal sins, but the injunction to stick to the truth never wavered.

Adulthood showed that there were more than two shades to honesty: some things are indeed private, and sometimes kids need a carefully modulated version of the truth. But the nun's basic precept has, in my experience, been a pretty darn good guide to behavior: don't lie.

All of us know this. Most of us, except campaigning politicians, practice it with a good degree of rigor.

Except when it comes to creating engineering schedules. When I talk to engineers about creating schedules, someone always responds "yeah, but..."

Yeah, but the boss will cut our schedule in half.

Yeah, but the show drives the schedule, not any sort of engineering realities.

Yeah, but they'll agree to our timeline but will pile on more functionality throughout the project, all without changing the end-date.

So, many developers give up in disgust and agree to whatever the boss demands, knowing fatefully that it will slip, maybe by a lot. Or they double their real estimate to come out even when management whacks months off their projection.

I think that's a tremendous mistake. Don't lie. Work from the highest of ethical standards. Create an accurate, detailed, schedule and present that.

In my experience most engineering managers are ex-engineers. They love numbers. Yet too many of us present schedules devoid of detail. It's hard to argue against a tightly-reasoned schedule that's accompanied by detailed work breakdowns. Once, arguing this point in a class of 80 developers, all of whom were issuing "yeah, buts" at a machine-gun rate, their VP of engineering stood up and told them: "you never give me these sorts of details, so of course I don't believe you. Give me the numbers and I'll have to yield."

Of course it is true that plenty of bosses will not be swayed no matter what arguments we present. Many honest schedules will fall on deaf ears. But it seems to me that we have an obligation to be truthful regardless. We must collect actual data to compare against projected dates when the project is done, so both we, and the boss, can learn.

Yes, it is somewhat naive to expect management to suddenly have the scheduling scales fall from their eyes when presented with well-supported schedules. But by being dishonest we play their same game. And that's just plain wrong.

The IEEE Code of Ethics says, among other things "[We promise] to be honest and realistic in stating claims or estimates based on available data". I think that's a pretty good place to start.

Yet an awful lot of engineers disagree with me. What's your take?


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 intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.

Joke For The Week

These jokes are archived here.

Bob Paddock, cited in this Muse twice already, sent this:

The Preface to Murphy's Law:

We, the willing, Lead by the unknowing.
Are doing the impossible for the ungrateful…
We have done so much for so long…
With so little…
We are now qualified to do anything…
With nothing…

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.