Go here to sign up for The Embedded Muse.
The Embedded Muse Logo The Embedded Muse
Issue Number 399, June 1, 2020
Copyright 2020 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.

Contents
Editor's Notes

HCC Embedded

Housekeeping notes:

I've started routing email through Google to swallow most of the avalanche of spam. But an analysis of several thousand of these spams shows Google does occasionally eat a legit email. If you send me an email and don't hear back in a couple of days, please try again with a different subject line.

A number of people have been inquiring about our privacy policy. It's simple:

We hold these truths to be self-evident, that all people have an absolute right to privacy.

We collect two kinds of data from you:

  • If you subscribe to The Embedded Muse newsletter, we log your email address so we can deliver it each month.
  • If you email us, our reply to you is stored in our sent-mail folders.

We never reveal your information to anyone, despite promises of wealth, fame, recovery of lost youth and desperately-needed full-body makeovers.

The only email you'll get from us is The Embedded Muse, unless you correspond with us, in which case we'll respond.

Unlike nearly every other newsletter, we don't track links.

We don't use cookies.

Our website does not use any sort of analytics.

Jack's latest blog: On Checklists

Quotes and Thoughts

As long as machines were the largest item in the budget, the programming profession could get away with its clumsy techniques. E. Dijkstra

Tools and Tips

SEGGER Embedded Studio 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.

Freebies and Discounts

This month's giveaway is one of Zeroplus's new Logic Cube Pro logic analyzers. This is their top-of-the-line unit with 32 channels, 256 Msa/channel memory, and 2 GHz sample rate. It lists for $3500.

Logic Cube Pro giveaway

Enter via this link.

Review of the Zeroplus Logic Cube Pro

Zeroplus is a Taiwan-based vendor of logic analyzers. I've reviewed several of their products in the past and am very impressed with the units. They recently sent me one of their new Logic Cube Pro analyzers (which confusingly also goes by the name Lap C Pro), which is this month's giveaway.

The prices range from $900 for a unit with 64 Msa of memory per channel, 16 channels and a 1 GHz sample rate, to $3500 for 256 Msa/channel, 32 channels and 2 GHz sample rate. For this review they sent the high-end unit.

First the specs, from one of their presentations:

Specs of the Logic Cubs Pro

"Sample Rate (LTR)" refers to storing the data in real time on the PC's disk, giving essentially unlimited buffer space.

Sample rates depend on the number of channels enabled. 16 channel units max out at 1 GHz with 8 channels; 32 channel models can sample all at rates to 500 MHz, dropping to 16 channels at 1 GHz and 8 at 2 GHz.

The UI is complete and pretty:

Zeroplus Logic Cube Pro main screen

In general, logic analyzers (LAs) are sort of boring. They all do the same thing: suck in and display digital signals. It's hard to differentiate products in this market as so many are so similar. Price is one selling point, one that Zeroplus is not addressing with the Logic Cube Pro. One might wonder when you can get a pretty decent analyzer for a few hundred bucks how one justifies spending thousands for a Zeroplus unit. Your average home experimenter won't be able to make a spousal case for one of these.

The Logic Cube Pro will appeal to professionals who needs fast acquisitions with all of the bells and whistles. For this unit really does hit every feature one might want in a high-end unit. Instead of a detailed review I'll highlight the cool stuff you won't get with a typical $500 unit.

The user interface is intuitive, fast, and pretty. Windows can float so can be dragged anywhere. The mouse scroll wheel moves the acquired data left and right in time (I'd rather it zoomed, but that's a personal preference).

Trace data uploads very fast, even for big buffers.

Need to decode a protocol like I2C? The UI includes over 100 decoders. All of the standard protocols are included plus plenty I'd never heard of. GP-IB is there; when was the last time you saw a GP-IB interface?

Trigger thresholds can be set in 10 mV increments from -6.0 to +6.0 volts. Working with logic that's using dynamic voltage scaling, generally around the 1V level, or near- or sub-threshold logic, this could be a critical feature. I don't know if anyone is using ECL anymore, but those negative levels could be important there, as well as for looking at differential signaling.

Even better, there's a programmable Schmitt trigger feature where you can set both voltage levels. It's subtle features like this that make the unit stand out from the low-cost competition.

For me, the Logic Cube Pro's killer feature is triggering. A big buffer is nice, but for those really hard to reproduce problems you want to start or stop acquisition when a specific event occurs. The usual modes are supported, with a UI to die for. For example, this is a trigger set on a delay time. The arrow points to the count, which can be any number up to 216.

