Archive for November, 2006

Help! My third party source code doesn’t comply with my coding standards

Friday, November 24th, 2006 Nigel Jones

Two big trends in the embedded world are on a collision course – and the resolution isn’t going to be easy. The two trends are the requirements that all code meet internal coding standards and the use of third party code.

Organizations have been gradually been getting religion about having and enforcing coding standards. As well as spelling out what the source code should look like, and making rules for what is kosher, many internal standards now also require code to be ‘Lint free’, and also possibly that it conform to various standards, such as those laid down by MISRA.

Simultaneously, organizations have been striving to improve productivity. One way of doing this is to turn to code re-use. Code re-use is normally discussed in the context of code that you’ve already developed being re-used in subsequent projects. However, a far more powerful paradigm is to use code that others have developed. Need a CRC algorithm, or a way of computing a MD5 hash – head to the Internet to find your source code. Have a need to develop a complex state handler – hello visualSTATE. Need to develop a GUI – take your pick from a plethora of component suppliers. Now if you were developing for a PC, most of this code would be supplied in binary format. However with the plethora of embedded targets and compilers, the chances are you’ll get source code that you’ll need to compile.

Now, the chances of the source code matching your coding standards should be nil. So what is to be done? My experiences to date have been pragmatic – but not pretty.

For small pieces of code, I simply rewrite them to bring them up to standard.
For third party libraries, such as a graphics library, it is usually impractical, if not illegal, to modify the source code, and so one is forced to accept the code as is.
For machine generated code, even if it’s small, rewriting the code is pointless, since the chances are you’ll be regenerating it later and over-writing your work. Thus, once again, one is forced to accept the code as is.

So what is to be done? At present, my coding standards procedure allows one to issue a variance where code doesn’t comply (in pretty much the same way that MISRA allows variances to be issued). Although this is OK, let’s recognize it for what it is – a cop out. What we really need are the suppliers of source code to recognize and adhere to various ‘standards’. For example:

1. Use the C99 data types folks. I’m tired of seeing UINT8 definitions everywhere when ISO has stipulated that a uint8_t data type is an 8 bit unsigned type.
2. Make your code Lint free. If you’re selling source code, it’s in your interest to make it as clean as possible. PC-Lint from Gimpel is the gold standard, so make sure you can pass it with a clean bill of health (and I don’t mean by suppressing every complaint it has).
3. Make your code MISRA compliant. MISRA can be a pain – but their intentions are good. If nothing else, making your code MISRA compliant will increase the size of your target market. This issue has been recognized by IAR to whom I’d like to congratulate for making the code generated by the upcoming new release of visualSTATE MISRA compliant.

What if you are just an honest Joe, just putting code out there for all to use and enjoy? Well why not adhere to the same rules? It’ll make your code more useful – and after all isn’t that the point of publishing it in the first place?

Home

Unexpected uses and the consequences thereof

Friday, November 3rd, 2006 Nigel Jones

I’ll pose today’s blog in the form of one of those lateral thinking questions – which you may want to try and solve before moving on to the rest of the post.

An engineer walks into a meeting, unpacks his laptop and an Ethernet hub, powers both up and then connects an Ethernet cable between the laptop and the hub. No other connections are made to the hub. Explain.

Well I suppose two obvious answers are that the engineer is nuts (likely), or that the engineer doesn’t understand the basics of Ethernet technology (less likely). Of course, in this case, the engineer is me, and while I can’t really attest to my mental state, I do know a thing or two about Ethernet. So what is causing this strange behaviour?

Well, like many engineers, I use some very expensive software. The vendors of this software, in an effort to protect their product from unpaid copying, lock the software to the computer’s NIC. (For the uninitiated, every Ethernet interface IC on the planet has a unique MAC address. Thus any computer with a NIC has a built in unique identifier). Now the vendor of my laptop (Toshiba), in a sensible effort to conserve power, powers down the NIC when it detects no valid signal on the Ethernet port. When the NIC is powered down, it can’t respond to requests for its MAC address, and so the copy protection scheme complains and I can’t run my expensive software.

Who is to blame here? I can’t really fault the SW vendor for wanting to protect their investment, and I can’t blame Toshiba for wanting to minimize the power consumption of their product. I suppose it would be nice if Toshiba provided a utility to prevent the auto power down – but that’s probably inconsistent with them trying to make the system easy to use for the average consumer. I think the answer is that the fault lies with us in the engineering community. We value great tools, but apparently enough of us (and our employers) are dishonest enough that we’ll copy them if we get the chance. Apparently part of the price we pay for this is looking like idiots when we walk into meetings…

Home