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
• EU GDPR - General Data Protection Regulation
• Review of Sampling Theory and Analog-to-Digital Conversion
• Review of the ne Text Editor
• This Week's Cool Product
• Jobs!
• Joke for the Week
• Advertise with us
• About The Embedded Muse

Does your team focus on firmware quality? Did you know pursuing quality is the best way to reduce schedules?

Most firmware teams find and fix about 95% of their bugs before shipping. That leaves about three per thousand lines of code. It's not hard to drop that by an order of magnitude. How are your team's numbers?

Does your team consistently misestimate schedules? Does the team use the rules of thumb to determine the sanity of a schedule?

About half the systems I analyze have serious reentrancy problems, most that show up after shipping. Are these sorts of defects lurking in your code?

Most test strategies miss half of the defects. How do yours measure up?

Best-in-class teams use coding constructs that will automatically detect errors. Does your team routinely employ these?

If you're not happy with the team's results, if you want to learn better ways to get world-class code to market in less time, bring my one-day Better Firmware Faster class to your facility. It's fast paced, and a lot of fun. More than 5000 fellow engineers have attended to beef up their firmware skills - your team can, too.

Discounted Better Firmware Faster on-site seminars in Europe: I'll be at the Embedded World show in Nuremberg February 27 to March 1. Being already in Europe, I will be offering on-site versions of this class in Europe for a reduced price shortly before and after the show. If interested, drop me an email.

The Barr Group is running their annual survey of embedded systems designers. You'll be eligible to win one of two Fluke 117 Digital Multimeters or one of three $25 Amazon gift cards.

FPGAs, GPUs, neural networks and more - I chat with Matt and my son Graham on their Undersampled Radio show.

Yet another study debunks the merits of open office environments.

"These are the days of miracle and wonder" - Paul Simon, who was not writing about the electronics age, could have been.

Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past.

Luca Matteini bought a TotoLink A3-AC1200 wi-fi router. It has a surprising feature. From Luca:

This month's giveaway is the Siglent SDS1204X-E four-channel, 200 MHz digital oscilloscope which I reviewed last issue.

The contest will close at the end of January, 2018.

Enter via this link.

Paul Carpenter wrote in Muse 335 about the EU's new General Data Protection Regulations. I had not heard of these, but have been digging into them lately. I'm no lawyer, so take these comments with a grain of salt, but it appears to me that all companies selling products in the EU are subject to these rules. I'm sure many readers have strong feelings about the GDPR regulations - as do I - but the law is what it is.

The regulations take effect May 25, 2018. After that date violators are subject to fines as large as €20m or 4% of global turnover (whichever is higher). If your records aren't in order the fine is 2% of global turnover (for a paperwork snafu). Those are mighty inducement to comply.

From http://www.eugdpr.org/gdpr-faqs.html:

Who does the GDPR affect?

The GDPR not only applies to organisations located within the EU but it will also apply to organisations located outside of the EU if they offer goods or services to, or monitor the behaviour of, EU data subjects. It applies to all companies processing and holding the personal data of data subjects residing in the European Union, regardless of the company's location.

What constitutes personal data? Any information related to a natural person or 'Data Subject', that can be used to directly or indirectly identify the person. It can be anything from a name, a photo, an email address, bank details, posts on social networking websites, medical information, or a computer IP address. (Emphasis added)

Do data processors need 'explicit' or 'unambiguous' data subject consent - and what is the difference?

The conditions for consent have been strengthened, as companies will no longer be able to utilise long illegible terms and conditions full of legalese, as the request for consent must be given in an intelligible and easily accessible form, with the purpose for data processing attached to that consent - meaning it must be unambiguous. Consent must be clear and distinguishable from other matters and provided in an intelligible and easily accessible form, using clear and plain language. It must be as easy to withdraw consent as it is to give it. Explicit consent is required only for processing sensitive personal data - in this context, nothing short of "opt in" will suffice. However, for non-sensitive data, "unambiguous" consent will suffice.

