Go here to sign up for The Embedded Muse.
The Embedded Muse Logo The Embedded Muse
Issue Number 377, July 1, 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 info@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email.

Contents
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.

Any idea how much code is in a modern car? Take a guess (in lines of code) and then scroll down to the Tools and Tips section of this newsletter for the answer.

Jack's latest blog: Millennials and Tools - A recent report claims tons of young folks don't own a screwdriver. Yikes!

Quotes and Thoughts

The future is uncertain - you can count on it. Anonymous

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.

How much code is there in a modern vehicle? According to the June issue of IEEE's Computing Edge magazine, in 2016 Ford announced their F-150 pickup has 150 million lines.

Freebies and Discounts

The folks at LitePlacer are offering a pick and place machine, in kit form, to Muse readers this month. This looks like a very cool robot:

This month's contest winner gets a LitePlacer pick and place machine

Enter via this link.

Multicore Scaling

We live in a golden age of computing. Need 10,000 servers to solve a problem? Amazon Web Services makes that easy and inexpensive. Short on CPU cycles in your embedded system? Multicore to the rescue.

Amdahl's Law purports to tell us how much speedup we can expect as a function of the number of processors used (n) and the fraction of a problem that is parallelizable (f):

Formula for Amdahl's Law

If f is 1 (everything can run in parallel) than the speedup is just the number of processors. Conversely, if the entire problem must run sequentially adding cores does nothing for you other than cost money and power.

(Gustafson's law shows that Amdahl's version is pessimistic for some classes of problems).

But Amdahl doesn't account for shared memory, a key characteristic of multicore systems. Typically each core hides behind its own small cache, but main memory is all on a single shared bus. If more than one core needs access to memory, all but one stalls. Sandia National Labs has shown this to be a problem even on programs with tremendous amounts of parallelism. For instance:

The failure of multicore

A new paper (Estimation of Maximum Speed-Up in Multicore-Based Mobile Devices, Yonghee Yun, Sodam Han, and Young Hwan Kim, IEEE Embedded Systems Letters, Vol. 11 No. 2, June 2019 - full disclosure: I'm on the publication's advisory board) estimates speedups attained in Arm big.LITTLE processors. These MCUs mix typically one or more fast cores with some smaller CPUs. For instance, NXP's SAC57D54H dishes up a big Cortex A5 with LITTLE M4 and M0+ cores.

The paper posits that speedups in big.LITTLE systems can be computed by:

A better formula for multicore speedup

nbig is the number of big cores, fk the parallelizable fraction of the code on each of those, Alpha is a constant that denotes the speed difference between the big and LITTLE cores, nLITTLE is the number of LITTLE cores, and fl is the parallelizable fraction of the code on those LITTLE guys.

I think there's a mistake in the formula: if fk and fi are both zero, meaning there's no parallelizable part of the code, it gives a speedup of infinity. Probably missing is a leading "1-" in the denominator.

There are some issues with the formula. The SAC57D54H I referenced has two different LITTLE cores so Alpha varies. Adding another denominator term for this difference would probably correct for that. And like Amdahl's Law there's no accounting for shared memory conflicts. The AHB busses used in most Arm multicore MCUs can allow for some amount of parallel accesses, and many of these devices have flash accelerators that are even more difficult to characterize, so it's likely that, at least with relatively few core counts, bus conflicts would have a small effect.

The authors show that for a variety of real-world problems the formula does match their experimental results remarkably well, so is a useful addition to our quiver of analysis tools.

Review: Siglent's New SDS5034X Oscilloscope

Siglent is a Chinese manufacturer of test equipment I've been following closely. They offer a wide range of instruments, and they, along with other Chinese vendors, have changed the oscilloscope business. Today you can get a high-quality scope for a fraction of what we paid a handful of years ago. They've recently released a new series of scopes.

Big screen. Big. 10.1". And did I mention it's big?

That's the first thing you notice when unpacking Siglent's new SDS5000X oscilloscopes which are their flagship products.

Siglent's SDS5000X

