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
• More Fast Trig
• The Joel Test
• On Professional Organizations
• This Week's Cool Product
• Jobs!
• Joke for the Week
• About The Embedded Muse

Jack's latest blog: Superintelligence

Everything is linear if plotted log-log with a fat magic marker. Mar's Law

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

Aleksandar Atanasovski sent the following. The tool does look pretty nice, and is reasonably priced:

This month's giveaway is a FRDM-KL25Z eval board based on the Cortex-M0+ microcontroller. The board is supported by mbed.org, which means you can do development without an IDE; the web site has an on-line compiler. The board appears as a disk drive on your PC. Compile the code with mbed's on-line tool, copy the resulting file to the board, and the code runs. I wouldn't build a real product with mbed, but it's great for playing around and building experimental code.

Enter via this link.

Harjit Singh sent another trig approximation:

static inline float NormalizeAngle(float x)
 {
   return x - 2.0f * PI * roundf(x / (2.0f * PI));
 }

//
// From: http://mooooo.ooo/chebyshev-sine-approximation
// The code will compute the sine of any IEEE single-precision float in the
// range of -PI to PI to within 4.58 Units of Least Precision (ULP)
//
static inline float mySinf(const float x)
  {
  const float coeffs[] = {
    -0.10132118f,           // x
     0.0066208798f,         // x^3
    -0.00017350505f,        // x^5
     0.0000025222919f,      // x^7
    -0.000000023317787f,    // x^9
     0.00000000013291342f   // x^11
   };
  const float pi_major = 3.1415927f;
  const float pi_minor = -0.00000008742278f;
  const float x2 = x*x;
  const float p11 = coeffs[5];
  const float p9  = p11*x2 + coeffs[4];
  const float p7  = p9*x2  + coeffs[3];
  const float p5  = p7*x2  + coeffs[2];
  const float p3  = p5*x2  + coeffs[1];
  const float p1  = p3*x2  + coeffs[0];
  return ((x - pi_major - pi_minor) * (x + pi_major + pi_minor) * p1 * x);
  }

static inline float myCosf(const float x)
  {
    const float rotatedX = NormalizeAngle(x + PI/2.0f);
    return(mySinf(rotatedX));
  }

This reminded me of an experiment I did a while ago with a 96 MHz Cortex M3 device and the mbed.org compiler. Using a lookup table of 256 entries, the MCU was able to generate a 10 KHz sine wave using 100% of the CPU cycles. The code looks like this:

int i;
for(;;)
{
  for(i = 0; i < 256; i++)Aout.write_u16(sine[i]);
}

That's 390 ns per table entry. I suspect most of that time is spent in mbed's Aout.write_u16() function.

Joel Spolsky has a long-running blog that has undergone several incarnations. I feel it is much less interesting than in years past when his focus was truly on software engineering. Today, the blog more often reflects his evolving interests in managing companies.

In a 20-year-old posting, Joel lists his 12 rules for evaluating a software team:

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

The posting contains Joel's rationale for each of these. A partial example about why using the best tools is important: "Top notch development teams don't torture their programmers. Even minor frustrations caused by using underpowered tools add up, making programmers grumpy and unhappy. And a grumpy programmer is an unproductive programmer."

It's hard to argue with that.

My take on Joel's rules is this:

• They form a quick heuristic for evaluating your team. What needs to change?
• Looking for a job? Good candidates ask as many questions of the interviewer as they get asked. Use these dozen questions to see if this is really a place you'd like to work.
  

A very long time ago, back when dinosaurs roamed the Earth, I was a student member of the IEEE. The cost was ridiculously low, the fellowship with other student members in our school's engineering lounge irresistible, and the lure of being part of the larger community of professional engineers ineffably compelling.

But the IEEE was a political mess. Over the objections of many of its members, IEEE officers, who were largely seen as academics and researchers with few ties to working engineers, campaigned vigorously for pro-immigration policies at a time with far too many native engineers were without a job. Gadfly Irwin Feerst (if you remember Irwin you're, well, old!) was a colorful figure who opposed these and many other policies. Though he was never one to be politically correct or even careful in his speech he came within a few hundred votes of becoming president at one point. Many claimed the top brass changed the rules to keep him at bay.

He took on the Institute's publications, saying: "The IT Transactions are indeed full of crap. Most of the papers are written by academics and foreigners. There is nothing in there for working engineers like me. In fact, I can't even tell if I've got it right side up or upside down."

Today, half a century later, I still recall his comments when I see papers with titles like the following in IEEE Transactions on Software Engineering:

• Software process representation and analysis for framework instantiation
• Using hammock graphs to structure programs
• The Effects of an ARMOR-based SIFT environment on the performance and dependability of user applications
• Cognitive Heuristics in Software Engineering: Applying and Extending Anchoring and Adjustment to Artifact Reuse
• BDD-based safety-analysis of concurrent software with pointer data structures using graph automorphism symmetry reduction

Feerst's battles with the IEEE ended a long time ago and are no longer important. In my opinion some of the publications, like Spectrum, are now packed with information engineers find interesting. IEEE Computer is also pretty good, though it rarely addresses embedded issues. It does have some thought-provoking articles from time to time about ethics and the like, an increasingly important problem with software in control of dangerous equipment, like automobiles.

The many Transactions publications are still for academics. Maybe age has brought me a less radical perspective, and I understand the need for some sort of balance between those of us who actually build products, and those seeking grants for conducting basic research. No doubt any professional organization has multiple and conflicting missions, satisfying no one entirely.

The IEEE, IEEE Computer Society, and the ACM, are professional organizations targeted at us. Membership is expensive. Unforgivably so, if you select options like access to digital libraries. The ACM's annual bill even has a bit of trickery designed to snare the unwary into giving extra donations to their foundations. But these groups offer value to us. It's unaffordable for most engineers to belong to more than a single professional organization, which is a real shame.

I remain conflicted about these groups, and sure wish the embedded world got more coverage. But they do offer value, if only in some of the resources offered via magazines and past publications stored on the web.

What do you think? Are these sorts of professional organizations worthwhile?

Though not cheap ($25k/year) zGlue has a technology called "ChipBuilder"^tm that greatly simplifies building custom chips. They have a library of some 1500 "chiplets" (IP designs of assets that go on an IC) which can be connected via an interposer. I think Xilinx pioneered the interposer concept, which is a silicon interconnect that provides the "wiring" needed between chips on a single substrate. The interposer eliminates the delays and power requirements needed when sending signals off-chip using conventional connections. zGlue claims that their technology shrinks IC design times to minutes and manufacturing to weeks.

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.

These jokes are archived here.

And 1.1.81 is officially BugFree(tm), so if you receive any bug-reports on it, you know they are just evil lies. -- Linus Torvalds

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.