Logic Cube trigger1

Or, trigger on a bus transition through some state:

Logic Cube trigger thru a bus state

The unit allows multi-level triggering. Set up a condition to be matched, and then possibly an action (like "wait 1.64 ms"), and then another condition. Iterate forever. The unit triggers after all of these conditions are satisfied. I got tired after setting up 64 conditions, every one of which would have to be satisified before a trigger occurs. I don't know what the limit is, though thought I saw, somewhere, that it maxes out at 256. That is an incredibly-nuanced trigger! In the following picture I configured these with individual channels, but you can use entire busses as well.

Logic Cube trigger on pattern

Need to trigger on one of those 100+ protocols communicating some specific data? The Pro has you covered. Here's the setup for an I2C packet. It's fun to set up; as you add parameters (like requiring an ACK) the colorful picture then shows that parameter:

Logic Cube protocol trigger

The LA provides both trigger input and output signals. I always look for this feature for coordinating testing with more than one piece of test equipment.

Some of the cheaper logic analyzers have one or two analog channels, generally with a greatly limited (e.g., 5 MHz) bandwidth. The Pro doesn't sample analog, but there's a mechanism to connect your DSO to the unit to show analog waveforms in the Zeroplus UI, synchronized with the DSO in time. That's sort of the best of both worlds: a real oscilloscope with all of those features integrated into the LA's UI. Philosophically it mirrors the notion of moving the LA display from a dedicated unit to the PC. Oh, and the software knows all about a number of scopes, with the ability to set up their parameters inside the Zeroplus UI. Oddly, there is support for Agilent but not Keysight (I assume the Agilent setting will control Keysight scopes), and there's none for Siglent, which is a pretty popular brand. You will be covered for some models from Tek, Rigol, GWInstek, Owon, Pico and even BK.

A noise filter removes short crud on any channel; the user specifies the duration of a spike that should be ignored. That's another nice feature not found in low-cost LAs that pros will like.

Working with an encoder or ADC? A feature will take the channels connected to that device and display an analog waveform representing the digital values from the peripheral.

A pattern generator is four-bits wide and runs up to 5 Mb/s. It will output any of the common logic voltages between 1.5 and 5. It accepts Excel files that define the pattern, though the manual is silent about this feature.

A few nits:

  • I could set it to a mode where the capture takes a long time, but hitting cancel to stop the capture does not immediately stop. You may have to wait many seconds depending on the acquisition rate and memory depth.
  • The help file is pretty useless. The .PDF user manual is better but really needs more explanations. A very intriguing "waveform trigger" looks like a highly-customizable feature that I couldn't figure out. It appears tantalizing cool.
  • The UI is Windows only.
  • There is a fan in the thing. It's not particularly loud, but is noticeable. It seemed about the same volume as the fan in a decent scope.

The Logic Cube Pro is a high-end logic analyzer that would satisfy nearly any need. The Pro is recommended for pros. It's available on Amazon.

State Machines v. RTOSes

Responding to last issue's take on RTOSes, Daniel McInnes wrote:

I have a comment about hierarchical state machines, or state charts. I have used these in production code, via Qt's SCXML https://doc.qt.io/qt-5/qtscxml-overview.html . I really like the tool, but it's only really applicable if you are already using the Qt framework, and can live with the licensing (dual commercial / GPL). I haven't been able to find a suitable standalone state chart tool with more permissive licensing. 'Yakindu' looks good, but I think it demands you use Eclipse, which is not for me. Boost state charts are almost right, but you don't get the diagrams, which I find really useful. Perhaps your readers know of a good tool?

Also, I really like Ian Horrock's book on developing user interfaces with state charts https://www.amazon.com/Constructing-User-Interface-Statecharts-Horrocks/dp/0201342782/ref=sr_1_1?dchild=1&keywords=statecharts&qid=1589845006&s=books&sr=1-1 .

Jack Crenshaw sent this:

Quite frankly, I've never been a big fan of the RTOS.  It usually seems to me that they try to offer too many options.  I mean, you can use a semaphore system, or you can use all interrupt-driven event handlers, or you can use purely timed tasks, perhaps counted down to get sub-frequencies.  But you don't need to use _ALL_ of them!

Most of the word I did for Honeywell had to do with their nav systems. The gyros used to run at 500Hz, so that frequency was run by the RTC, and all the lower frequencies got counted down from there.  Then, of course, there's always a background task that runs asynchronously, to take care of housekeeping tasks, including the watchdog timer.

