Sign In
Forgot Password?
Sign In | | Create Account

Share and share alike

Colin Walls

Colin Walls

Posted Mar 21, 2011
0 Comments

A constant challenge I have found, when teaching or mentoring people, is to avoid making assumptions about what they know. I have found that it is so easy to assume that, because something is obvious to me, it is clearly apparent to everyone else. On numerous occasions I have discovered that this not to be the case. Of course, the best response to this realization is not to treat everyone else as stupid, but try to explain something clearly and then listen to the echo back of the explanation.

In developing software – embedded software in particular – there are certain things that are fundamental, particularly around the conservation of resources. More than once I have been surprised by engineers’ inability to focus on this issue …

Many years ago, I was supervising an inexperienced engineer, who was developing the software for a simple telecommunications device. I do not recall all the details, but broadly it managed two separate flows of data. The code was written in assembly language – that is what we did in those days. She had a problem. Although the basic functionality of the device was in place, she still needed to add some more features and was running out of program memory [ROM]. She sought my help. I was surprised by the problem, as the software did not need to be particularly complex and, by the standards of the day, the available memory seemed to be more than enough.

I looked at the code and quickly saw the problem. She had written code to deal with one communications channel [a UART driver] and then made a second copy of the code to handle the other channel. Nobody had ever explained the idea of shared code to her. All that was required was to ensure that the code was reentrant – i.e. all data was directly or indirectly stored in registers or on the stack – and a single copy would suffice. We both learned a lesson that day. The engineer learned about how shared code worked and I learned that it was not obvious to everyone.

Much more recently, I was involved in the technical support of a customer, who exhibited a similar sounding problem. This time, the code was much more complex and written in C. The device was handling ten channels of data. He wanted to enhance the code and had run out of memory. We gave some advice about compiler optimizations, which helped, but not enough. A more detailed look at the code and a few tweaks and we reduced the code’s memory footprint by nearly 90%. I imagine you can guess what happened. He had 10 copies of the same code, which we could reduce to a single one. Of course, ensuring the C code was reentrant was very straightforward, just requiring the absence of statically stored data.

However, we also caused a problem for this customer. Prior to our “fix”, he found debugging was easy: just a matter of putting a breakpoint on the code for a relevant channel. Now, the shared code would stop on a breakpoint, but it would do it for whatever channel happened to use the code next, which was a little confusing. We demonstrated a debugger which could provide task-aware breakpoints and the problem was solved. He was very happy to buy the tool after the spectacular solution to his problem that we provided. It was a win for all concerned.

Development Tools

More Blog Posts

About Colin Walls Follow on Twitter

Colin WallsI have over twenty-five 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, I am a member of the marketing team of the Mentor Graphics Embedded Systems Division, and am based in the UK. Away from work, I have a wide range of interests including photography and trying to point my two daughters in the right direction in life. Learn more about Colin, including his go-to karaoke song and the best parts of being British: http://go.mentor.com/3_acv Visit The Colin Walls Blog

More Posts by Colin Walls

Comments

No one has commented yet on this post. Be the first to comment below.

Add Your Comment

Please complete the following information to comment or sign in.

(Your email will not be published)

Archives

Tags

 
Online Chat