First, the basics:

  • Available in 350, 500 and 1 GHz models
  • 2 or 4 channels
  • 5 GSa/s acquisition rates (if more than one channel is enabled, this goes to 2.5 GSa/s)
  • 250 Mpts memory depth
  • 110,000 waveforms/second capture rate
  • 256-level intensity grading display (color temperature)
  • Segmented memory with 100,000 segments
  • Optional 16 digital channels, protocol decoders and more.

They sent me the SDS5034X, a 350 MHz four-channel model with the digital channels.

Do you like touchscreens? I'm mixed. Marybeth's computer has one, and every time she has a computer question my first response is to point to, and touch, an item on the screen. This always screws things up. My AWG has a little touchscreen that I mostly find annoying. The SDS5034X also has one, but the screen is so huge that the touch feature works brilliantly. Should you dislike this feature a "Touch" button disables it. There is one quirk: with the touch feature disabled, the only way to select various parameters in menus is with a mouse, so we mouseless scope operators will need to leave touch enabled.

Operating the scope feels a bit like using an iPad. For example, when entering the time one can move the window just by sliding your finger around the screen.

Siglent SDS5000X

Want to move a cursor? Sure, the knobs will do so, but it's easier to just touch the desired cursor and move it with your finger. It's easy and feels natural. The two-fingered pinch and zoom will adjust the vertical gain or timebase, though I feel I have more control with the knobs when changing these settings. A menu across the top of the screen gives touch access to pretty much all of the instrument's functionality.

The more I used the scope, the more I relied on the touchscreen.

An interesting feature is the "+" field in the lower left hand corner of the above picture. Press it to quickly enable another channel, be it analog, digital, a math function or a reference waveform.

I don't have the gear to measure the bandwidth of a scope rated at 350 MHz, but using my homemade SquarerUpper tool, the scope displayed a 700 ps risetime as 1.46 ns, quite good for a scope of this bandwidth.

All of the usual trigger modes are supported, plus a few nifty extras:

  • The slope trigger starts acquisition when the rise or fall time of a signal is <=, >=, or inside or outside a range of time values.
  • The window trigger starts when the signal enters or leaves a range of values. Oddly (and unlike all of the other settable features) the window's values are set only by moving the trigger level control; there's no dialog box to set them.
  • Dropout triggers the scope when a signal doesn't show up.
  • A zone trigger starts acquisition as a signal enters or leaves a box you draw on the screen using the pinch-squeeze movement, or set via a dialog box. That's pretty cool. I've seen this feature on expensive Tektronix scopes.

    Zone trigger format

  • There's an enticing "qualified" trigger, but I couldn't figure that one out. The manual is vague about this.

A few nice features:

  • Each vertical channel can have a 1 MΩ or 50 Ω input impedance. Cheap scopes don't have this. I use the 50 ohm setting a lot when dealing with high-speed signals.
  • Each channel has a deskew feature, which lets you set a different skew in 10 ps increments to compensate for, for example, different length probes. Think about this: 10 ps.
  • Modern scopes weigh so little that you have to hold them with one hand while pressing a probe into the BNC connector. I've screwed wood blocks into the bench behind my instruments so they don't shift position. The SDS5034X has non-skid rubber on the bottom so it stays in place when connecting a probe.
  • It will create and plot histograms of a region you define with the pinch-and-squeeze movement, or define with a dialog box. The diagram is unlabeled so I didn't find it useful. It will show the statistics in tabular format, which is pretty nice if you want data about a portion of a waveform.
  • The "save" feature is very fast compared to other scopes I've tested.

The unit does all of the usual measurements, and has a very nice histogram feature. In the following picture it's measuring the rise time and width of a pulse. On the bottom are two small histograms, one for each measurement. Dragging one with a finger up to the main part of the screen enlarges it. This feature changes the entire nature of an oscilloscope, which traditionally gave only snapshots of waveforms. Sure, digital scopes generally also give min, max, and standard deviation. But a histogram shows the distribution of values. That's pretty cool.

SDS5000X histogram feature

A lot of measurements are supported. I would probably never use many as I'd not remember that they existed. In most cases I'd eyeball the waveforms, perhaps using cursors. These more esoteric measurements are probably of use only when looking at their statistics.

