Posts Tagged ‘sourcery codebench’

17 July, 2017

I was recently approached by a software developer, who was new to embedded programming. As is commonly the case, we had a language problem. It was not that his English was deficient – he just did not speak “embedded”. He asked a question: How do I log on to my target hardware to do debugging?

On the surface, this is a reasonable question. Having ascertained that he was not using Linux – he was using a conventional RTOS – I felt that I needed to explain his options for debugging on an embedded system … Read the rest of this entry »

, , , , ,

22 May, 2017

I recently came across an excellent book: The Art of Readable Code by Dustin Boswell and Trevor Foucher. As soon as I heard about the book, I knew that it would interest me and ordered a copy without delay. For years, I have pushed the message that the #1 priority, when writing code, is readability; the authors and I are on the same wavelength. I am likely to be referring to this book again in this blog, as, on initial reading, although many things are already clear and familiar to me, I still have more to learn and to share … Read the rest of this entry »

, , ,

31 October, 2016

First off, I lay no claim to be an Internet security expert. Maybe because of this, I was quite shocked by the scale and effect of the major DDoS attack that hit the news recently. This attack restricted access to some major websites for Internet users on both sides of the Atlantic. The really interesting aspect of this incident is that the attack was implemented by hijacking large numbers IoT devices … Read the rest of this entry »

, , , , , , ,

17 October, 2016

What are you priorities when writing code? Obviously you need to implement some specific functionality and there may be a required level of performance. This is all testable or measurable. However, there are two other key goals, that are harder rate:

  1. Write code that is clear and easy to understand. I shy away from using the term “self-documenting”, but that is certainly what you should be aiming for.
  2. Make sure that the code is maintainable and extendible. It might be you that has to do future work and a little care now will make your life easier down the line.

It is #2 that I would like to focus on today … Read the rest of this entry »

, , , , ,

22 August, 2016

It is a given that structured programming – in one form or another – is a Good Thing. For years, the spaghetti of GOTOs that arose in earlier programming languages has been abhorred by all right-thinking programmers. There are good reasons for this attitude. Firstly, structured code tends to be easier to debug and, second, the code is more readable and, hence, maintainable. Both of these are productivity improvements, so the GOTO should clearly be avoided.

But, what about the break statement in C? … Read the rest of this entry »

, , , , ,

25 July, 2016

My latest video blog is now available. I am talking about the volatile keyword in C/C++, which is of vital importance to embedded developers. You can see the video here or here:

Future video blogs will continue to look at topics of interest to embedded software developers. Suggestions for topics are always welcome via comment, email or social networking.

, , , , ,

13 June, 2016

I have frequently asserted that one of the most important attributes – maybe the most important attribute – of code is readability. This is because an enormous amount of time is spent on debugging and maintaining code – far more than that expended on writing it in the first place. So, keeping the future human reader [who might be you!] in mind at all times is essential.

Interesting challenges occur when you think about hiding text/code from the compiler … Read the rest of this entry »

, , , , , , , , ,

29 February, 2016

My latest article in embedded.com is the first instalment of a two-part piece:

Self-testing in embedded systems

All electronic systems carry the possibility of failure. An embedded system has intrinsic intelligence that facilitates the possibility of predicting failure and mitigating its effects. This article reviews the options for self-testing that are open to the embedded software developer, along with testing algorithms for memory and some ideas for self-monitoring software in multi-tasking and multi-CPU systems.

This first part concentrates on dealing with hardware failure. The second part, which addresses software failure, will be published soon.

, , ,

4 January, 2016

New Year greetings to everyone. But, before charging into 2016, I will just hark back to 2015 briefly …

On a previous posting I reported what I thought was my last embedded.com article of the year. However, it seems that i jumped the gun, as another article made it under the wire:

Non-intrusive debug

Debugging represents a very significant part of an embedded software development project. All developers have their own favorite approaches and each one has its strengths and weaknesses. A key issue is how intrusive the debug tools are – i.e. the extent to which debugging software affects the functionality of the code. This is not a black and white issue, as a number of factors and priorities need to be considered. This article outlines different approaches to debugging, from the perspective of intrusion, and also considers the implications with respect to code optimization.

