Archive for December, 2008

So you want to be a consultant…

Saturday, December 20th, 2008 Nigel Jones

In the lede to this blog, I stated that I’d from time to time be commenting on the trials and tribulations of being a consultant in the embedded systems world. Well, today is my first post on this topic, so I thought I’d address the question I get asked most of the time ‘How do you market your business’?

Well, the trite answer is that in general I don’t! The bulk of my work comes from repeat clients. I have one client that I’ve been doing work for for nearly twenty years, another for about seventeen years, and a third for nearly ten years. In short, I’m a very big believer in keeping my existing clients rather than developing new ones all the time. Obviously this isn’t very helpful for someone that is thinking about striking out on their own and is wondering how to sign up a client or three.

My main suggestion if this describes you, is to approach previous employers / managers. If you are really good (and it helps a lot if you are) then previous managers will be extremely interested to hear that you are available for consulting work. Why do I say this? Well look at it from their perspective – here is a talented person that knows their products / procedures / tools who is available to come in and help out in overloaded situations. Thus the next time senior management is demanding that something gets done faster, it’s an easy sell for your ex-manager to suggest bringing you in to help meet the deadline.

Incidentally, this especially applies to companies that have just had layoffs (even if you were one of those that got cut). When companies have a layoff, they typically overdo it. As a result, important projects grind to a halt and only get moving again when more help is brought in. Now typically for political / legal reasons a company cannot layoff people and then hire different ones. It can however hire ‘temporary help’ – and that’s where you the consultant come in. Thus if you have just been laid off and think it’s time to strike out on your own, I strongly suggest that the first person you call to offer your services is the person that laid you off.

Incidentally, I cannot stress enough the importance of face – face or at least voice – voice contact. Sending a card or an email will almost certainly result in the approach going no where. If the thought of ‘warm calling’ makes you break out in a sweat, then the chances are you just aren’t cut out for having your own business.

What about other techniques such as advertising? I have never gone this route but I know people that have with some success. Be warned however that advertising can be expensive and can be too successful. I say this because the only thing worse than not having enough work is having too much!

How important is a good website? Well I used to think it was largely irrelevant (and my website reflects this attitude. I’ve been promising myself for a year to get it updated). However, I know of several cases where it has been extremely important in bringing in new business. I would caution you though that spending your time and money on a website is no substitute for making the telephone calls.

What about the social networking sites, such as ‘Linked In’ or ‘Plaxo’? These can be helpful if you want to track down all those folks you used to work with who might want to hire you. They are easy to use and low cost / free. Incidentally, don’t feel awkward about contacting someone you have lost touch with. Although it might be a little strange socially, it’s well worth it to both of you if a fruitful business relationship develops.

Finally, what about the myriad of technical recruiting agencies out there? I have never done any work through them. I have interacted with them, and have found a huge variability in their ethics. Personally, I’d avoid the big companies (which are nothing but key word matchers) and work with the smaller, one man companies. Notwithstanding this, if you’re relying on these folks to bring you work then you are being passive rather than proactive. Not recommended!

Next time I post on consulting, I’ll address some other important issues. But for now, just remember that a consultant without clients is like a (fill in your own analogy here). Thus the first step in becoming a consultant is getting a client. Only then is the other stuff important.

Follow up to my last post

Thank you to all of you that encouraged others to come and read this blog. I saw a very nice uptick in my readership last week for which I am most grateful.

Home

Posted in Consulting | 2 Comments »

Efficient C Tips #5 – Make ‘local’ functions ‘static’

Saturday, December 13th, 2008 Nigel Jones

In my humble opinion, one of the biggest mistakes the designers of the ‘C’ language made, was to make the scope of all functions global by default. In other words, whenever you write a function in ‘C’, by default any other function in the entire application may call it. To prevent this from happening, you can declare a function as static, thus limiting its scope to typically the module it resides in. Thus a typical declaration looks like this:

static void function_foo(int a)
{
}

Now I’d like to think that the benefits of doing this to code stability are so obvious that everyone would do it as a matter of course. Alas, my experience is that those of us that do this are in a minority. Thus in an effort to persuade more of you to do this, I’d like to give you another reason – it can lead to much more efficient code. To illustrate how this comes about, let’s consider a module called adc.c This module contains a number of public functions (i.e. functions designed to be called by the outside world), together with a number of functions that are intended to be called only by functions within adc.c. Our module might look something like this:

void adc_Process(void)
{
 ...
 fna();
 ...
 fnb(3);
}
...
void fna(void)
{
  ...
}

void fnb(uint8_t foo)
{
 ...
}

At compile time, the compiler will treat fna() and fnb() like any other function. Furthermore, the linker may link them ‘miles’ away from adc_Process(). However, if you declare fna() and fnb() as ‘static’, then something magical happens. The code would now look like this:

