Posts Tagged ‘development tools’

18 September, 2017

My latest video blog is now available. This time I am looking at how parameters are passed to functions in C. Embedded developers like to know how things work under the hood. 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.

, , ,

26 June, 2017

All C/C++ functions have a single point of entry and it is widely thought that a single point of exit is logical. Indeed, a number of programming standards [MISRA C for example] insist on this approach. The logic is that a single return statement makes for clearer, easier to read code. Additionally, a single exit point means that there is less chance of failing to execute function exit code, which may deallocate resources etc. Such an error leads to memory leaks and the like. The contrary argument is that an early return might avoid the need for some convoluted logic to direct the execution flow to the end of the function – a nest of if … else constructs can be hard to read.

I have been pondering an alternative approach that might deliver the best of both worlds … 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 »

, , ,

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 »

, , , , ,

29 August, 2016

My latest article at embedded.com has been published:

C++ Exception Handling

Exception handling in C++ is controversial among embedded software developers, as is the use of the language at all. The feature is designed to make code more readable by providing a cleaner way to handle error conditions. This article aims to clarify what the facility does and how overheads may be managed.

With all aspects of embedded software development, good tools are instrumental in project success.

, , ,

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.

, , , , ,

11 July, 2016

My latest article at embedded.com has been published:

CPU selection in embedded systems

The selection of a CPU in any embedded design has long been considered a ”hardware issue”. As it is part of the hardware, this seems logical. However, the implications of the choice on the software development are profound. This article puts the case for a stronger influence from software developers in the CPU selection process.

, ,

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 »

, , , , , , , , ,

16 May, 2016

Embedded developers often bemoan the fact that no programming language is ideal for their particular needs. In a way, this situation is unsurprising, because, although a great many developers are working on embedded applications, they are still only quite a small subset of the world’s programming community. Nevertheless, some languages have been developed with embedded in mind. Notable examples are PL/M, Forth and Ada, all of which have been widely used, but never universally accepted.

The compromise, that has been adopted almost universally, is C … Read the rest of this entry »

, , , , , ,

25 April, 2016

There is a variety of reasons why C is so widely favored as a programming language for embedded software. It is a powerful, expressive and efficient language – these are certainly attractions. But another factor is also important: availability of expertise. C is used very widely outside of embedded, so many programmers know the language. Staffing up an embedded software project should, therefore, be quite straightforward.

However, programming for embedded systems, even if it is in a familiar language, is still different from programming a desktop computer … 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.

, , ,

8 February, 2016

I recently attended a funeral, after which was a lunch. When the guests had finished eating and had begun to visit the bar less frequently, I stood up and tapped a glass with a spoon to request everyone’s attention. I explained my favorite maxim: TANSTAAFL – There Ain’t No Such Thing As A Free Lunch. For them, the price was listening to me rambling on for a few minutes.

I firmly believe that there is very little that you can get truly for free in the world, even though the cost may not always be apparent. People even expect that software might be free … Read the rest of this entry »

, ,

25 January, 2016

As any software developer is well aware, the basic process for building an embedded application is quite straightforward. Normally, the code is written in some combination of C [perhaps C++] and assembly language and distributed across a number of files [modules]. Each module is compiled/assembled to produce a relocatable object module; this file contains the machine code instructions for the target processor, but with the memory addresses left open. The numerous object modules are then joined together using a linker [sometimes called a linker/locator], which resolves the memory addresses to the required final locations and produces the absolute file, which is an image of the final system memory.

That is the simple picture. There are other nuances, like incremental linking [where a number of relocatables are joined together to make another relocatable – linking, no locating] and object module libraries … Read the rest of this entry »

, , , , , , ,

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.

, , , ,

2 November, 2015

My latest video blog, where I discuss language standardization and use of language extensions, has just been published and may can be accessed here or here:

Of course, using professional grade development tools, like Sourcery CodeBench from Mentor Embedded helps address these issues fully.

I am very interested in feedback and suggestions for future topics. Do get in touch by email, comment or via social media.

, , ,

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 »

, , ,

3 August, 2015

It is a very simplistic view, but, broadly speaking, there are two ways to design an embedded software application [or pretty much anything really]: either top-down or bottom-up. There are pros and cons of each approach and it is hard to say, in the general sense, that one is better than the other.

So much for design, but how development is approached is another matter … 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 »

, , ,

9 March, 2015

I have finally caught up and this is the last aggregation of recent articles. From now on, all being well, I’ll post to alert readers of new material being available. This time the articles cover measuring RTOS performance, the use of open source tools, memory use optimization and approaches to debugging … Read the rest of this entry »

, , , , , , , , ,

@colin_walls tweets

Follow colin_walls