Tweet Follow @jack_ganssle
Go here to sign up for The Embedded Muse.
TEM Logo The Embedded Muse
Issue Number 310, August 1, 2016
Copyright 2016 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 info@ganssle.com.

Contents
Editor's Notes

Better Firmware Faster classes in Denmark and Minneapolis

I'm holding public versions of this seminar in two cities in Denmark - Roskilde (near Copenhagen) and Aarhus October 24 and 26. More details here. The last time I did public versions of this class in Denmark (in 2008) the rooms were full, so sign up early! (There's a discount for early registrants).

I'm also holding a public version of the class in partnership with Microchip Technology in Minneapolis October 17. More info is here. (There's a discount for early registrants).

Or, I can present the seminar to your team at your facility.

I'm now on Twitter.

Quotes and Thoughts

Norm Augustine, retired chairman and CEO of Lockheed Martin, wrote a book called Augustine's Laws that documents observations he made as a government contractor. One of those was that by the year 2054 the entire US defense budget would buy just one aircraft, due to their spiraling costs. In the May 9-22, 2016 issue of Aviation Week and Space Technology (often called Aviation Leak and Secret Technology due to their outing of many programs) he wrote this revealing statement:

"Another law from the 1960s used historical data, fearlessly extrapolated, to show than an ever-increasing fraction of an aircraft's weight was being devoured by electronics and in 2015 would leave no room for pilots. Thus, we have today's dilemma wherein pilots must remain in Nevada while their aircraft burn holes in the sky all around the planet. The Wright Brother surely are doing barrel rolls in their graves.

"Of course, some observers have questioned how, as these laws seem to imply, it would be possible to endlessly add cost to an aircraft when nothing more can be added to an aircraft's weight, not even a pilot. To do this would require a colorless, odorless, weightless substance whose cost - like entropy - would continue to increase forever. Fortunately, the industry's engineers were up to the task: the elusive substance is software."

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.

TI has made their Analog Engineer's Pocket Reference available for free (registration required). It's an excellent book. Couple that with their also-free Handbook of Operation Amplifier Applications and you'll be on the way to a great library of analog resources.

Siglent has a new series of professional-grade and I reviewed the SDS 2304X here.

Jeremy Overesch sent a link to about a 6502 microprocessor made from 4237 discrete transistors.

Freebies and Discounts

This month's giveaway is a 200 KHz oscilloscope in kit form, without the 9 V power supply. Again - you have to solder this together. This is a real entry-level unit but looks like fun.

The design is pretty clever. For instance, to generate a -5V supply the MCU's PWM toggles transistors that switch the positive supply through an LC circuit and diode; that is then regulated with a 79L05. The scope's trigger level is set by holding a push button down; that causes a DAC on the MCU to drive an op amp, which then (it appears) initiates an interrupt to tell the processor to start collecting data.

Enter via this link.

Resume Optimization

The NY Times ran a short but important article about resumes. It doesn't cover nearly enough, but makes a few key points I'll list here:

  • Write the resume around the job description. The description tells you what the company is looking for, so it makes sense to tailor the resume to meet that need (while being honest).
  • Many companies use algorithms that search resumes for keywords and skills. The article makes the important point that these are designed more to filter out candidates than to find the diamond in the rough.
  • Because of these algorithms, have a section titled "Skills" which should be near the beginning. After all, the employer wants more than anything to know if you have the skills they are looking for.
  • Quoting from the article: "I can do everything, I'm a jack-of-all-trades, I'm a Swiss Army knife," Mr. Siegel offers as examples. "Nobody is hiring a Swiss Army knife. They're looking for a specific skill set."

When confronted with a pile of resumes, a boss's first pass is not to find the best candidate. The goal is to shrink the pool by as much as possible as quickly as possible. Only then will that individual turn to weighing the merits of promising candidates. Does the candidate have the skills we need? If not, the resume goes to the recycle bin. Anything weird will get immediately rejected, like those I've seen on pink paper, or the one with a picture of the applicant's dog. Stress a skills match above everything.

Possibly the worst resume I have ever read was so priceless I still have it, 30 years on. It has a section on the candidate's health, with the following: "Mental Health has been strained from 1983 to the present. I have been under the care of a Psychiatrist from the time of my separation up until the present time. At this point I am in the process of changing my divorce agreement from joint custody to full custody going to the mother. I think I will be sucessful [sic] and by the time this position opens I will be on my way to a full healthy recovery to start a new life and a step up in my profession".

I'm sure this person was in high demand.

More about resumes here.

Active/Idle Meter

Andrew Kollosche sent this:

Over past years while developing software on micro-controllers I have used a LED as to indicate activity. Usually by toggling the LED on and off in various functions or in an interrupt routine, if the LED stops blinking, well you have a problem.

Back in 2014 Jack Ganssle's free online newsletter, "The Embedded Muse" demonstrated the use of an analogue Volt-Ohm Meter (VOM) connected to a output port pin as software debugging tool for micro-controllers. Called an Idle Meter it is mostly used under an RTOS system by toggling a port pin in the Idle procedure, thus measuring system idle time. But what about all those programmers who because of the micro-controllers they use, won't support an RTOS software and are stuck with the good old Superloop?

As a Superloop does not have any idle time, how about reversing the idea and use the VOM as an Active Meter instead. In this case we flip the port pin high at the start of the Superloop and set it low at the end. The meter will now show the activity of the loop and if any function within the loop suddenly increase it's processing time a corresponding increase will be shown on the active meter. It is now a simple matter of moving the starting point of the active meter one function call at a time down through the loop until the offending function is found.

Having said all of the above, if you wish the VOM can still act as a Idle Meter by simply reversing the Port High and Low points. It was found via experimentation a small delay was required between 1 and 5ms, between toggling the Port pin. See in the simulator code below for Microchip PIC16FXXX. A 10K potentiometer is used as a voltage divider and the VOM scale set to 2.5v full scale deflection (fsd). To calibrate set potentiometer to half way point and connect to +5 volts and adjust for fsd. Once fsd is set, connect to PIC port output pin.

       + 5volts or port output pin
       |
       /
10k    \ <------- wiper to + VOM probe set on DC 2.5volt range.
Pot    /
       \
       /
       |---------  - VOM probe.
       Gnd
 
/*
*               Main program and Superloop starts here!
*
*      A Superloop is a program structure comprised of an infinite
*      loop, with all the tasks of the system contained within the loop.
*
*      Enter – void.
*      Exit  - never.
*
*/
void main(void)
{
    byte x,tickcnt;                     //declare index counter, tick counter.
 
    //Simulate execution time table
    const byte Sim_tbl[8] = {15,5,40,255,28,2,63,8};
 
    Initial_PIC();                      //setup all ports & variables.
    RA3 = 0;                            //power LED on.
    x = 0;                              //index zero.
    do                                  //SuperLoop.
    {                                   //Start of main program loop.
        tickcnt = Sim_tbl[x];           //get simulated application time.
        while(tickcnt)                  //zero?
        {
            tickcnt—;                   //dec app time.
            DelayMs(1);                 //wait 1ms.
        }
 
/* Now decide if its going to be and Idle or Active Meter,
with VOM connected to the RA4 pin of PIC16FXXX microchip */
/*
        //idle meter.
        RA4 = 1;                        //idle ON.
        DelayMs(3);                     //wait 3ms.
        RA4 = 0;                        //idle Off.
*/
        //active meter.
        RA4 = 0;                        //active Off
        DelayMs(3);                     //pause 3ms.
        RA4 = 1;                        //active ON.
    }
    while(1);                           //do forever!
}
Managing Stack Space

Erich Styger had a suggestion about managing stack usage:


I'm using the GNU/--gcc --fstack-usage option, see https://mcuoneclipse.com/2015/08/21/gnu-static-stack-usage-analysis/. Add a simple perl script, and I get a nice stack usage report like this:

Additionally, there is the nice --Wstack-usage option to warn about excessive stack usage (described in above article too).

Do check out Erich's link which includes much more detail about this.

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

Note: These jokes are archived at www.ganssle.com/jokes.htm.

A young programmer and his project manager board a train headed through the mountains on its way to Wichita. They can find no place to sit except for two seats right across the aisle from a young woman and her grandmother. After a while, it is obvious that the young woman and the young programmer are interested in each other, because they are giving each other looks. Soon the train passes into a tunnel and it is pitch black. There is a sound of a kiss followed by the sound of a slap.

When the train emerges from the tunnel, the four sit there without saying a word. The grandmother is thinking to herself, "It was very brash for that young man to kiss my granddaughter, but I'm glad she slapped him."

The project manager is sitting there thinking, "I didn't know the young programmer was brave enough to kiss the girl, but I sure wish she hadn't missed him when she slapped me!"

The young woman was sitting and thinking, "I'm glad the guy kissed me, but I wish my grandmother had not slapped him!"

The young programmer sat there with a satisfied smile on his face. He thought to himself, "Life is good. How often does a guy have the chance to kiss a beautiful girl and slap his project manager all at the same time!"

Advertise With Us

Advertise in The Embedded Muse! Over 27,000 embedded developers get this twice-monthly publication. For more information email us at info@ganssle.com.

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. 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 info@ganssle.com for more information.