You may redistribute this newsletter for non-commercial purposes. For commercial use contact firstname.lastname@example.org. To subscribe or unsubscribe go here or drop Jack an email.
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.
Jack's latest blog: On Retiring
|Quotes and Thoughts|
You'll always get the good news; it's how quickly your get the bad news that counts. Harvey Mackay
|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.
Bryce Deary likes Ceedling:
Joe Szedula had an idea about watchdogs:
Clyde Shappee wrote that if you download a trial of OrCAD you get on their email list, and occasionally they offer a deep discount on that CAD tool.
|Freebies and Discounts|
This month's giveaway is an Amazon Echo Show 5.
Enter via this link.
|A Low-Cost Performance Analyzer Upgrade|
Joe Szedula, who contributed his thoughts on watchdogs (above), also had an idea for a poor-person's performance analyzer, derived from my thoughts on the subject here.
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.
Jon Fuge suggested using a FET for protecting against a battery being installed backwards:
Having read your article on ultra-low power design (an area which interests me greatly); I have another addition which has worked well for me in the past… It uses a P-MOS MOSFET transistor which to the casual glance looks like it's fitted the wrong way around.
When the battery is the correct way around:
When the battery is reverse biased:
Beware not to exceed the Gate-Source voltage of Q1; if necessary, add a resistor and Zener protection to protect the G-S voltage from being exceeded.
Bing Huang sent a reference to a very interesting patent for a socket that allows an AA or AAA to be inserted in either direction, yet still power a system:
The better coin cell socket in your report on Ultra-Low Power Design reminded me of another battery holder design that works with battery inserted either ways. It is a purely mechanical design but is elegant. However, it is only for AA, AAA, etc type of batteries and not coin cell. It was developed by Microsoft. You can check out the design here:
There are other designs in the past, but this seems to be the simplest.
Frequent correspondent Clyde Shappee had some good data:
I read with interest the remarks about reverse battery protection.
I too have used the P-Channel MOSFET solution and it works well.
D1 is the diode I used for the body diode current measurement. In simulation as the voltage came up, about 8 mA of current flowed through it before the MOSFET turned on. V6, 0 V is for measuring the current through the diode. Likewise, V5 measures current to the load.
Today I simulated it, and with the battery in reverse, the current is quite reasonable, less than 150 pA.
The voltage drop across the MOSFET was just 2.3 millivolts. Because I was curious, I checked the current through the body diode and it was on the order of 60 pA.
This does seem like the ideal solution.
Clyde also mentioned an insidious sneak circuit he found in an MCU. If the batteries in a system were inserted backwards, some 4A were drawn through ESD protection diodes in the MCU's ADC input!
I've been getting a lot of inquiries about using shaft encoders lately. Here's an overview, which is probably not complete as there are so many products available today.
An encoder gives position information about a rotating mechanical shaft. An example is a volume control on a radio. In the old days we used potentiometers - variable resistors - to set the gain of the amplifier. Today it's more likely an encoder would translate the position of the shaft (the volume knob) into something an MCU can understand. With a pot there's a mechanical stop at the low and high ends of travel. If there's no stop, an encoder is likely used.
Encoders come in many flavors:
- Mechanical units have one or more wipers that ride on a circuit board. Those wipers could, for example, generate a binary code representing position.
- Optical versions beam light through a disk which is scribed. For instance, the disk could have 1000 scribes, so the device will output 1000 pulses per revolution (PPR).
- Magnetic encoders use Hall-effect sensors.
Their outputs are equally diverse:
- Incremental encoders just send a pulse stream. Each pulse denotes some amount of angular rotation.
- Binary and Gray code versions send absolute position information.
- Quadrature encoders provide two signals each 90 degrees out of phase with each other. While an incremental encoder can't tell you which way the shaft is rotating, quadrature versions do.
- Fancy units: Many encoders will provide position information via I2C, SPI, or other formats.
- The rest: Voltage, commutation and many other versions abound.
Incremental and quadrature encoders have one innate flaw: You can't translate the outputs to an absolute position. So some of these also sport an "index" pulse, which is a separate signal that is asserted once per revolution. Typically, in manufacturing a technician rotates the encoder to generate the index pulse at some pre-determined position. From that it's possible to figure absolute position (e.g., with an incremental encoder that generates 1000 PPR, if 500 pulses have been detected after the index signal, then the shaft is 180 degrees from the calibrated index position).
Pulses per revolution vary from just a few to 65,536. (That puppy will set you back over $1000, and outputs 16 bits of Gray code).
The cheapest encoders are a half-buck or so in singles and are generally quadrature versions. These offer a dozen or two PPR and are often found as controls, like for the volume control on a radio. Others are more capable; Digikey lists one QE with 6000 PPR for only (!) $3700.
What does a quadrature encoder's output look like? Here's an example:
Instead of going into some depth about using a quadrature encoder, check out this excellent reference which includes sample code.
Some MCUs have peripherals that handle quadrature encoders directly. For instance, Microchip offers their Quadrature Encoder Interface, which looks like:
The digital filters remove glitches from mechanical encoders. Microchip has a good reference about this peripheral here.
It is possible to have custom encoders made. In one case we had data coming in spaced at sin2 of the shaft angle. One could use a very high-resolution encoder and interpolate, but the interrupt rate would be astronomical. Instead, we had an encoder made which gave us pulses spaced at sin2 intervals.
Aside - On Gray Code
Gray code is a code developed to eliminate the glitching one can expect from mechanical contacts. With binary many bits change at a time and wiping contacts and create erroneous apparent binary codes. With Gray, only a single bit changes at each count. Here's and example from the Wikipedia page:
Another aside - Servicing Encoder Interrupts
Back in the early 1970s we designed an instrument which used an optical encoder that provided 1000 pulses/revolution. It was connected to a spinning set of optical interference filters. As one tilts an interference filter, the filter's passband changes, so by measuring the shaft position we could infer the frequency of light passed.
As I recall We had a new sample every 100 us. The processor was Intel's first 8-bitter, an 8008 operating at a blistering 0.8 MHz. With 5 to 11 T-states per instruction only a few could execute between encoder pulses. How to handle that data?
The 8008's interrupt structure was odd, to say the least. It's response to an interrupt was a nearly-normal fetch cycle, except that an interrupt acknowledge signal was generated. External hardware had to supply an instruction on the bus during this INTA. Normally one would jam a one-byte call to invoke one of eight handlers, but that was far too slow for this application. Instead, we had the processor execute a halt instruction located at the beginning of the handler after processing each interrupt. The hardware jammed a NOP, the fastest instruction, in response to an interrupt. That simply resumed execution at the beginning of the interrupt service routine.
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.
These jokes are archived here.
Machines don't save you from doing more labor, they just save your employers from paying for more labor.
The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at email@example.com.
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 firstname.lastname@example.org for more information.