Math operations are the usual (+, -, *, /, FFT, d/dt, ∫dt, √). You can create two of these and combine them to form g[f(x)].

There's a DVM that will measure various kinds of voltages, frequency and period. While sort of nice, this is a very common feature. But there's a twist: the scope can create a bar graph, a histogram and a trend line from that data:

SDS5000X DVM feature

This is an excellent feature that makes the scope a recording meter. Oh, and these graphs are windows that you can move around with your finger.

A 350 MHz 2-channel version of this scope goes for $2900, at 1 GHz with 4 channels it's $7300. The 16 digital channel option adds $800. The scope I tested goes for $4700. It's available here in the States from Saelig.

I like this scope. A lot. I tried hard to find things I didn't like but came up blank. Well, it's not as pretty as those from Keysight and Tektronix; the knobs are a bit cheap-looking. And the option arbitrary waveform generator (which I did not test) is not inside of the scope; it's an add-on instrument the scope drives over a USB port.

More on Test Points

In the last Muse readers had ideas about adding test points to a PCB. More ideas flowed in. Phil Pemberton wrote:

In response to Chris Brown's comment regarding short-circuiting power supply test points, I'd like to offer an idea.

I've been repairing a satellite data receiver and the power supply test points all have a 4k7 resistor between the test point and the rail.

The idea here is that the resistor limits current in a short; if you shorted two rails together, you'd have a combined total of almost 10k between them. That's unlikely to allow much of anything to happen.

It's one of those "I wish I'd thought of that" ideas - it doesn't affect the normal use of the test point (checking the rails) but does make the process safer, especially when there's a several-hundred-Watt power supply involved.

Ray Keefe suggested:

We operate on the following principal where possible:

Test point

Test point

  • it is also possible to add production test points with a simple jig to break them out to support debug during hardware and software qualification. Some very cost effective jig frameworks exist such as http://www.merifix.com/ or PCB mount clips such as these https://www.adafruit.com/product/2458

Test point

Asserts Redux

Tom McCormick responded to my thoughts about the assert() macro:

Regarding your note on assert, I have found that the style shown leads to different debug vs release build behavior. This makes for a really difficult class of bugs to chase. Specifically

void function(int arg){
  assert((arg>10) && (arg<20));

halts, as designed, during a debug build, but continues merrily along its way in a release build. In its place, I have tended to favor

void function(int arg){
  if ((arg<=10) || (arg>=20))
    {
    // Error – Invalid Parameter
    assert(0);
    // Do error handling

as this style of code doesn't implicitly assume that all bugs are caught during debugging and tries to gracefully deal with those that aren't. At the very least debug and release build behavior is identical; save for the halt.

Tom's comment raises some interesting issues. He's right, as the presence of the NDEBUG switch disables the assert() macro, so debug and release builds have different functionality. NASA's philosophy is test what you fly, fly what you test. In other words, don't do your testing, and then change the code! Yet there may be very good reasons for having assert() behave differently between build types.

What should assert() or any other bug-catching code do in a release build? In some systems there may be graceful recovery schemes, though it's hard to imagine one that applies to every possible bug assert() would detect. Tom's approach lets one tailor the system's response to a particular detected failure: the error handling code can vary from bug to bug. Or, one could write assert() to enter a safe mode (e.g., on a spacecraft the system goes to minimal functionality, orients the solar cells to the sun, and handles ground commands). In that case, assert() could be the same in both debug and release builds; in the former you set a breakpoint on entry to the safe mode code.

Back in the 70s we built a system with an error mode that could never happen, and, as a joke, we coded a message that said "Error: Call (301)-XXX-XXXX and give Harold hell." Except it did occur.

Harold was not happy.

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.

Funny job ad

Joke For The Week

Note: These jokes are archived here.

You might be an engineer if:

  • If you window shop at Radio Shack
  • If you know the direction the water swirls when you flush
  • If you own "Official Star Trek" anything
  • If you have ever taken the back off your TV just to see what's inside
  • If a team of you modified the antenna on the radio in your work area for better reception
  • If you thought the concoction ET used to phone home was stupid
  • If you ever burned down the gymnasium with your science fair project
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. 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 info@ganssle.com for more information.