For a free resource to help get us embedded engineers thinking about security, Ross Anderson's book, "Security Engineering" (2nd edition), is free online at http://www.cl.cam.ac.uk/~rja14/book.html. Each chapter of the 1000-page book is a separate PDF file.

(Thanks to Bruce Schneier's blog for that link.)

Regarding your comment on there being few Automated Embedded Test tools out there, check out the free "Unity" tool at www.ThrowTheSwitch.org.

My friend Mark Vandervoord (a.k.a. "Dr. Surly") is one of the co-developers of it, and it is featured in James Grenning's book: https://pragprog.com/book/jgade/test-driven-development-for-embedded-c. They are launching not-free webinars: http://throwtheswitch.org/dr-surlys-school.

In "Tools and Tips" many times snagit, snipit, dropbox, and Window screen capture have been mentioned but nobody mentioned "Greenshot". It is an excellent software and freeware. It does rectangle, windowed, and full screen capture with a nice set of highlighting and annotation.

I have used it for many years. Please give it a try.

On the snipping tool, I hope this is not too obvious. In windows, <SHIFT> print screen captures the entire desktop, but <ALT> print screen only captures the currently active window.

For basic & simple image editing, i.e. cropping screen capture, I use Paint.NET.

CNET: Paint.NET is a full-featured image editing program ...
Wikipedia: Paint.NET is a freeware raster graphics editor software for Microsoft Windows ...

Pure Text is a tiny application sitting silent on the desktop bar (reminds me of a TSR, Terminate and stay resident of old DOS days…). When you copy some text or excel cells using CTRL-C, using Windowskey-V instead of CTRL-V to paste it removes all formatting leaving only the “pure text” hence the name.

I found this little tool just *great* when working on excel sheets full of data to move around or when pasting text between word documents with totally different formatting/font/highlighting/whatever, or doing the “unpredictable results copy” from excel to word or vice-versa.

Microsoft OneNote (Windows icon) + S

Screenshot Captor

JING

HyperSnap

In high school I had a friend who was a brilliant cartoonist, usually on the blackboard (remember them?). Whenever he did a cartoon he would first stare at the space where the drawing would go for several minutes, then quickly draw in the lines accurately and perfectly. The first draft was the finished article. I asked him about this once and he told me, "I do the cartoon completely in my head first and then project it onto the paper. When I'm drawing I'm just tracing the lines".

There is a similar story in "The Shipping News", where the main character, Quoyle, commissions a boatbuilder to build a small wooden boat for him. After several visits he is dismayed to see no progress, nothing even started. The boatbuilder assures him the boat is nearly finished, in his head. Once the boatbuilder is satisfied with every detail, he starts shaping the wood and boat goes together very quickly. (I thought you might appreciate that Jack, since you are a sailing person).

I believe this way of thinking has merit for writing software, although from experience I know it is hard to justify a lot of time with no obvious output to managers. It doesn't mean you don't do testing. However, when it comes to testing, the software is more likely to work first time and have fewer bugs. The other extreme is continuous hacking and testing with plenty of output but no clear definition of when it is finished (been there, done that too!).

Like the programmer you mentioned, I also like to work out everything in my mind before coding and the path between knowing what to do and actually walking the defined path can be tedious, as you noted.

However, you also dropped a comment about management "lopping off" some of the schedule. In my experience, most employees do their best to estimate the time it will take to do something based on their estimate of the degree of complexity involved and the amount of new knowledge that will be required. This is the estimate they give to management. It does not include "Oh, by the way"s or the frequent, "Could you work this in for me?", and certainly not the "lopping off" bit.

When the schedule extends past the calendar date management has passed on without adjusting for past history regarding the lack of correlation between that individual's estimates and actual calendar days spent since start of the project, guess who is blamed? For some reason, many managers appear to think that programmers can be forced to be more productive through clever manipulation by management. They also seem to share the curious notion that they can ask for additional tasks to be completed during the project that will not affect the time required to complete the project.

Some of the worst examples of this idiocy I have encountered were practiced by some of the same people who had experienced the problem from the other end. Perhaps our concepts of management and labor need to be re-examined?

Every manager needs a sign on his office wall that reads, "No problem" does not mean that it will not require time and money to implement your request. It simply means that the person sees no technical difficulty in complying.

On "Is it Done Yet?" I feel the pressure--and shame--from making bad time estimates myself and I now see people who work for me painting themselves into the same corner.

Automated testing would be helpful but a lot of testing software has more bugs than the DUT, simply because the testing software is thrown together fast and dirty. Much of the debugging we do when a test shows errors, is figuring out that the test gave the wrong inputs or expected the wrong result.

What I find helps a great deal is pulling the question back to a scope and a timeframe where an engineer can see all of the factors involved: "What can you deliver this week?" and "If that goes well, what can you deliver next week?" Then it is up to me to see the rate at which we are making progress, the difficulty of the tasks ahead and be the fool to estimate the time until task completion, but only with the details of how I arrived at that estimate. Since my company does a good bit of research, the people asking for the estimates have to understand the consequences of not even knowing yet what all of the difficulties are.

I have to agree with the comments on discipline in the newsletter.

In particular those by Dave Telling. I too had a technical military background as did my father who was involved in the design of aircraft jet engines, who also said that discipline was one of the most important traits in design. Short cuts in jet engine design could be fatal! Having discipline makes life a lot easier as many things can be done properly and automatically. Couple this with a good process and things become very efficient; things just work and you get fewer errors (bugs).

As for his comments on MISRA-C: Overall they [the MISRA-C rules] work. He mentioned relaxing some of them. Yes this is required! There are only 10 Mandatory rules. The MISRA-C team recognised that not all the rules are appropriate 100% of the time in fact my first conference presentation after the launch of MISA-C:2012 was Why MISRA-C might kill your project!
http://www.safetycritical.info/library/presentations/DD-MISRA-C3.pdf

It is because many just see MISRA-C as a tick box and do not apply it with care, relaxing rules (with written justifications or deviations) as needed. If you apply 100% of the MISRA-C rules 100% of the time you get MISERY-C but you have only yourselves to blame. This second paper does explain how to implement MISRA-C: http://www.safetycritical.info/library/presentations/MISRA-C3-0002.pdf

One of the main problems is no one really understands C. I covered this in the presentation MISRA-C Curse or Cure:
http://www.safetycritical.info/library/presentations/MISRA-C-curse-or-cure.pdf. Ask any set of programmers which book to use to learn C and most will say K&R despite it being published over 26 years ago before ISO C90, C99 and C11. It is also about 1/3 the page count of the current C standard (and has smaller pages). ISO-C** is a language definition like a dictionary yet very few programmers have even seen a copy let alone own one. So where did programmers learn their C? By word of mouth? Trial and error? From a book that only covers a fraction of the standard? Also as the Curse or Cure paper points out static analysis (lint) was invented in 1976 and intended to be part of the compile chain. It is also usually rule 1 in the programmers 10 commandments. How many programmers have the discipline to run static analysis before every compile and if not why not? We are back to discipline again.

This is a big area for me. I think too often the entire Computer Programming Field (Software Engineers, Programmers, etc) view it too much as "art" and therefore write off anything related to "discipline" as interfering with the "art". Thereby, it only perpetuates the problem. The challenge is that I think the field needs to simply "grow up" and mature. The field - in all forms - is relatively new compared to any other similar field, even Electrical Engineering, it's closest relative and sibling. Developers need to realize that it is not an "art"; but it's a disciplined, pragmatically driven field where code-styles need to be enforced, and if you don't like it, then oh well, get in line and do the job; where code logic structures need to be done and enforced such that best practices are performed and bring out the best software with deterministic outcomes and nothing is left to chance. And the list goes on. I've probably written to you about this prior as well. Sadly it will probably be another several decades before these things really come to pass; and sadly too often we just limp about when we could be fixing the broken bones in our collective bodies of software.

The book Computer Approximations by John Hart is available as a reprinted edition from Krieger Publishing, ISBN-10:0-88275-642-7 ISBN-13: 978-0882756424 and Amazon. The reprint is dated 1978, rather than 1968 for the original Wiley printing. It apparently contains some (minor) corrections. The biggest benefit is besides being cheaper than used copies of the original edition in many cases, it is printed on acid-free paper so hasn't turned yellow, and as still available
("in-print") as new, including from Amazon for ~$85 USD.

That all said, I would suggest anyone wanting to learn about computing approximations techniques would be better served by Elementary Functions: Algorithms and Implementation 2nd ed. by Jean-Michel Muller (2005) which gives a state-of-the-art perspective, yet is still largely accessible to the software professional without an advanced mathematics background. Given that it is nearly half the price (~47 USD at Amazon) and far more up-to-date discussing contemporary processors and operating systems it is easy to recommend as a very suitable alternative or rather replacement to Hart's Computer Approximations. It is more theoretical than Hart, but given the availability of freely available (and often multiple public domain) implementations of varying quality in this age, the understanding is perhaps more scarce than the techniques or implementations.

Jean-Michel Muller, also has a second related but different book on floating point arithmetic itself, Handbook of Floating-Point Arithmetic (2009). This is the best technical background on floating point mathematics that I know of. It also is one of the few detailed written explanations on floating point numbers, arithmetic, and techniques that covers that revised IEEE 754-2008 floating point specification. It also covers floating point arithmetic in hardware, though at the theoretic, rather than concrete level (it is not a Verilog/VDHL cookbook of techniques). Highly recommended for anyone in scientific programming or needs to really understand floating point calculations.

We in the embedded systems world are used to what I call cross-domain job requirements. The job posting in Muse 280 is an example of cross-domain job requirements.

In in the embedded systems we blend technologies from electrical engineering, mixed signal, high-speed digital, VHDL, software design aka firmware, PCB layout with balanced impedance traces, RF, etc. And this blend of cross domain skills is sometimes executed well.

Sometimes not.

Re: excerpt from job posting for a web developer
* Writing back-end Ruby code
* Turning PSDs into beautiful UIs