Advertisement

Colin Walls

image
Embedded Software Technologist

Colin Walls has nearly forty years’ experience in the electronics industry, largely dedicated to embedded 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 with Mentor, a Siemens business, and is based in the UK.

Colin Walls

's contributions
Articles
Comments
    • Colin continues the RTOS Revealed series with a look at queues, which provide a more flexible means of passing simple messages between tasks than mailboxes.

    • In this installment of the RTOS Revealed series, Colin continues his discussion on mailboxes, focusing on key utility services and data structures supported by the Nucleus SE RTOS.

    • Mailboxes are perhaps the second simplest method of inter-task communication – after signals – supported by Nucleus SE. They provide a low cost, but flexible, means of passing simple messages between tasks.

    • In this installment of his RTOS Revealed series, Colin explains signals, which are the simplest method of inter-task communication supported by Nucleus SE.

    • The world of embedded software - or actually the world as a whole - needs more innovators like Jim Ready. I think that they broke the mold when they made him. RIP Jim.

    • A partition is a memory area obtained from a partition pool and offers a flexible means for tasks to obtain and release data storage in a deterministic and reliable fashion. This installment of the RTOS Revealed series describes partitions and their use in an RTOS.

    • Colin continues his RTOS Revealed series with a look at the RTOS services that provide additional information about tasks or operations on them.

    • In this latest installment of RTOS Revealed, Colin discusses how tasks are configured in Nucleus SE and begins to detail the service calls for tasks in both Nucleus SE and Nucleus RTOS.

    • Understanding the detailed workings of a specific RTOS will give you a good basis for coming to grips with any RTOS. Here's a look at the inner workings of the Nucleus SE RTOS.

    • Understanding the detailed workings of a specific RTOS will give you a good basis for coming to grips with any RTOS.

    • Colin's RTOS Revealed series continues with a look at what lies beyond a kernel and what makes a kernel become an operating system.

    • Being able to identify and specify each task in a system is a key requirement, but tasks have some subtle nuances that make a discussion of the broader topic appropriate.

    • This series delves into all aspects of real time operating systems (RTOS) and is intended for any developer who is curious about how to use an RTOS and how they work.

    • In this next article in his RTOS Revealed series, Colin looks at how tasks are defined and how task scheduling works.

    • Colin Walls introduces RTOS Revealed -- a new series that will delve into all aspects of real time operating systems.

    • Exception handling in C++ is controversial among embedded software developers, as is the use of the language at all.

    • A car has become a mobile box full of embedded systems, and a working knowledge of the standards and approaches to automotive software development is, therefore, useful.

    • The selection of a CPU in any embedded design has long been considered a "hardware issue," but the implications of the choice on software development are profound.

    • Designing any kind of system to be truly safe is a challenge. The first requirement is to define the term "safe" and consider the implications of it being unsafe.

    • On the characteristics of an embedded hypervisor, what facilities it can offer and some typical applications.

    • To what extent debugging software affects the functionality of the code is not a black and white issue.

    • Here's an approach that enables some quite imaginative functionality to be added to devices with minimal effort and cost.

    • The order in which bytes are stored in a CPU word can often be ignored but sometimes an appreciation of this matter is critical.

    • A simple LED indicator can provide a humble "UI" to communicate some information to the user.

    • Colin Walls discusses the details of floating point operations, when floating point should and should not be used, some of the pitfalls of its use, and how its use may sometimes be avoided.

    • RTOS overhead needs to be carefully evaluated in embedded systems with limited resources, but determining RTOS memory footprint may be difficult.

    • Historically, power management was purely a hardware issue, but today software is increasingly responsible for power management in embedded systems.

    • Optimized for embedded applications, an HTTP server is likely to be quite small in terms of code size and can provide a user interface limited only by the designer's imagination.

    • One of the myths associated with IPv6 is that the only reason to adopt IPv6 is the impending depletion of the IPv4 address space.

    • Network protocol designers have developed "bit-stuffing" techniques that involve adding extra bits to indicate the end of a message in a stream of data.

    • Most embedded software developers spend the bulk of their time debugging. This does beg the question: What does debugging actually mean? The answer is less simple than you might expect.

    • The conflicts that occur when optimizing an embedded design for size versus speed in a limited resource environment and what developers can do about resolving them.

    • Colin Walls looks at why embedded software programming differs so much from programming for desktop computers and why there are so many options for programming tools. He also provides a strategy for selecting the tools you need.

    • Selecting an RTOS for an embedded system is quite a complex process and making the right decision is critical. It will require looking at and evaluating the metrics of three important parameters: memory footprint, interrupt and scheduling latencies, and kernel services timing.

    • If all you want to do is just some basic multithreading or multitasking, here is a guide to how to make judgments on system complexity and some techniques to achieve your goals with no more than a few lines of code.

    • Using C language’s low level capabilities to access registers in peripheral devices should be simple and straight forward, but because no standard way has emerged to do it, the procedure has a number of options and pitfalls.

    • Colin Walls provides an example of why he thinks Forth, an interpretive stack-based programming language popular in the 1970s, might be a good tool for very low cost MCUs, especially in the age of the Internet of Things.

    • Passing parameters to a C function seems simple enough. The details of how that process takes place have a significant impact on the behavior and performance of the code. This article looks at parameter passing mechanisms and how to use them optimally.

    • Medical devices should be of interest to any embedded software developer as they encapsulate a great many of the techniques that characterize modern embedded systems development.

    • The C/C++ keyword ‘static’ has two separate uses. This article explains those uses and clarifies their relevance to embedded developers.

    • A “blast from the past” personal story from C and C++ programming specialist Colin Walls on the first multicore software design he developed in 1981.

    • Colin Walls explains how replacement of a function call by a copy of the code of the function works through the use of inlining.

    • Colin Walls look at operator overloading and how it can be used to yield readable and maintainable code. He includes examples of good and bad practice.

    • Colin Walls provides some guidelines on how to determine the kind of usage a device may receive and the trade-offs in the startup design parameters that must be considered.

    • How RTOS blocking system calls work and how they can be used to manage CPU time, distribute tasks and manage other resources such as peripherals.

    • Colin Walls considers the possibility of a repeat of the “millennium bug” (aka Y2K) panic, when it was thought that timers in systems might not be able to cope with the date roll over to the year 2000.

    • That depends on the NVRAM technology. A battery-backed RAM would become unreliable as the battery drains and then fail totally. Flash memory tends to be reliable, but only survives a certain number of write/erase cycles. That is normally a lot. I think the failure mode is incomplete erasure.

    • @Mark54 - I am not aware that Jim had any involvement with those OSes. RMX came out of Intel, IIRC; OS9 was a bit of an outlier, but quite popular in its day.

    • The complete code will be available later in the series - i.e. when I have written enough to enable users to deploy the code.

    • Like Max, I strongly prefer a date style that is sortable and tend to use YYMMDD. This is favored by people in Sweden and Japan and is also the basis of the ISO date format, I believe.

    • Although I know I'll continue to run into you elsewhere - virtually and, I hope, in the real world - I'll miss reading your thoughts and insights here. It takes a brave man to say "no more", when they have established an institution. I respect your bravery.

    • @Joffrey - Yes, an intermediate layer is what I have in mind. Thanks for the other resources. BTW, the "one line RTOS" may reappear. :-)

    • I am right with you on the topic of YouTube, Jack. As usual, you're a man after my own heart. I loved "I always crank the speed up to 1.5X which is a bit more efficient." - I thought I was the only person on the planet that did that! :-)

    • I would imagine that the sensors would be tested and routinely replaced as part of the standard servicing schedule. However, this is really outside of my area of expertise.

    • @Ogautherot - If I were interviewing you, I would actually expect the answer "pointer to int". :-) Except that I agree with you about it being a reference [and I would never ask such a question!].

    • Like you, I have chucked quite a few things that might be at least of interest, if not of value, today. I do, however, have a small collection of elderly computing and electronics books: PDP-11 manuals, a PDP-8 programming guide, books on Fortran, Algol and SNOBOL... I have a TI TTL Data Book, but it's quite new [1983] - that's yours if you want it.

    • Nice article Jack. I like the begin/end idea [but I have written Algol in my time ...] What I would change: Sort out the static keyword. It does what it's supposed to, but that is confusing to many, as it has [at least] 2 separate meanings. It can control how a variable is stored and the scope of a function. I'd like to see a simple way to declare a function or an external variable as local [to the module] or global.

    • There are certainly some high quality open source software out there. Not too much in the RTOS space, but, as you say there are some options. The big issue is support. If you are incorporating someone else's IP into your design, you need to be confident that any problems that arise can be addressed promptly. Typically the open source community is very supportive, but a contractual obligation focuses the mind.

    • Great story Jack. As my Dad is the same age, I know where you're coming from. My Dad's sister is a mere 87 and she mentioned in passing how much she love to have the chance to visit a favourite place in Portugal [not too far from UK]. It cost me very little money to grant her wish a few weeks ago, but the payback is priceless. I concur with @Sliebson3 - do go off topic more often. You are talking to engineers, many of whom will share your other interests.

    • @GordonScott: Yes, of course there's nothing new in the world. At least using a visible LED would get the attention of a human operator. It was the Morse "SMS" bleeps that gave me this idea originally.

    • @Dl2iac - Good to hear that my points are rooted in the real world. I agree that using Morse Code for more text would not be very useful.

    • Embedded developers tend to be conservative and take an "if it ain't broke, don't fix it" kind of attitude. In this case, breakage did occur a while back.

    • I did not claim to invent this technique, so it is not a question of reinventing. I was just intending to make readers aware of the approach.

    • I am not sure that I really understand your questions fully. For the most part, the answers would depend on which tools you are using. If I can help further, please email me: colin_walls@mentor.com

    • "The insurance person never thought about how things work" Is it because I'm an engineer that I find this mindset incomprehensible? I just can't imagine going through life with no clue about how things work. I just HAVE to know. I don't have to understand all the tiny details, obviously, but I would feel bewildered if I didn't grasp the basic principles. Nice piece Jack.

    • I am sorry, but that makes no sense, as it is not possible, with CPU that I know of, to access less than a byte of memory, even if the software instructions might appear to facilitate this. So, any access exceptions will occur only if a memiry address does not exist.

    • I assume that this question is really: is MCAPI and alternative to using a hypervisor to build a supervised multicore system? The answer to that is no. MCAPI’s role is simply to handle message passing between cores [or, more correctly, nodes]. I guess that one core could effectively disable another by sending it a barrage of messages, but I cannot readily envisage a way that MCAPI could be used to do anything more malicious. Since MCAPI is set up statically [normally], I would not think that there would be too much opportunity for malicious code to be introduced. Thinking further, MCAPI does not enable one core to give another core any code to execute. The most extreme possibility that I could imagine is that a “bad” core loads some code into shared memory [a common interface technology] and persuades the other CPU to execute it. However, I would hope that measures are taken to avoid ever executing code out of shared memory. Apart from security concerns, there are lots of reasons why this is unwise. As an aside, the introduction of the heterogeneous cores into the mix, as you have referred in your question, whether it is adding ARM Cortex M3/M4 cores to the ARM Cortex A9/A15 core block in TI and FSL devices, or adding softcores in Altera and Xilinx case, is indeed a fascinating area and something that Mentor Embedded folks have been working on. The opportunities and challenges that these heterogeneous multicore and multi-OS systems bring is a topic on its own, which would be a good subject for a future article.

    • Delsner: You are correct! It looks as if the second page has gone. I will advise the editor.

    • Good point Matt. Of course, non-static objects are initialized at run time, so there is nothing worry about.

    • Paul: You are right - I am a little sloppy about my terminology. With regard to your second point, didn't I cover that under "Thread Protected Mode"?

    • MMU support can only really be incorporated by the RTOS vendor; it cannot be "retrofitted". The use of the MMU is most likely to be quite transparent to the application developer. Once the OS is configured, there is little else to do. In theory, an MMU can be used without an OS of any kind, but that would be very unusual.

    • I think your phrase "Different strokes for different folks" sums it up perfectly. I have reservations about Twitter, but I think that what matters most is how it's used. People blame PowerPoint for bad presentations; it is not the software's fault that some people just don't know how to communicate. "A bad workman blames his tools." Twitter's brevity could be a strength, I feel, as it can result in focus. Attribution for the quote "If I had more time, I would have written a shorter letter." is fuzzy, but it makes a good point. My relationship with the Internet is 24/7 passionate enthusiasm. I just love having so much information at my fingertips. When I was a kid, my Dad bought me a big set of encyclopedias [when he realized that he was no longer able to answer all my questions]. Typically, I would be doing my homework and grab a volume to look up something. I would then be lost for hours, as one interesting [but probably irrelevant to my original enquiry] reference led to another. Nowadays, I am the same with the Internet. It is just easier to retrace my path and find stuff repeatably [and just a tad bigger].

    • You are right Paul. I should have said "The inline keyword was also implemented in many C compilers as a language extension,and later added to the standard language."

    • I take your point Losgann, my comment about Forth did appear harsh, but that was the result of the necessity for brevity. As Twburger points out, the readability of code is really the responsibility of the programmer, but it is nice when the language encourages good practice. I could write very readable Forth, a language for which I have something of an affection, but I could also write totally unintelligible C. I did write a more balanced piece of Forth here: http://blogs.mentor.com/colinwalls/blog/2010/10/19/go-forth/

    • 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