Back in 1995, I worked for a company that made patient monitors for hospitals.  Their existing product used eight Z80's, and naturally the code was written by an absolute genius of a programmer, but one who eschewed all comments.  Naturally, he was no longer with the company, so it fell to me to psychoanalyze his code (and his thought processes.

My job was to figure out what he'd done, and create the code for a single 80386 (later Pentium).  To make matters more interesting, we had promised that the functionality would be unchanged, so we wouldn't have to go back through FDA validation.

I tried many, many approaches to documenting the existing code; mostly I used DFD's (Data Flow Diagrams), made "real time" with little lightning bolts to imply interrupts.

But the most effective documentation turned out to be STDs (State Transition Diagrams). I'm not 100% certain, but I think my approach might have been a little unique.

The thing is, all the various parts were a little too complicated for one single state machine, so I had to nest them -- one STD per function.  As far as I know, most nested SM's return some kind of flag indicating the results of the function; then that flag would be used to alter the state in the parent machine.

My twist was to recognize that nobody knows what the reaction to a different state function should be, better than that child state machine itself.  So what I did was just let the child set the state for the parent SM.

It's a little kludgy, I admit, because the child has to know what states are used in the parent (caller) routine.  It's not as much information hiding as I'd like, but the only thing required was that the declaration of the states had to be defined in the parent, and passed to the child.

So anyhow,  when control was returned to the parent, its new state had already been set.

The neatest part was, the whole system needed almost no debugging at all.  Either it worked, or it didn't, and when it didn't, the problem was VERY obvious and easy to repair.

On Expectations

Studies suggest that typical code gets shipped with 0.5 to 1% defect rate. That is, the code in a 100KLOC product probably has 500 to 1000 bugs. Yes, some organizations do very much better, but the norm is just not acceptable.

There are many reasons for poor quality. One is management expectations. Software engineering is viewed as an intrinsically chaotic process with unpredictable and non-repeatable results. The boss and sales department are so exhausted by the development process that when the product finally appears they're happy to ship, no matter what problems still lurk.

Software engineering is indeed hard. But it doesn't have to be either chaotic or unpredictable. If management doesn't hold engineers to high standards, if they don't routinely expect products to be done correctly, odds are they won't.

Engineers should be expected to deliver high quality, well-tested, maintainable code.

The corollary, of course, is that engineers should expect adequate resources from management, be they personal, tools, requirements and time.

Users of the SPARK language, for instance, have reported incredibly low bug rates, in some cases zero on delivery of a product. That's due to several reasons including the use of a safe language (it's a subset of Ada) with tools that do formal proof checks against annotations provide in the comments. Those tools are important, but success in SPARK comes from an expectation that developers will use them correctly all of the time. Shortcuts aren't allowed. There are no exceptions. C developers can benefit from the same philosophy.

On of the more interesting popular press articles, which every developer should read, is They Write the Right Stuff, a piece written a quarter-century ago that resonates with me to this day. It's about the team that created and maintained the Space Shuttle software, which was probably the best code ever written. The developers expect error-free code, and when a problem slips through they attack, not the bug, but the development process that was flawed enough to permit the bug.

Yet in too many outfits bugs are considered normal.

Perfection is impossible in any human endeavor, so errors will occur. But this is the only industry on the planet that can get away with shipping products full of known defects. Someday no one will smoke and all of the asbestos will be buried. Who do you think the lawyers will go after?

Failure of the Week

661787 hours is 75 years. Consider this: 75 years ago was 1945 and the only real computers were the ENIAC and Colossus. Neither could copy GB of files! ENIAC originally had a "store" of 20 ten-digit accumulators, or something like 0.0000001 GB of memory.

This Week's Cool Product

Nvidia's new Ampere architecture is a chip with 54 billion transistors built on 7 nm geometry. It's targeted at big AI applications (as opposed to working at the edge as I described in Muse 397), where it - or the board it's on, the info is unclear - consumes 400 W. Specs are sparse, but I imagine it runs at around one volt, which means that little one or two square cm of silicon needs 400 amps, an awful lot of current.

The part uses multiple floating point formats, including the new TF32:

An INT4 format is supported as well. It's hard to think of an application other than machine learning that could profit from 4-bit integers.

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

These jokes are archived here.

And don't tell me there isn't one bit of difference between null and space, because that's exactly how much difference there is. -- Larry Wall

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.