You may redistribute this newsletter for noncommercial purposes. For commercial use contact jack@ganssle.com.

• Editor's Notes
• Quotes and Thoughts
• Tools and Tips
• Freebies and Discounts
• Review of the Phoenix Project
• Debouncing Quadrature Data
• CAD and Privacy
• Jobs!
• Joke for the Week
• Advertise with us
• About The Embedded Muse

Give your team the tools they need to operate at a measurably world-class level, producing code with far fewer bugs in less time. This is what my one-day Better Firmware Faster seminar is all about. It's fast-paced, fun, and uniquely covers the issues faced by embedded developers. Information here shows how your team can benefit by having this seminar presented at your facility.

Follow @jack_ganssle I'm now on Twitter.

Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. - Alan Kay

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

Do you read Circuit Cellar Ink? It's one of the few print magazines left in this field. I enjoy it, but do find some of the articles to be too hobbyist-oriented for my interests. However, December's issue is a real winner. Four articles were compelling:

• Comparing FPGA Technologies - Altera, Xilinx, Lattice or Microsemi - what are the differences?
• An Introduction to Verilog - The basics of writing "code" for an FPGA
• Op Amps and Capacitive Loads - A great analysis of the issues of driving caps.
• The Internet of Things (Part 4) - Sure, everyone has a great IoT idea. Do you know what it will cost to get certified to use the cellular network? Hint: a lot!

John Kaasgaard suggested:

Where do you get the fasteners, metal, plastic, and all of the non-silicon things that are needed to build products? My favorite resource for mechanical items is McMaster-Carr. They provide fasteners, materials, and all sorts of things. Prices for most items are great, though, strangely, tools are expensive. I live within 150 miles of one of their distribution centers so inexpensive UPS ground shipments arrive the next day. Their new phone/tablet app is great. Highly recommended.

Paul Bennett was kind enough to write this review of The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford ( Published by IT Revolution Press, ISBN 978-0-9882625-0-8).

This is an instructional text in novel format, telling the tale of Bill, an IT Manager who suddenly is elevated to oversee the roll-out of a project that already has major problems, is over budget and very late onto an infrastructure that is creaking at the seams and fragile to changes.
More importantly he has to accomplish this heroic feat within 90 days as the company's continued existence as a single entity is in jeopardy.

To most in IT and other technology related businesses this is probably sounding like an absolutely horrific nightmare scenario, but it seems that such scenarios do happen and companies do fail because of it.

Bill is lucky in that he has an odd-ball mentor who helps him to gain insight and understanding of the total problem space and guides him to see the IT Operations he is responsible for more like a manufacturing company with real physical products and similar issues of constraints, bottlenecks and quality management problems that need to be solved.

How does this apply to the Embedded World? Topics like identifying all the process steps, mapping out transfers between steps and how you efficiently make the transfers all uni-directional (minimising re-work, re-design or re-coding). It also highlights how you really need to understand relational dynamics between parts of the system (both in product and development process).

The story style is every bit as gripping as those cliff-hanger soap operas you have on TV where you keep turning to the next chapter to discover what happens next. However, it introduces the whole ethos behind running successful DevOps as an integral part of the whole business team. Doing anything less really does seem like suicide...

David Paulsen had some thoughts about the debouncing code in Muse 292:

I read your last "The Embedded Muse", and just couldn't resist replying to one of the articles.  In the essay by John Youngquist, he gave a great example to decoding a quadrature encoder.  However, he missed an important point.  A common problem with encoders is the illegal transition that occurs due to coupling between the two quadrature signals.  Gray code is supposed to go in the order:

        00 ==> 01 ==> 11 ==> 10

The problem is that lots of encoders out there have cables that have a bit of capacitance between the signals. Also, many of the drivers are open collector, so they pull strongly low, but not as strongly high.  That means that for example, when you go from state "11" to state "10", you often get a very short "00" state in between, due to the coupling.  If you happen to read it at the glitch, you sample the encoders as "11" ==> "00" ==> "10".  Note that the "00" state was very short, but if you happen to read it, it counts as one of your discrete samples.

John's code works great if there is never one of these illegal transitions.  I have heard some argue that the glitch is so short that it will "almost never" happen.  That is fine if you are only trying to decode a rotary knob for user control where a rare glitch can be tolerated.  However, with a motor encoder, such an occurrence will cause the position to be updated incorrectly.  I have seen this occur in a control board sold by a major motor manufacturer, using their motors and their encoders.  In that case, their position either lost or gained counts in a fashion that made it unusable for a position control on the medical device we were designing.

