Posts Tagged ‘debugging’

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 »

, , , , ,

18 July, 2016

An embedded system is normally a CPU [or some CPUs] interfaced to a number of peripheral devices. The software processes data and controls the peripherals. In summary, that is what embedded systems are all about. But, of course, there are many other details and that is what occupies embedded software developers most of the time. A significant issue is around peripherals and timing … Read the rest of this entry »

, , , ,

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 »

, , , , , , , , ,

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.

, , , ,

4 May, 2015

A while ago, I concluded that it might be useful to highlight the publication of online articles, that I had written, here. So, I made a series of postings to catch up, listing articles that have appeared regularly on embedded.com over the past couple of years. That catch-up process is now complete and I can now provide a notification as and when publications occur … 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 »

, , , , , , , , ,

21 July, 2014

Multicore continues to be a hot topic, as an ever-increasing number of embedded systems are designed with multiple CPUs – most commonly multiple cores on a chip. One of the challenges with understanding multicore is that the term actually covers a number of architectures and approaches to design. This is a topic that I have discussed somewhat before, but the increasing popularity of multicore and additional technology options make it a topic worth revisiting.

Figuring out the terminology is the first challenge … Read the rest of this entry »

, , , , , , , , , ,

3 June, 2013

I recently posted about using printf() for debugging – or, rather, I suggested a few good alternatives, which make more sense to embedded developers. Most debugging/tracing technologies involve adding some code to the target system, which might make some developers uncomfortable. Surely the code being debugged is no longer the same as you plan to ship?

Broadly speaking, this is really a manifestation of what physicists call the Observer Effect. This effect refers to changes in a system that are caused by attempts to make measurements. This effect can be mitigated in various ways, but there is the possibility of eliminating intrusiveness all together … Read the rest of this entry »

, , , , ,

7 May, 2013

It has always seemed obvious to me that a particular characteristic that makes embedded software different from desktop programming is the close relationship with hardware. As most embedded devices are custom designs, the hardware platform is something of an unknown. So, it is clear that the development of the hardware and software should be done in a cooperative fashion.

Mentor Graphics is unique among the major electronic design automation [EDA] companies in having made a great investment in embedded software development, which is manifest in the Embedded Software Division, a.k.a. Mentor Embedded. On the other hand, Mentor Embedded is unique among embedded software tools/RTOS vendors by being part of a large company involved in hardware design. In any case, we should be in a great position to bridge the gap … Read the rest of this entry »

, , ,

19 December, 2011

Last week I wrote about a test harness for applications using an RTOS. The idea was to have a library of functions corresponding to the API calls of a particular RTOS. Specific tasks of an application, that are under test, would be linked to this library to enable the code to be executed on a desktop computer in a useful way.

I had some feedback on this posting from a couple of people, talking about RTOS simulation on a host computer … Read the rest of this entry »

, , , , , ,

12 December, 2011

I was talking about OS-aware debuggers and someone asked me whether I could suggest a technique for unit testing of code for a multi-threaded application. It took me a while before I could fully understand what they were after, but it did become clear eventually. They were considering an environment where a number of engineers were working on an embedded application [using Nucleus]. Each guy was developing one or more tasks, which interact with one another and those written by other engineers. My questioner was wondering how these engineers could make some solid progress with testing and debugging ahead of building the complete system … Read the rest of this entry »

, , , , , ,

7 November, 2011

If you met someone in a bar, say, and you got talking, they are likely to ask what you do. You will probably reply that you are an embedded software developer. [Actually, in my experience, this can be a bit of a conversation killer. You might be better saying you are an airline pilot or a brain surgeon.] If they carry on talking with you, they might ask you what that job entails and you would probably answer with something about designing software and writing C/C++ code. Of course, that is not really the case. 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 … Read the rest of this entry »

, , ,

22 August, 2011

Embedded software development tools are important to all developers and a topic that I frequently discuss [like here]. The way such tools are described by vendors is interesting. For example, there might be a reference to an “optimizing compiler”. That is rather meaningless, as all compilers are optimizing to at least some degree. For an embedded compiler, the important factors are the quality of optimization and, more importantly, the degree of control that the user can apply.

Another interesting terminological issue is applied to debuggers and trace tools. They are commonly referred to as “non-intrusive” … Read the rest of this entry »

, , , , , , ,

@colin_walls tweets

Follow colin_walls