From https://www.csoonline.com/article/3202771/data-protection/general-data-protection-regulation-gdpr-requirements-deadlines-and-facts.html: "68 percent of U.S.-based companies expect to spend $1 million to $10 million to meet GDPR requirements. Another 9 percent expect to spend more than $10 million."

One wonders what the effect of these rules will be on deeply-embedded products. For instance, there are USB-connected toothbrushes that collect brushing data. If that goes back to the mother ship, is it covered by the GDPR? Any IoT device surely knows its IP address - and that seems to be explicitly covered.

In many cases organizations must conduct a Privacy Impact Assessment (PIA, though I've always assumed that acronym referred to something else). More here: https://ico.org.uk/media/for-organisations/documents/1595/pia-code-of-practice.pdf

Perhaps most confounding is this, from the regulations themselves: (https://gdpr-info.eu/art-32-gdpr/ ) "Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk..."

What does this mean to the technical people who will be tasked with building a "secure" system?

Are you complying? Is the process onerous?

Remember convolution mathematics from your circuit theory class? I took that in about 1972, and at the time had no idea what was going on. The teacher was enthralled with the math and did little to explain how it applied to circuits.

Well, the new book Sampling Theory and Analog-to-Digital Conversion by Patrick Jungwirth is just the opposite. Yes, there's a lot of math, and that can be dense at times. But the author ties the formulas to real-world examples. Sometimes, a little too much. I thought the chapter that introduced linear systems veered off-course when the examples included pumping gas, Newton's Laws, and more. The rest of the book, though, sticks closely to electronics.

And it's all about sampling theory, as the title suggests. In the course of three of the book's eleven chapters you'll waltz through Fourier transforms, the Dirac delta function and its relatives (we called this the unit impulse when I was in college), and Shannon's Sampling Theorem.

The final chapter is all about software-defined radios - it's fascinating and comprehensive.

Each chapter ends with problems, so the book may be targeted to the classroom. It would make a very practical two-semester textbook. Extensive references are provided pointing the reader to more sources of information.

As mentioned, there is a lot of math. Patrick does start from first principles, so if your calculus is weak he'll get you up to speed. I did find some of it hard to follow. In some cases, formulas were presented in a way I consider backwards. For instance:

As an engineer I generally want to calculate V_out, not V_in.

But the book is for engineers; there's a whole chapter on reading ADC datasheets, and another on ADCs in general. The latter provides one of the best introductions to delta-sigma converters I've seen. Yet another covers testing and characterizing ADCs.

The book is lavishly illustrated, and the full-color diagrams are all extremely-well executed. An example follows, though in the book this fills an entire page, so looks a lot better than this reduced-resolution version:

• You're willing to plow through the math. If so, you'll get a lot out of it.


• You don't care so much about the math but want to learn about using ADCs.
  

It's available on Amazon in a $15 Kindle edition. Patrick provided me a printed version with a spiral binding. At 360 full-color pages it would be a big print job on a small printer, but I'd go for a hard copy. If you're like me, you'll be flipping pages a lot to understand the equations.

Alan Fay sent a review of the ne text editor:

An Introduction to ne - Nice editor

This is an old-school text editor that runs as a console application in the *nix shell. It replaces primitive text editors like ed, vi, and vim, with a "nice" editor. Its executable occupies 400 KiB on my Linux machine. It's available here.

WHAT I LIKE

By default, ne displays a c source file in colors:

• <util/delay.h> is cyan.
• Comments are green.
• Both opening & closing brackets are violet.

The remaining C source lines are shown in two different colors:

• Numeric constants are shown in a different shade of blue.
• C keywords are shown in black.
  

For example, in the line, PORTC = 0xFF; 0xFF is shown in blue, PORTC = is shown in black.

This can help if you just need to change one thing-- a bit pattern, or a comment-- to help you find it quickly. ne works for C syntax files with extensions '.c', '.h', 'c++', etc.

If you don't want the multi-color feature, simply disable it at startup:

$ne --no-syntax test.c

and all characters are shown in black. I do this whenever I write files in plain English text, as I did writing this review.

Other helpful features I like are

• Ability to open multiple files simultaneously in different windows; an F2 jumps to the next open window in the queue of open files; an F3 jumps to the previous window in the queue.
• Ability to display a reversed-color "menu" that pops up at the top of the Konsole viewport as soon as you press and release the Esc key or the Alt key.

It's like the old DOS text menus. You use the left/right arrow buttons to move left/right from one keyword to the next.

There are eight keywords. Each keyword has a list of verbs corresponding to actions you might want to take. You choose a keyword in the list by using the up/down arrow keys. For example, you might move the cursor (black rectangle) to the keyword Edit to pop up a submenu of Mark block, Cut, Copy, Paste, and so on, then push the down-arrow three times and hit Enter to paste the contents of the paste buffer to the cursor location. Of course, <Ctrl> V does the same thing.

Undo/Redo Functions:

• Pressing F5 undoes the last command.
• Pressing F6 re-does the last command.

It is possible to undo the last n commands sequentially. But I don't know the value of n. It is at least 2.

If you have just saved your file, and then press Undo, and then press Redo, and then quit, ne does not bother asking if you want to save the file.

And the most important thing -- it's free.

WHAT I DON"T LIKE

Type-setting programs, AKA word processors, automatically wrap lines of text to fit into a rectangular area given page left margin, page right margin, page top margin, and page bottom margin.

Text editors don't. You have to wrap long lines manually. Or use the GUI-based editor Kate. In Kate, word wrap is a verb. You simply activate the menu's "Apply word wrap". If you have already highlighted a section of text with the mouse cursor, only the highlighted lines are wrapped. OTOH, if no text is highlighted when you "Apply word wrap", all the text in the file is wrapped.

In ne word wrap is BOTH a noun AND a verb. If you're in word wrap *mode*, a w appears on the status bar. If it's off, there is no w on the status bar. To use word wrap as a *verb*, you must obviously first set the right margin to some value. Then type <Alt> p. Ne wraps the words in that paragraph, stopping at the end of the paragraph. So when I want to text lines throughout the entire file, I save my file and reopen it with Kate to do that.

WHAT ELSE I LIKE

At the bottom is a reversed-color status bar showing the name of the file, the line number, the column number, a percentage showing the cursor is at 95% of the way through the file, an i if insert mode is on (otherwise, if you don't want to insert text, press the <Insert> key if you want to toggle to overwrite mode so your keystrokes overwrite existing text -- the i disappears from the status bar. There are 18 other "status" or "mode" characters on the status bar that I haven't figured out yet.

No need to remember which "mode" -- insert or overwrite -- the editor is in, as with vi.

The main feature I like about ne -- and the reason I started using it--is its Macro feature. This is similar to the Macro feature in the old MULTI-SIM DOS code editor from the late 20th century. A Macro is just a sequence of keystrokes. You choose the keystrokes by typing them. Then assign that sequence of keystrokes to any key. I typically use a function key not already assigned to another function (for example, don't use F2 or F3 because of their navigation functions I explained above ). Then when you press that function button, the "playback macro" feature repeats the sequence of keystrokes you assigned to it.

This is very helpful if you, for example, copied and pasted a half-dozen lines from another source code file, linked the object code into executable code and ran that executable code on the target CPU to make sure the change did exactly what you expected it to do, and then go back to re-format the source code to make the pasted-in code match the original code.

In this case, for example, your sequence of keystrokes might be:

End (move cursor to end of this line)
Down-arrow (move cursor to next line)
Home (move cursor to column 1)
Del
Del
Del
Del
Del
End (move cursor to end of this line)
Down-arrow (move cursor to next line)

Here the 5 Del keystrokes move the source code 5 columns to the left. So to reindent a section of code, you simply place the cursor one line above the starting line, and press the assigned function key once for each line of code you want to move left. It's not foolproof. For example, if somebody pressed TAB to indent a line of code, the first Del deletes all the whitespace to the left of the first character, the second Del deletes the first character, the third Del deletes the second character, and so on. You have to watch what the Macro does as you press the key. I do think this is a good added feature-- finding hidden characters like the TAB.

You can also save Macros and reopen them in another session. I haven't done that yet.

It's nice (sorry for the pun) that you can edit text without using the mouse. It's also very nice that most of the standard keyboard's built- in navigation keys [Home], [End], [PageUp], [PageDown], <downarrow>, <uparrow>, <leftarrow>, <rightarrow> keys work as you expect.

NICE FEATURES

ne has other features such as changing the case of all the characters to the right of the cursor, stopping at the next word.

When you have edited your file, you press Ctrl S to save it, then Ctrl Q to end the program. If you press Ctrl Q without pressing Ctrl S first, and have made a change to the file, the status line changes to "This document is not saved; are you sure? n" and then your choice for next keystroke becomes y or n. Nice idiot-proof feature. There's also a character in the status line that changes when you modify the file.

When you press Ctrl S to save the file, the status line changes to "Saved" and stays that way until you press the next key.

ne has its quirks: For example the word-wrap function (Alt P) works only for the paragraph the cursor is in, stopping at the end of this paragraph, rather than continuing on to the end of the file. And you can't limit the word-wrap function AFAIK to operate on a highlighted section of text containing multiple paragraphs the way you can with GUI editors.

I have only mastered a subset of ne's functions. Just the ones I need to get the job done. If I've missed any of your favorite ne functions, send Jack a note.

There's a lot of press - and hype - about autonomous cars, but little about how these things actually work. I'm fascinated with the sensors, some of which are already being used in assisted driving electronics. Consider RADAR - once this was an expensive technology requiring magnetrons, waveguides, and other exotic RF technology. Today several vendors have RADAR on a single chip. TI's new AWR1443 is an example.

Block diagram of the AWR1433 RADAR-on-a-chip

This is a 161 ball part that includes three transmitters and four receivers! It operates from 76 to 81 GHz. Output power is just 12 dBm, not surprising for a monolithic device, but a whole lot lower than those megawatt air search RADARs we're familiar with.

The power supply max ripple specs are daunting, at tens of microvolts depending on frequency and voltage.

At $90 (1000 pieces) this is a pretty expensive part for automotive applications, but no doubt the 1 million piece price is much lower. But it's pretty cool that RADAR-on-a-chip is available, and it's even more amazing that this technology is being "driven" by the consumer automotive market.

The National Electronics Museum, which is outside of Baltimore, has an SCR-270, which was an early RADAR. This is the same model that detected the Japanese planes half an hour before the Pearl Harbor attack. Unlike the single-chip device described above, it ran at 106 MHz and weighed some 100,000 pounds. The single-chip RADAR needs 2W; the SCR-270 required 15KW. If you, like me, are interested in the history of electronics, I recommend The Invention That Changed the World, by Robert Buderi, which chronicles the development of RADAR. It's light on non-Anglo-American work, and I'd sure like more tech detail, like schematics, but enjoyable nonetheless.

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.

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 at www.ganssle.com/jokes.htm.

And God said "Go forth and multiply."

The snakes said "Oh Lord almighty, we cannot follow your command, for we are adders."

Thus spake the Lord "Go and fell those trees and build furniture out of them. For adders can multiply with the aid of log tables".

It occurred to me that readers who grew up in the era of widely-available calculators might not know what a log table is. In the bad old days we'd refer to our CRC Standard Mathematical Tables (I still have mine) which was basically a book full of hundreds of pages of tables of logarithms, trig, roots, etc., generally to five decimal places. To multiply we'd extract the logs of the two arguments, add them, and then use the tables to find the antilog. A slide rule basically operates the same way, though is only accurate to about 3 decimal places.

Advertise in The Embedded Muse! Over 27,000 embedded developers get this twice-monthly publication. .

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.