Anyway, here is another algorithm for decoding a quadrature signal.  This one is actually smaller and faster than the one previously sent.  It also uses fewer registers (doesn't need the B register).  The most important point, however, is that it does not suffer from the illegal transition problem.  If the encoder signals are ever read with an illegal transition, they are simply ignored, no increments or decrements occur for illegal transitions.
I normally don't write 8051 code any more, but I put this together to demonstrate the algorithm.  I used the same input that John used, so the compare could be done easily.

         ;@ Quadrature encoder decoder

 
 
 

         ;@  R0 = position counter
         ;@  P1.6 and P1.7 are the quadrature encoder connections
       QUAD_DECODE:
  A-0000:  e590               MOV   A,P1         ;@ Read  signals in bits 7,6
  A-0002:  23                 RL    A            ;@ Shift over to  bits 1,0
  A-0003:  23                 RL    A
  A-0004:  30e102             JNB   ACC.1,qd1    ;@ Convert to  binary
  A-0007:  6401               XRL   A,#1
       qd1:
  A-0009:  28                 ADD    A,R0        ;@ Diff  (neg) from count
  A-000a:  30e006             JNB   ACC.0,qd_done;@ If bit 0 == 0, done
  A-000d:  20e102             JB    ACC.1,qd_inc ;@ Check sign
  A-0010:  18                 DEC    R0          ;@ Decrement count
  A-0011:  22                 RET
       qd_inc:
  A-0012:  08                 INC    R0          ;@ Increment count
       qd_done:
  A-0013:  22                 RET 

The "ADD" instruction takes a little explaining.  Basically, I would have preferred to use a "SUB" instruction here, but the 8051 has only a "SUBB", so that would require that we clear the carry bit first, taking one more cycle to complete.  That is easier to understand, but slower.  This entire procedure takes about 12 cycles to complete (10 cycles if we move the input bits to bits 1,0).  If the counting is backwards from what you want, simply swap the "DEC R0" and "INC R0" instructions.  If you have multiple encoders to decode, then just remove the first 3 instructions, and pass the quadrature bits in ACC.1 and ACC.0, and the original position in R0 (or R0,R1,R2,R3 if you wanted a 32-bit position).  You should also initialize the position at power up to the match the state of the encoder, or you could possibly start in the illegal state, and get one count the wrong direction with the first move.  Normally this is not a problem with motors, since they need homing anyway.

The same algorithm could be written in C, and be much easier to understand, as follows, complete with a test program:

/*
    * Test program for quadrature decode
    * 7-oct-2015   David Paulsen   Wrote original
*/
    #include <stdio.h> 
/*
    * Quadrature decoder
    * Parameters:
    *      position    : Current  position
    *       enc        : New A,B quadrature bits in bit 0,1 (Gray code)
    * Return value:
    *      Updated position value
*/
       int quadDecode( int pos, int enc )
       {
       if ((enc & 2) != 0)
       {
           enc ^= 1;           /* Convert  Gray code to binary */
       }
       enc -= pos;             /* Get diff, only low 2 bits matter */
       if ((enc & 1) != 0)
       {
           if ((enc & 2) != 0)
           {
               pos--;
           }
           else
           {
               pos++;
           }
       }
       return pos;
       } 

int main( void )
       {
       int p1, p2, enc; 
       for(  p1=0; p1<4; p1++ )
       {
           for( enc=0; enc<4; enc++ )
           {
               p2 =  quadDecode( p1, enc );
                printf("Pos: %2d ==> %2d  enc=%d  quadDecode  change=%s\n",
                        p1, p2, enc,
                        p1<p2 ? "inc" :
                        p1>p2 ? "dec" :
                        "hold"
                     );
           }
       }
       return 0;
       } 

Lucca Matteini had some thoughts on CAD tools to share:

I was pondering today about EDA tools and their file formats, since they've become richer in these last years, adding so much information... too much of it, actually!

A few days ago, a colleague sent me the documentation from a potential customer, who already had some development hardware/firmware designed for them, though incomplete. Since this final customer is only marginally experienced in electronics, they need some insights and analysis by professionals, and they miss many details in their prototype design.

Then I started analyzing it "forensically", to understand how it was developed.

To be short, I started discovering from evidences a sequel of consultants (unknown to me), that progressively added something to the final results. In some cases names were in schematics, or in firmware sources, so I started browsing connections between the companies and individuals involved, from their web sites and the Linkedin network.

The puzzle started evolving like reading a detectives story, and that was even fun.

The most relevant part that I considered was the Altium/Protel database file, of the schematic/PCB project. Since I'm not using Altium/Protel for some time now, and I don't have it here, my curiosity lead me to open the database file and investigate on its binary content: a database, when not compressed/encrypted, contains lots of text strings.

So I discovered not only where the original designer put the files on his hard disk, but it confirmed me his identity, the dates on which the design roughly started and was updated, and all the parts used or considered for the project; I even found parts and libraries that he used probably for other designs. All of this in a matter of few minutes.

I already noted a similar behavior on OrCAD design files, that I currently use: even without opening the binary files, it's evident how symbols have associated their source library, that can be bound to an hard disk location, potentially revealing names of projects and companies that you could prefer to maintain private.

Is it strange, to desire not to share them with anyone?

The ones I'm working with today can see the names of the companies and the projects, I worked on ten years ago. After all some of them could be under some NDA or other limiting agreement.

Don't these large EDA companies consider it in their development? Now, this makes me disappointed and surprised!

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

From Vic Plichota:
[from a T-shirt worn by Matt Noy, an EE at CERN's LHC]

There are two types of people in this world:

1 - those who can extrapolate from incomplete data,

Advertise in The Embedded Muse! Over 23,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.