Go here to sign up for The Embedded Muse.
TEM Logo The Embedded Muse
 Issue Number 328, May 1, 2017
Copyright 2017 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.

Contents
Editor's Notes

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 for more details.
Quotes and Thoughts

"Code should be written to minimize the time it would take for someone else to understand it." - From The Art of Readable Code.
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.

One of my pet peeves is oscilloscope probes. We tend to give them little thought, which was fine in the olden days of slow signals. Now probes are more problematic.

When Keysight introduced a 30 GHz scope I called and asked "what about probes?" No problem, I was told, as new matching probes were available... for $28,000 each! Four of those and you could buy a house in some areas.

Consider the following picture (sweep is 5 ns/div). The scope is sensing the output of my "squarer-upper," a box I made that squares signals from my Siglent SDG-2042X arbitrary waveform generator. Most AWGs have a relatively slow rise time on pulses, and my squarer-upper reduces that to about 700 ps. The top trace is with an Agilent 500 MHz probe, a $200 unit. The bottom trace is from a Chinese 100 MHz probe that came with a scope; the cost is probably ten bucks or so.

Note the difference in rise time.

The March/April issue of Elektor Magazine (sorry, subscription required) has an article by Alfred Rosenkränzer about an active differential probe that caught my fancy. A circuit is provided but I sent off 129€ to get an assembled version. The specs are impressive: using differential inputs the input impedance is 5100 ohms, or 2550 when using a single-ending input. What blew me away was a claimed 1.9 GHz -3dB bandwidth, and a 300 ps rise time. An equivalent probe from the major vendors will be thousands of dollars.

It's powered from a USB port and is basically just some voltage regulators driving an ADA4927-1 differential op amp.

Does it live up to the hype? You betcha. The following (2 ns/div) shows, in red, how it compares to the Chinese and Agilent probes. Sure enough, the measured rise time matches the 700 ps of the squarer-upper, given that my scope is a 500 MHz unit:

(The time shift is due to the different lengths of probe wires. As I complained to my wife while doing this, the darned slowness of the speed of light has been haunting me for 40 years!)

One down side is the connection to the target system, which is just a two-pin header (shown by arrow in the next picture). Now, connecting probes to a high-speed target is always a headache, and I don't know of any fast probes that have the good old grabber connection we all know and love:

It has a +/- 12V range; with no input protection, be cautious using it.

Overall, I'm impressed.

Mr. Rosenkränzer doesn't have a web site, but you can contact him at alfred_rosenkraenzer@gmx.de. As mentioned, it's 129€ plus shipping.

Freebies and Discounts

Debugging an RTOS based system is hard. Even if your code is logically "correct", when you have multitasking and asynchronous events occurring you may get strange behavior and transient faults which are difficult to capture, never mind recreate. Percepio's Tracealyzer is like a logic analyzer for your RTOS-based software. It records and visualizes your software at RTOS level, to help you understand what's going on.

This month's contest giveaway is a full Professional Edition of Percepio Tracealyzer for the RTOS of your choice. One lucky Muse reader will win this at the end of May when the contest closes. Thanks to Percepio for donating the Tracealyzer for the contest.

Enter via this link.
On Capacitors

The latest issue of Circuit Cellar has an excellent article about capacitors by Robert Lacoste. This is a subscription-only publication so I can't link to it.

A couple of important facts:

Class 1 capacitors are those optimized for stability and accuracy. The NP0 is an example. These are made with dielectrics with low permittivity, so their capacitances are low.

Class 2 units offer much higher capacitances, but come at a price of poor performance over temperature and low accuracies. They're typically used for bulk applications like decoupling (more on this momentarily).

Class 2 capacitors suffer from aging. Over time their capacitance decreases according to the formula C=Cinitial(1 - log10(t) * A/100), where t is the time in hours and A is the aging rate. For a Y5V A is typically 7%; X7Rs are much better at around 2.5%. After 1000 hours (about a month) a Y5V will lose 20% of its rated value; after ten years it loses 35%.

A nice NP0 at 0.47 μF (about the biggest available) will run a couple of bucks or more in volume. An X7R, which is available in decent decoupling sizes, will be pennies, and a Y5V is even cheaper.

As I detail in Hardware and Firmware Issues in Using Ultra-Low Power MCUs you really can't use a Y5V in low-power systems as they leak quite a lot. Even X7Rs can be devastatingly leaky, so one must be really careful about selecting the most plebeian of components, the decoupling capacitor.

Then there's ESR - equivalent series resistance - which for a Y5V can be an order of magnitude worse than an X7R, particularly at low frequencies.

Finally, MLCC caps derate themselves, As the applied voltage goes up their capacitance goes down. Here's typical data for a 22 μF device. Note that the derating is highly dependent on package size:

Kemet has a nice tool to compare some of these specs here http://ksim.kemet.com/.

Uses for a 32-Bit ADC

Last issue I wrote about Linear Technology's new 32 bit ADC and wondered what kinds of applications would use such a thing. A couple of readers had interesting applications. For instance, Tim Flynn wrote:

At a prior job, we were looking at (did some testing) 32 bit A/Ds.

An application is EM communication. There is some debate on "EM", most expand this to Electro Magnetic. But I prefer the more accurate term Earth Mode. This is used for downhole tool communication. Most downhole tool communication is done with mud pulse telemetry. EM telemetry is modulating a voltage (& current) across a gap sub (electrically isolated, mechanically strong) near the drill bit. The surface system detects the voltage between the drill casing and a probe placed in the ground away from the rig. The detection system needs high dynamic range as the receiver can have 10s of volts on the inputs (& even higher). As the drilling gets deeper the received signal drops. Sometimes we were looking looking for signals in the nanovolt range, all the while the rig with its variable speed drives inject interference near the band of interest.

