You may redistribute this newsletter for non-commercial purposes. For commercial use contact email@example.com.
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 http://www.ganssle.com/onsite.htm for more details.
I'm now on Twitter.
|Quotes and Thoughts|
More than 80 percent of software bugs will be found in less than 20 percent of software modules. Pareto Principle as modified by Capers Jones.
|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.
Does anyone remember the Sony-Tek oscilloscopes from the 1970s? Tektronix realized that their big-buck products priced many smaller outfits out of the market so partnered with Sony to create a line of cheaper alternatives. They were OK, but we found them to be somewhat unreliable with a poor UI. Engineering soon managed to dump them on the production people and continued using the Tek 7000-series units, which were a dream to use but could be insanely pricey. Today the big players still offer expensive and very capable units, but Chinese competitors (e.g., Rigol, Siglent, Owon, etc.) now offer very good units for astonishingly-low prices. A few years ago Tek countered with their attractively-priced TBS1000. Keysight has a new line of low-cost scopes that start at $448 for a 50 MHz unit. If anyone is using these low-cost Tek or Keysight units, let me know what you think of them; I'll share the feedback with Muse readers.
|Freebies and Discounts|
The mantra of Ada programmers is "if you can make the darn thing compile at all, it will work," because the compiler just doesn't allow for most silly mistakes. An Ada variant, SPARK, is even more demanding. SPARK's philosophy is "correctness by construction." Bug rates in programs written in the language are unbelievably low.
This month's contest giveaway is a copy of the book Building High Integrity Applications With SPARK, by John McCormick and Peter Chapin. One lucky Muse reader will win this at the end of April when the contest closes.
Enter via this link.
Various vendors offer to make products available for free or at a discounted price for Muse readers. I've thought a lot about this; the Muse is not going to be a promotional vehicle for products. Yet, my intention has always been to deliver value to readers, be it in content or freebies that could be useful. Here's one such offer:
Best Circuits' "LCDTerm" is an LCD and controller on a board that is very easy to control over an SPI or UART link. Instead of a painful LCD I/O interface, it is completely driven by simple printfs to the serial port. They will send a sample kit to "qualified corporate customers" - I suspect that means to those planning to use it in a product. More info here.
|Precedence Rules in C|
Do you know the precedence rules for C? Most of us don't. Precedence experiments reported in "Developer Beliefs About Binary Operator Precedence"(Derek M. Jones) are startling. Most developers can't correctly answer questions about which operators have a higher precedence than others, and lots of experience doesn't improve things much, as evidenced by precedence tests given to engineers:
My belief is that the right thing to do is to use parenthesis instead of relying on feeble memory to insure expressions will execute properly. However, Muse reader N Abid Ali Khan has kindly written up some rules to make it easier to remember which operator will dominate. Here's his thoughts:
Rhyme of C Operators, by N Abid Ali Khan
Thanks to Dennis Ritchie and his team the first C compiler was released way back in 1972. The C language has found its own place in developing embedded system software, real-time operating system policy implementations and device drivers ranging from simple 8-bit microcontrollers to complex 32-bit FPGA targets. This article takes you through the basics of C-supported operators and describes an easy way to remember the priority of operators while evaluating an expression.
If you can remember the slogan 'MA-S-G-E-A-R-O-Ca-Co-?-=' (left to right), any C expression can be calculated without actually typing the expression in a C compiler. Many books provide a standard table discussing the priority of operators and their associativity. But, when an expression is given, it is a little cumbersome to work it out by recalling the table all the time. This article also serves as an easy way to keep the order of priority on the fingertips.
Figure 2: C statement with arithmetic operators (multiplicative and additive)
Let us take the example of priority of execution of C expression shown in Fig. 2. This expression evaluation is simple; since only arithmetic operators are involved, where multiplicative operators (multiplication, division and modulo division) have high priority, while additive operators (addition and subtraction) have lower priority. If the expression is found to have operators of the same level of priority, evaluation starts from left to right (associativity). Step-by-step evaluation is also mentioned by specifying the high-priority operator with an underline.
Figure 3: Statement with multiplicative, additive, AND, XOR and OR operators
Now, let us see how priority of the expression changes if we introduce bit-wise operators (bit-wise AND - &, bit-wise EXOR - ^ and bit-wise OR - |) in combination with arithmetic operators. For our use case, let us consider the expression shown in Fig. 3. Notice that, initially, multiplicative operators from left to right are evaluated. Then come additive operators; finally, when we land with only bit-wise operators, order of priority is first bit-wise AND, followed by bit-wise EXOR with bit-wise OR at the end. The expression, which has to be evaluated, is underlined for each step.
Figure 4: With multiplicative, additive, AND, OR, XOR and shift operators
In the above expression, we missed the shift-left (<<) and shift-right (>>) operators. In fact, these are at the third position in the rhyme. Consider another expression given in Fig. 4, where multiplicative, additive and all bit-wise operators exist, including shift operators. This expression looks crispy, and no coder opts for it. However, if you are asked to work on driver development with RAM memory organisation whose CPU registers are not bit-addressable, you may land up with expression(s) like this. As advised, you have to follow the order of the slogan, considering the priority with multiplicative -> additive -> shift-left or shift-right -> bit-wise AND -> bit-wise EXOR -> bitwise OR to evaluate the expression for arriving at the correct answer.
The shift-left and shift-right operators have significant improvements in terms of power because if you are shifting integer N by k times towards the left, you are multiplying N with 2k. On the other hand, if you are shifting N by k bits towards the right, you are dividing the number by 2k
That means, for an integer N,
N<<k = N x 2k // Efficient multiplication N>>k = N / 2k // Efficient division
Figure 5: With multiplicative, additive, relational, bit-wise - &, |, ^ and shift operators
Let us add relational operators of the two operands and try to get the value of the expression shown in Fig. 5 by following the priority order of the operator rhyme. Note that, within the available relational operators, there exist two priority levels among equality operators (low) and greater or less than operators (high). Next, let us observe the behaviour of compound conditional AND (&&) and compound conditional OR (||) statements, too. Among these, logical AND (&&) has higher priority compared to logical OR (||). In the expression given in Fig. 6, again, by following the operator's priority rhyme, the step-by-step value is obtained.
The assignment operator (=) is the last priority in the rhyme. Note that, other than the regular assignment operator, a combination of assignment with arithmetic operators or with bit-wise operators too may fall under this observation. For example, consider the expression in Fig. 7. After evaluating the complete expression on the left-hand side, 63 is the result. Next, we have an assignment operator concatenated with an addition operator; this addition will be performed in the end, yielding the final value as 69.
Finally, consider the expression shown in Fig. 8, where most operators are deliberately used to understand how to evaluate to a final value, by following the order of priority as per the rhyme. Although the expressions given in Figs 5, 6 and 7 are vague in nature—which a developer rarely adopts, for the other expressions, especially expressions that can be a combination of multiplicative, additive, bit-wise and assignment operators in a single expression, precedence of operators will come in force. As per the operator's rhyme from left to right, value can be calculated.
Figure 8: C expression with arithmetic, bit-wise, relational, conditional and assignment operators
|Certification Securite de Premier Niveau|
If you want to sell a device that connects to the Internet to the French government, your product must comply with the Certification Securite de Premier Niveau (CSPN) rules.
It's hard to find much about CSPN in English but a new article in Embedded Computing Design is a must read for developers planning to export gear around the world. Under CSPN a third party organization, licensed by the French government, does the security evaluation of a product. It appears only three such groups currently exist for embedded devices.
The good news is that the evaluation must be completed in 8 weeks, and will require only about one person-month of time from the vendor.
Security is a huge concern. While CSPN is probably a step in the right direction, I'm concerned that the process apparently treats a product as a black box. The referenced article suggests no internal information needs to be supplied to the evaluators. Bitter experience has taught us that apparently secure products still contain vulnerabilities. The Common Criteria, another certification standard, requires that the NSA does a full analysis of the source code for the highest (EAL7) evaluation level. The costs are staggering.
|This Week's Cool Product|
I'm very interested in ultra-low power designs (and have written an exhaustive report about them) as this is the future of the IoT, and some serious (and interesting) engineering is needed. Maxim has a new series of boost converters (MAX17220 - MAX17225) that will take a Vin of as little as 0.95V to generate as much as 5V. The tradeoff is reduced output current, but many modern MCUs don't need much:
The device has an enable input used to shut the part down; the datasheet claims in this mode as little as 50 nA is required. That's a bit disingenuous as this is based on a "typical" spec. I think it's poor design to use anything other than the rated max, which is 100 nA - still a decent number.
The datasheet is frank and correct about design rules, such as the careful selection of output capacitors due to their ESR and being careful in selecting one as the capacitance of MLCCs is degraded by applied voltage. It includes a number of sample circuits.
Constrained by form factor? The device can run with an 0603 inductor.
It's not listed on Mouser's or Digi-key's web sites yet but other sources suggest pricing is/will-be $1.23 in 1000-unit lots.
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.
|Joke For The Week|
Note: These jokes are archived at www.ganssle.com/jokes.htm.
Vol Taire sent a better form of the Dr. Suess joke in the last Muse.
|Advertise With Us|
Advertise in The Embedded Muse! Over 27,000 embedded developers get this twice-monthly publication. For more information email us at firstname.lastname@example.org.
|About The Embedded Muse|
The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at email@example.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 firstname.lastname@example.org for more information.