Colin Walls

image
Firmware/Software Engineering Management
Colin Walls has over thirty years experience in the electronics industry, largely dedicated to embedded systems software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, Colin is an embedded software technologist in the Mentor Graphics Embedded Software Division and is based in the UK. His regular blog is located at http://blogs.mentor.com/colinwalls and he may be reached by email at colin_walls@mentor.com.

Colin Walls

's contributions
Articles
Comments
Discussions
    • Gato: With all due respect to you, I believe that you misunderstood what I said. In my original example, i was a simple int - that is why I was mystified about any possible difference between ++i and i++. My colleagues were simply picking me up on style.

    • Yes. You are right. It is only a temporary fix, but it meant that a device might have up to 100 year lifespan [which is overkill] instead of around 20 [which was tight].

    • Chris. I agree with you entirely. I think that embedded programmers should, at a bare minimum be able to understand assembly, if only to make sure that the compiler is doing a good job. Resorting to writing assembly is also an option that I would not want to see removed. The art of writing embedded code comes from understanding the tools and what they can do for you in order to use limited resources in an optimal way.

    • I am with you on the blinking LED issue. There is a cool feeling when a system "comes alive" - almost like you have breathed life into to it yourself. The amount of information that a single LED can provide is surprising, as there are many possible states: on, off, flashing [with various duty cycles], pulse sequences, Morse code ... The biggest error is to conclude that an LED flashing shows the code is working. Sure, you want it to flash to indicate processing is occurring, but make sure that it is accessed from real code. I have seen a status LED driven from a timer ISR, which would carry on merrily reporting that all's well when the rest of the system had crashed.

    • I recently jointly authored a white paper "Embedded System Power Consumption: A Software or Hardware Issue?", which may interest readers and may be obtained for free here: http://www.mentor.com/embedded-software/resources/overview/embedded-system-power-consumption-a-software-or-hardware-issue-374257e7-4a93-4229-84a6-89d855b2443b