static void fna(void);
static void fnb(uint8_t foo);

void adc_Process(void)
{
 ...
 fna();
 ...
 fnb(3);
}

...

static void fna(void)
{
 ...
}

static void fnb(uint8_t foo)
{
 ...
}

In this case, the compiler will know all the possible callers of fna() and fnb(). With this information to hand, the compiler / linker will potentially do all of the following:

  • Inline the functions, thus avoiding the overhead of a function call.
  • Locate the static functions close to the callers such that a ‘short’ call or jump may be performed rather than a ‘long’ call or jump.
  • Look at registers used by the local functions and thus only stack the required scratch registers rather than stacking all of the registers required by the compiler’s calling convention

Together these can add up to a significant reduction in code size and a commensurate increase in execution speed.

Thus making all non public functions not only makes for better code quality, it also leads to more compact and faster code. A true win-win situation! Thus if you are not already doing this religiously, I suggest you go through your code and do it now. I guarantee you’ll be very pleased with the results.

Next Tip
Previous Tip

A Request …

If I’m to believe the statistics for this blog, it appears that I’m gradually building a decent sized readership. Furthermore many of you choose to come back and read the latest postings which tells me that I’m doing something of value. Anyway, if this describes you, I’d be obliged if you’d encourage your colleagues to read the blog and also to post comments / questions. Why do I ask this? Well, an increased readership has several benefits, for both me and you the readers.

  • I believe quite passionately about improving the quality of embedded systems. Those of us that are working in this field collectively have an enormous impact on the world. Thus anything that helps improve the quality of embedded systems in turn helps improve the world. (I appreciate that this is a little melodramatic. It is, however, true).
  • Writing about something is the best way to I know to find out if I truly understand it. Thus, the very act of publishing a blog causes me to improve my skills and knowledge.
  • Some of the (too few) comments I get are quite profound and often instructive. Thus I also learn in this way.
  • The bigger the readership I have, the more inclined I am to publish. If I’m publishing things of value, then presumably the readers benefit.

Anyway, if you concur, then please encourage your colleagues. If you don’t, then that’s OK as well.

Thanks for reading.

Home

Tags:
Posted in Efficient C/C++ | 42 Comments »

Knowing my weaknesses

Saturday, December 6th, 2008 Nigel Jones

A few weeks ago I published what appears to have been quite a popular blog on what I called the ‘Bug Cluster Phenomenon’. Today, I’m going to extend that concept somewhat by way of a mea culpa.

Earlier this week I had to eat some very humble pie. For the last six weeks or so I had received complaints that a temperature measurement wasn’t giving accurate results. The sensor in question is measuring approximately ambient temperature, and was returning values in the 18 – 26 Celsius range, which seemed reasonable to me. I just wrote off the complaints as being due to the fact that humans have a very poor perception of absolute temperature. Well finally, at my urging, someone dragged the device out into the Winter cold, where it promptly read 18 Celsius. Thus I was faced with proof that something was wrong.

I proceeded to investigate the code, and discovered that based on the current inputs to the code, the code was generating an output with an error of about 2 degrees. How was this possible, since it was nothing more than a series of multiplies, adds and shifts – not typically fodder for a 2 degree error?

Well, further investigation showed that at a certain point I was getting numeric overflow when two numbers were being multiplied together. Now typically, when this occurs, one gets answers that have huge ‘errors’. In my case I had the misfortune that the arithmetic worked out such that the error at room temperature was barely noticeable.

Anyway, I duly fixed the code. However, before moving on I took the time to reflect on this particular bug. Was this just one of those stupid coding errors that we all make from time to time, or was there more to it? I came to the conclusion that this was not just “one of those things”. Rather I realized that this was at least the third time this year that I had written code that suffered from a numeric overflow problem. In short, I have a problem or a blind spot if you will, for a particular class of problem.

Well I’m told that recognizing ones problems is the first step in solving them. So I proceeded to do a little bit more investigating and discovered that my numeric overflow bugs always occurred when I combined multiple operators on a line. For example:

y = a * a + c;

Thus the solution seems obvious to me – only one numeric operator per line. Thus in future, I will always code like this:

y = a * a;
y += c;

The bottom line. When you encounter a bug, as well as looking for other bugs nearby (as described in the bug cluster phenomenon post), also take the time to reflect on what caused the bug in the first place, and see if you can recognize any systemic problems in your approach to coding. When it comes down to it, this is nothing more than a process of ‘continuous quality improvement’. If it works for Toyota then it might just work in the embedded systems arena.

Home

Posted in Coding Standards, General C issues | 4 Comments »