It was totally fascinating working on these systems. I like to use the terms magical.

Interesting that in their app note they point out the use of X7R caps. These have piezoelectric properties. NP0 caps are much preferred. Very challenging keeping the board quiet.

John Taylor has another application:

I am currently designing an in house product with this part:  A USB current monitor that does not require any gain in front of the ADC and uses a 0.1 ohm shunt to measure currents below 1uA and above 25amps with a single ADC channel.  The ADC has a fast sample rate that is fast enough to capture complex WiFi and Bluetooth activity and a low speed sample rate with enough oversampling to get to true nanoamp resolution for measuring sleep currents.  I am dispensing with the inclusion of USB powered internal power supplies from previous designs and using an isolated SPI interface to eliminate ground loops.

Several people noted they are used in geophysics. David Wyland wrote:

Nice article on 32-bit ADCs. The question was posed: what would you use them for?

One answer is: geological exploring for oil using geophones. Geophones are very sensitive low frequency microphones, planted in the ground. They are used in a sonar system consisting of a geological sound source and many geophones as sound receivers.

The sound source is an explosive charge that generates a sharp impulse into the ground. The geophones listen for the echoes from various shapes and discontinuities in the ground.

The output of a geophone is a big spike plus ringing that starts out at the volt level an decays to the nanovolt level. Echoes from nearby sources are large and early; echoes from far sources are small and later. The problem is to track the analog signal as it decays from volts to nanovolts.

A 32-bit ADC has a range of 10^9, matching this need very nicely.
On Shift Vs. Divide

In the last two issues readers have commented on precedence rules. Dave Hansen isn't keen on the responses that use a shift instead of a divide:

I must not have read the previous issue closely, because I see you are discussing the use of shift operators to perform efficient integer multiplication and division.  My view on this is much simpler.  Don't do that.  For many reasons.

Beyond the issue discussed in TEM 327 (division of negative values flooring rather than truncating, at least in many cases in a two's complement implementation), consider other limitations of the shift operator:

1) If the right (shift) operand is negative or greater than or equal to the width of the left (the value being shifted), the behavior is undefined.  For example, on one platform I worked on a few years ago, given an unsigned 32-bit int variable I'll call value, ((value >> 32) == value).  This was because the input to the barrel shifter on the CPU was 5 bits wide, and the compiler simply stuffed the lowest 5 bits of the shift into the register.

2) Shifting a nonzero bit left into the sign bit of a positive signed value or any shift left of a negative value also invokes undefined behavior (the standard says this much more formally, but that is the gist).

3) Shifting a negative signed value right has implementation-defined behavior.  So at least the compiler documentation has to tell you what it does, but it does not have to do what you expect.  For example, given a 16-bit int, ((-1) >> 1) _could_ result in 32767 rather than -1.

This kind of thing (using shift to multiply or divide) is exactly the kind of thing Tony Hoare was talking about when he said that premature optimization is the root of all evil.  In my experience, compilers are miles ahead of where they were 20 years ago.  Ten years ago, my compiler for a platform with a single-cycle divide would generate faster code for a=b/c then it would for the code using a test for sign and a shift.  A compiler for a different platform could detect (in many circumstances) when the denominator was a power of 2, and would generate the correct shifting code in those cases (and whenever the denominator was a constant).

In summary, I would argue that your code should say what you mean.  This shifting trick, like using XOR to swap values without a temporary, is useful insofar as it will enable you to understand what the original programmer of legacy code might have intended.  But new code should avoid these tricks and let the compiler figure out the quickest way to get things done.  Especially if you really need the code to generate the correct result.  And who doesn't?  Optimization is easy if you don't have to get the right answer.
This Week's Cool Product

A new commercial series of really fast scopes is out - Picoscope's 9300 family reaches 25 GHz (for $26k). This is a sampling scope, which means it's designed to display repetitive signals by taking a sweep, delaying a tiny bit, and sweeping again, to reconstruct the signal. The ADC is thus much slower than on a real-time scope (the most common type), which can, in a single sweep, suck in the entire waveform. If you need a real-time 63 GHz scope, Keysight has a nifty model for $451k. I sure want one of those!

Sampling scopes typically have better resolution than real-time scopes; the Picoscope has 16 bits of resolution compared to Keysight's real-time model (8 bits).

What got me interested, considering the review of a probe above, is that the company has a new set of probes for the unit. Passive, with only 0.4 pF of tip capacitance, at $1400 each they're pricey but much cheaper than offerings from the giant test equipment vendors. They're cute little things, but as is routine for these high-speed probes, not as simple to connect to a target system as a lower-speed "grabber" model.

Saelig distributes the Picoscope products in the USA.

Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors.
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 intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.
Joke For The Week

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

From Chris Jones:

"...a poem we think is about the lowly wahka. Maybe. Well, perhaps--we're really not sure what the poem actually is about. Here it goes:" 

      <>!*''# 
      ^@`$$- 
      !*'$_ 
      %*<>#4 
      &)../ 
      |{~~SYSTEM HALTED

Transliterated:

    Waka waka bang splat tick tick hash,

    Caret at back-tick dollar dollar dash,

    Bang splat tick dollar under-score,

    Percent splat waka waka number four,

    Ampersand right-paren dot dot slash,

    Vertical-bar curly-bracket tilde tilde CRASH.

Advertise With Us

Advertise in The Embedded Muse! Over 27,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.