You may redistribute this newsletter for noncommercial purposes. For commercial use contact email@example.com.
Many of us think there's some sort of more or less inverse linear relationship between the amount of software reused and the cost to create firmware. Turns out, that isn't true. NASA has shown that once you start fiddling with about a quarter or less of the code reuse's benefits start to melt away.That's not to knock reuse; I feel that it's probably our only hope of salvation as programs soar in size. But it does say a lot about how we need to go about reuse to get the benefits it promises.
This, and a whole lot more, is part of my Better Firmware Faster seminar. It gives your team the tools they need to operate at a measurably world-class level, producing code with far fewer bugs in less time. It's fast-paced, fun, and uniquely covers the issues faced by embedded developers. Learn how your team can benefit by having this seminar presented at your facility.
India update: I will be doing a three day version of this class, open to the public, in Bangalore, India July 15-17. Contact Santosh Iyer for more information.
40% of embedded people don't use a version control system. I wonder how many of them have a disciplined back-up strategy? Here's one approach for small teams.
|Quotes and Thoughts|
"I am and forever will be a white socks, pocket-protector, nerdy engineer." -
|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.
Howard Speegle on his Rigol oscilloscope:
Dukai Zoltan wrote:
One reader wondered where readers go for hand tools. He was looking for a crimper but Digi-Key, normally my go-to source, wants $400. What is your favorite resource for tools?
As mentioned in the last Muse, I'm giving a bench scope, a GW Instek GDS-1052-U, to a lucky Muse subscriber. This is a dual channel 50 MHz unit, and offers great performance for the $300 price.
The giveaway will close at the end of May, 2015.
|Tools and STM32 MCUs|
Richard Tomkins had some extensive thoughts about development environments:
|Readers' Thoughts on the Forums|
Last issue I wrote about the technical forums. That struck a chord; many readers responded and here are some of their thoughts.
John Burgoon commented:
Luca Matteini had a personal story:
I'd like to share a recent (and very short) experience I had, with a question on Stack Overflow.
I was looking for Ethernet/wireless routers with a certain feature (usually not well documented), so I registered as a user on Stack Overflow, and started a question as in "How to find a router with X feature?", briefly explaining in the text what I needed, and how I was more or less happy with the routers I tested so far. I kept everything in few lines, being as dry as I could.
In a few minutes I received a flaming reply, from an user with +10k comments active, telling (as offensively as he could) that it wasn't a forum to endorse manufacturers, and that routers with feature X were just a pile of junk.
I answered politely that it wasn't my intention to be off-topic, and anyway I thanked him for his point of view.
The very next day I was informed by an automated message from an administrator of the forum that my post was put "on hold", since the content wasn't appropriate, and the question wasn't proper, since it was better that I asked in a form like "How to find XXX?". My jaw dropped.
I immediately unregistered my user, adding as a comment how I found useless such a community.
Unfortunately these communities have a tendency to make a few sociopaths feel as elected genius and masters. Maybe some of them really have good skills, but unluckily, staying in a community places them in front of different opinions, smart and silly ones, and they simply can't stand it.
I remember a similar case many years ago, where chatting on the IRC I came in contact with one of the developers of the KDE Unix/Linux environment. By then, the application suite was still in beta release, so I installed it on Linux and found some issues in configuring the sources. When I naively informed this guy that there were some things to fix in the autoconf/automake scripts, he burst out saying he'd never seen before anyone of my nationality understanding a thing about autoconf or automake, period. I'm not sure it was racism or what, but I saw clearly there was no space for contribution, and I quit. After that episode I reconsidered seriously what is the real meaning of "open source".
Benjamen Meyer wrote:
It really depends on the forum. The Qt Centre has proven vary useful in the past; but don't expect an answer right away. Any user can post/answer; and they do have a point system too. I did try to participate recently in StackOverflow; however, their rating system prevented me from even answer questions (as a new user I didn't have enough points; nor did I have enough questions to get enough points to answer someone else's question to which I had an answer). I've also used Google Groups, and had similar experiences depending on the group - some get answers quickly, others never. So it's really hit-or-miss. What I don't like about Forums is that there is no real way to remind the community that the question hasn't been answered without flooding the boards with the same question.
So, I still prefer the tried-and-true mailing lists.
Now, in both cases finding whether the question you're trying to ask has already been answered - and more importantly finding the answer in such cases - is extremely hard. I think this is in part because computers don't understand what people are thinking, and people tend to rarely ask the same question the same exact way twice. So you have to figure out how someone else may have asked the question - or a close enough approximation - that the computer can match your question with the existing question, and hopefully that question will have an associated answer.
And of course there are the cultural problems - namely that some groups treat new comers as idiots that should have read everything on the Internet before asking their question to the group, while others (the minority unfortunately) respond politely and point the people in the right direction. Still, sometimes the groups just don't want to answer the question at all for some reason.
It would be nice if all the technology we've developed help overcome these hurdles, but in many cases it makes a bigger hurdle than we had before. While opening the door to the world, we've slowly bricked it closed. May be it's just that it's people's way of handling the overflow of information being pushed at them. Or may be it's something else. May be one day computers AI will be smart enough to help us all out.
Ian Stedman had suggestions:
I have in some cases both benefited and benefited others on technical forums. AVRfreaks has been most useful to me. Once someone who knew me from there had a desperate question why his firmware lookups didn't work, and I could (and did) easily supply the answer. At other times I've been mystified by strange behavior and learned from the experts there.
Sometimes you get nonsense, sometimes you get help. Here's something I just cooked up, a recipe for how to get worthwhile help
1) Do your own research; If it's dealt with in a tutorial, or is a homework problem, you will get laughed at.
2) Be completely respectful; even to the trolls. Sometimes even obnoxious people have useful things to say.
3) Thank them; If they help you, let them know that they helped. If they didn't, thank them for their time.
4) Pay it forward; If you do wind up finding out something odd, an unusual behavior or a documentation problem, post it.
That's roughly what I do. There will always be a**hats, and that's part and parcel of dealing with humanity. Ignore them as best you can, and enjoy the better part of homo sapiens without descending to the level of those who'd rather fling dung as a chimpanzee.
I have gotten help (although not from Stack Overflow- - they may be victims of their own success) from technical fora (forums) from everything from microprocessors to fixing my toilet.
Generally speaking, human beings like to share, like to be helpful, and like to feel useful helping others. There are always exceptions, and it is a somewhat gritty duty of those of us who'd rather be helpful to override, overrule, and generally leave to their own fate those who'd prefer to, if I may, watch the whole world burn. The human race isn't, overall, like that - But a very vocal minority is.
That minority is the problem, but they'll always be with us, either as capitalists or politicians or merely a**hats. We need to deal with them.
Chris Bruner's take:
In response to your reader on Stack Overflow, his opinions and my responses, respectively:
* Too often pointless flame wars reduce the signal-to-noise ratio to near zero.
* In many cases the same questions get asked over and over.
* Or, the questions are unanswerable ("what's the best MCU to use?").
* Many of the issues discussed are pointless, philosophical ("is a mobile phone an embedded system?") or just not interesting to me.
I've also not found Steve Anderson's experience to be typical. If I've asked a question either on Ubuntu, Gentoo Mint forums I've often gotten good answers to problems. Of course sometimes your problem is unique and it's up to you to solve it yourself. There is a TON (probably several literal TONs) of document ion on Linux and all the tools that go with it. The biggest problem that I've found is being able describe my problem in a way that google, or a forum understands it. 99 times out of 100, the question has been asked before and has also been answered before.
Tyler Herring had another XKCD comic:
Just wanted to make a comment on the technical forums... I find they're pretty much a total crapshoot as well. Usually because the thread contains, at best, bickering and complaints of "why don't you use <XYZ> package or product" instead and product slamming or borderline Rube Goldberg style work arounds.
My personal favorite situation is threads where the person who posted it says days or even weeks later "nevermind, I figured it out" but never posted what they did to solve it.
I'm not sure if you're an XKCD webcomic reader, but this comic sums how the situation usually goes:
On that note, I basically use technical forums to confirm if anyone else has had my issue as sort of a sanity check. And I figure half the time, I may find an answer to my question, and the other half of the time, I'll have to go it alone.
Nick P wrote:
I agree with critics about StackOverflow. It's great for its intended purpose, as Google lands me there often. However, many of the best questions (and answers!) that I found to hard problems were "closed as not constructive." I definitely benefited from the answers. Other times, I had a solid answer to questions that I was blocked from posting. The explanation from the critics is essentially dogma and elitism. That's the kind of thing StackOverflow (and programming culture in general) need to get rid of because it's sacrificing lots of human potential in favor of... ego?
The critics proposed good alternatives. The idea of just letting the normal voting and marking techniques weed the bad ones out over time was nice. Even better was applying garbage collection concept to eliminating worst questions from archive. That combo is simple and should work well. Shows that there's room for a S.O. alternative that has such features along with protections against elitist behavior, maybe even in its non-profit charter. I doubt it would displace S.O., but it might: provide the wisdom the S.O. is closing off to users that want it; pressure S.O. to change their policies. I'd invest... (cough) twenty bucks or so on Kickstarter (cough)... in such a venture.
Also in the last issue, I wrote about the decline in square footage for office workers and corresponding increase in interruptions. Several readers had comments:
Nick P, as he often does, had citations:
I'll add that two things: introverts and flow. Introverts are a significant chunk of knowledge workers. They can often do several people's worth of thinking on a topic. Some of history's best minds were introverts. A relevant drawback is that their brains are hardwired to loose mental energy when interacting with people and especially with interruptions. They're internal people that prefer quiet spaces  that let them focus. These new open environments utterly waste the mental talent of such people by ensuring they can't focus long enough to leverage their mental potential. It's why I, as an introvert, will always turn down such a job no matter how much the pay is.
The other is flow , aka being in the zone. This state of mind can increase one's effectiveness by an order of magnitude. Many surveyed talk of ideas and solutions "flowing" out almost without any mental effort. Until they're interrupted by anything from a distraction that removes train of thought to a major surprise (eg scare) that activates fight or flight response. Recovery requires getting back to normal state of mind, remembering task, remembering context, reconstructing train of thought, doing work again, and then achieving flow again. A common amount of time cited is around 10-15 min for this process *per interruption*.
So, with flow, we have a very important piece of psychology. We know that letting people focus without interruptions for a period of time can dramatically increase their productivity. The recovery process adds wasted productivity on top of the interruption itself. Properly leveraging flow in an organization can be a great competitive advantage. Yet, many organizations will throw it out the window with modern office buildings. That's despite a few studies in engineering showing people with closed offices got more done. I argue that, from a business perspective, it's straight up stupid to throw away potentially billions  in productivity. So, I advocate going back to the old approach of letting people get things done in peace. And more profitably, it turns out.
Sergio R. Caprile mentioned an article:
On this very subject of interruptions, I follow and advocate a very nice
I work 2 or 3 days per week at my lab, where I do pure R&D and hard stuff and 3 or 2 days at the office, where I can be easily interrupted and so work on more mundane tasks. Project meetings are first thing in the morning or the afternoon, on days where I'm at the office. No direct phone calls from outside.
Sales people love me ;^)...
That is an excellent article and is well worth reading.
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.
Andrew Cawood submitted this:
I recently came across this while Googling for an answer to a 418-error on one of my desktop apps - a spec for a Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0):
The date of the RFC gives some explanation, and it is worth a glance for anyone who has spent time wading through RFCs.
The 418-error in question is defined as:
Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot". The resulting entity body MAY be short and stout.
Some other extracts:
Thus, there is a strong, dark, rich requirement for a protocol designed expressly for the brewing of coffee.
Coffee pots heat water using electronic mechanisms, so there is no fire. Thus, no firewalls are necessary, and firewall control policy is irrelevant.
Omitted Header Fields: No options were given for decaffeinated coffee. What's the point?
Security Considerations: Anyone who gets in between me and my morning coffee should be insecure.
Unmoderated access to unprotected coffee pots from Internet users might lead to several kinds of "denial of coffee service" attacks.
Advertise in The Embedded Muse! Over 23,000 embedded developers get this twice-monthly publication. For more information email us at firstname.lastname@example.org.
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.