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
• Quotes and Thoughts
• Tools and Tips
• Freebies and Discounts
• Multicore Scaling
• Review: Siglent's New SDS5034X Oscilloscope
• More on Test Points
• Asserts Redux
• Jobs!
• Joke for the Week
• About The Embedded Muse

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!

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

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.

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:

Enter via this link.

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):

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:

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:

n_big is the number of big cores, f_k the parallelizable fraction of the code on each of those, is a constant that denotes the speed difference between the big and LITTLE cores, n_LITTLE is the number of LITTLE cores, and f_l is the parallelizable fraction of the code on those LITTLE guys.

I think there's a mistake in the formula: if f_k and f_i 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 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.

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.

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.

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.

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

  

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

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:

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.

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

Ray Keefe suggested:

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

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

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

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.

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.

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

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.