"If you want to go fast, go alone. If you want to go far, go together." --African Proverb
In this issue:
- Is it a Bug or an Error?
- Free and Customizable "Error"-Killing C Coding Standard
- Better Trained Teams Produce Code with Fewer "Errors"
- Modern Embedded Programming: Beyond the RTOS
- How to Comply with MISRA-C's Guidelines
- Industry News That's Not Boring
Firmware Update is a free, monthly newsletter by embedded systems expert Michael Barr. Firmware Update is a trademark and this issue is Copyright © 2018. You may forward whole issues to colleagues that design embedded systems. No other uses are permitted.
Is it a Bug or an Error?
You’ve probably heard the story of Grace Hopper attaching a moth dislodged from the relay in a mainframe to an engineering notebook (photo below) and labeling it the “First actual case of bug being found.” It was after this 1947 event that the use of words like “bugs” and “debugging” took off in the emerging software realm.
But why is it that if a bridge collapses we say it was an "error" of the designer(s) and don't attribute it to an inevitable act of god or “bug”? Why do only software engineers get a linguistic pass for their failures? Is it time for us to stop saying "bugs" and start saying "errors"?
Join this discussion all around our community, e.g., at EmbeddedGurus, EEWeb, and EmbeddedRelated.
Free and Customizable "Error"-Killing C Coding Standard
The "error"-killing Embedded C Coding Standard is followed by thousands of embedded software developers who want to reduce the number of "errors" that creep into their firmware during the coding phase. Though this popular standard is most often followed as is, some teams inevitably prefer to add/change/delete some rules to fit their project-specific needs. One company that did this was Pole/Zero.
To avoid the expense and risk of developing a proprietary standard from scratch on their own, the engineers at Pole/Zero licensed the editable Word .DOC version of the standard, which is available for purchase and download at https://barrgroup.com/embedded-systems/books/embedded-c-coding-standard.
Better Trained Teams Produce Code with Fewer "Errors"
Barr Group has scheduled a series of hands-on training events in April and May 2018. Each course is laser-focused on practical skills development that attendees can immediately put to use writing less "error"-prone firmware faster.
- Embedded Software Boot Camp (4 days)
- Test-Driven Development (TDD) & Agile (3 days)
- Embedded Security Boot Camp (4 days)
- Debugging Embedded Systems on the Target (2 days)
- Embedded Android® Boot Camp (4 days)
- Developing Effective Coding Standards (1 day)
Registration is now open with payments accepted via credit card or company check. Discounts are available for alumni of prior courses and groups of 3 and larger.
Alternatively, if you have a team of five or more, consider bringing a Barr Group instructor to your office for an on-site training of the above or any other workshop from the full course catalog.
Modern Embedded Programming: Beyond the RTOS
How to Comply with MISRA-C's Guidelines
The MISRA-C coding guidelines are widely followed by designers of mission-critical embedded systems in a range of industries. So when Datalight developed its Reliance Edge™ embeddable file system, they knew they wanted to comply but also recognized that they didn't then have the right skills in house.
Datalight's first step was to hire Barr Group to teach an on-site Firmware Defect Prevention for Safety-Critical Systems course, to ensure that everyone on the team had a solid foundation for applying coding standards, code reviews, and static analysis. Next, Barr Group provided coaching and guidance services to assist the Datalight team in rapidly increasing its knowledge of MISRA-C. Finally, as the product approached a stable release, Datalight brought Barr Group back to perform an independent source code review.
How can Barr Group help your engineering team achieve success? Find out more...
Industry News That's Not Boring
The Perils of Autonomous Driving and "Software on Wheels" http://www.ibtimes.com/perils-autonomous-driving-software-wheels-2648011
A mere 25 miles from Moscow, the Marx generator is a Tesla tower so powerful, it can emit energy equivalent to the electricity produced by all the power plants in Russia: https://www.engadget.com/2015/02/18/russia-tesla-tower-drone-footage/ (but only for 100 usec)
If it wasn't for the launch of the Mosaic web browser now 25 (!) years ago, you might still be getting news like this via the Gopher protocol: http://www.zdnet.com/article/mosaics-birthday-25-years-of-the-modern-web/
Want to stop creating spaghetti code? Watch this handy video tutorial: https://youtu.be/k7O2IHH7aC8
Jack Ganssle is currently conducting a survey of the salaries of embedded systems designers. Please participate if you have a few minutes: http://www.ganssle.com/salary-survey-2018.html
And while you're at it, a researcher at the University of Kansas is conducting a different survey about embedded systems design practices and schedules at https://kstate.qualtrics.com/jfe/form/SV_0ujD0sDWFdEg341
Can three random teens build an Oculus Rift-style headset for about $100? Apparently, yes:
Quick Links to Useful Stuff
How to Contact the Author
I'm always interested in hearing from embedded systems designers and happy to take a few minutes to help you find the resources to get a design done right. Send me an email anytime. And be sure to also connect with me on Twitter (@embeddedbarr) and LinkedIn (https://linkedin.com/in/embeddedbarr).
Meet Me at Embedded World 2018!
Will you be at this year's Embedded World conference in Nuremberg, Germany?
Join me from 11am-1pm any of the three days (27 Feb – 1 Mar) in the Open Systems Media Embedded Pavilion (Booth 3A-507 in Hall 3A). During that time, I’ll be presenting some of our findings from the 2018 Embedded Systems Safety & Security Survey for which the complete analysis report will be released that same week.
Will you be at Embedded World also? If so, please reply to this email so we can try to meet in person.
