Martin Cowen ⁽⁴⁵⁾

Quite a large proportion of embedded firmware jobs are in the defence industry. I won't be a part of that and here's why. There's a practical problem and a moral problem. The practical problem is not knowing who the products will be used by, when, and for what purpose. As usual, the BBC comedy show Yes Minister has more truths in it than official statements and procedures. Jim Hacker - "So there's no real control over who the arms go to in the end?" Sir Humphrey Appleby - "Oh indeed there is - the dealer has to provide and end-user certificate which is a signature acceptable to Her Majesty's government that the ultimate customer is in fact an approved user." Jim Hacker - "Is that that a real guarantee? I mean would you be surprised for instance if a British…

After nearly 10 years of continuous operation, my Panasonic DMR-EX77 PVR died. The display went out and it didn't respond to the remote control. Sometimes this type of failure is just a fuse which has been stressed too many times by the inrush current produced when charging large capacitors in the power supply, but not this time. It was immediately obvious that the electrolytic capacitors had failed. I could see their bulging tops which are designed to blow out in the event of failure. All electrolytic capacitors have an expected lifetime which is mainly due to the wet electrolyte drying out at which point the capacitance drops and the equivalent series resistance goes up. It seems to be a common problem with these PVRs. On this product, the capacitors which needed replacing were identified as C1401, C1402, C4056 & C1557.

A function to reverse the order of bits in a byte makes for a good interview question. The candidate has to think about loops, shifting and masking as well as the mundane but important issues of function and variable naming, data types, spacing and comments. As opposed to those "gotcha" questions apparently beloved by the tech giants where you have to know some trick, this can be worked through methodically. Once there is a solution on the table, there is an opportunity to talk about optimization for speed and/or space. There are lots of ways to approach this problem, but I suspect that many will take this simple idea of testing each bit and setting the LSB of the output in a loop which shifts up the output and mask one place each time. //bit reverse eg 0x80 return x01…

Generally, the advice on unit testing in embedded environments is to run your tests on the PC host rather than on the target device. Whilst I agree that this is the most productive arrangement, there are a variety of reasons for needing to test on the target which can be convincing in certain situation. The technique described here allows for both. Mike Long in his GOTO 2015 presentation Continuous Delivery for Embedded Systems says "Test on your host because that's fast - it's a really fast way to develop. But also test on the target because behaviour can change in different ways, different compilers, different hardware..." Niall Cooling in his talk at the EmbeddedOnlineConference 2020 "How agile is changing the face of embedded software development" says (at 46m) on the gap between testing on the host and the target Things…

I've been using this interview question for the last 20 years to test embedded C engineers: Given the formula for Fahrenheit as 9 * C + 32 = F - 5 Write a function to convert unsigned char tempInC to unsigned char tempInF (ie. All values are bytes, including intermediate results). The processor has no floating point library. Recently I was intrigued to find that a very similar problem was posed by professor James M. Conrad at the University of North Carolina at Charlotte at this point in his lecture on Embedded Systems: Software Testing. The responses I used to get were similar to what the students gave in that video. Whilst some candidates would think this was a maths problem that needed rearranging to solve for tempInC, others thought that I just wanted them to write the formula in…