, , , ,

28 September, 2015

In a similar way to blog posts here, I often endeavor to address a specific technical matter, that is pertinent to embedded software, in articles I publish elsewhere. Sometimes the topic is a matter where a developer does not need a detailed knowledge on a day-to-day basis, but an understanding of what is going on “under the hood” may be useful. My latest article on embedded.com is a good example … Read the rest of this entry »

, ,

21 September, 2015

Embedded systems, much as we know them now, have been around since the early 1970s, when Intel released the first really practical microprocessor. In those days, the term “embedded systems” had not been coined – that did not come along for another 20 years. I wrote a book, which was published in 1986. There was a long list of possible titles, but the word “embedded” did not appear. It was finally called “Programming Dedicated Microprocessors”.

I have always had trouble explaining what I do professionally. People understand that I work with software, but are confused when I cannot necessarily help them make their PC work better. I have to explain what an embedded system is. The description I use is something like this: Inside almost all modern electronic devices are tiny computer chips called microprocessors. They run a fixed program to provide the required functionality to the device. That is an embedded system … Read the rest of this entry »

, ,

10 August, 2015

It seems that hardly a day goes by during which someone does not say “This is like science fiction!” Typically, they are talking about cell phones, GPS, tablets, cars with keyless ignition – the list goes on. Only this morning, I was using Apple Pay [which has just been launched in the UK] to get my breakfast and the server smiled and said “Love technology …”.

These are all embedded systems [or the close relatives thereof] and are very complex … Read the rest of this entry »

, , ,

1 June, 2015

It is common for C to provide several different ways to do something, all of which are exactly equivalent. For example, given that x is a normal int variable:

x = x + 1;

is exactly equivalent to:

x += 1;

or

x++;

The only possible difference is that a less capable compiler might generate slightly better code for the second and third options [which would be a hint that getting a better compiler would be worthwhile].

However, sometimes constructs that appear to be equivalent have very subtle differences … Read the rest of this entry »

, , ,

4 August, 2014

I started a couple of weeks ago, when I received an email from Sandeep Vasant from Ahmedabad University in India. For reasons that he has yet to reveal, he was having trouble with some code like this:

int a=10, b=20, c=0;
c = a++ + a++ + b++ + b++ + ++a + ++b;

He tried this with one compiler and the resulting values of a, b and c were 13, 23 and 96 respectively. He was satisfied with this result. Then he tried a different compiler, which yielded a final value for c of 98, which he found confusing.

I started looking into this, certain that the explanation was simple … Read the rest of this entry »

, , ,

28 July, 2014

I often need to do a bit of programming – normally C or C++. I am not generally writing a real software application, as that is not my job, but I often need to produce chunks of code to illustrate a point in an article, presentation or blog post. This code can be anything from a single line to a few dozen. Obviously, all I need to do is create a text file for the code and build it using a suitable toolchain for execution on my PC or for inspection of the resulting assembly language output.

Recently, I was introduced to an interesting alternative … Read the rest of this entry »

, , , ,

10 March, 2014

I am always interested in receiving feedback and comment on my blog posts and, when I recently wrote about embedded software engineering priorities, I did receive some interesting responses. When I get some useful input, I commonly ask permission to publish it. Sometimes this is refused, but usually I am given leave to post the comments.

In this case, the comments are, IMHO, quite controversial … Read the rest of this entry »

,

10 February, 2014

Apart from writing about embedded software matters, I also read widely and enjoy the perspectives offered by many of the key figures in the field. One writer, who always gets my attention, is Jim Turley. Jim is never afraid of raising contentious issues and tends to take something of a chip-centric view of embedded systems.

He seemed surprised, in a recent article, to find that engineers’ priorities might be different … Read the rest of this entry »

, , , ,

9 December, 2013

, , , , , , ,

2 September, 2013

, , , , ,

@colin_walls tweets

Follow colin_walls