A Significant Bit of Advice - Embedded.com

A Significant Bit of Advice

A Significant Bit of Advice

Many thanks to Christopher Leddy for his excellent article, “Software-Friendly Hardware” in the September 2001 issue (p. 69). I hope the many hardware designers out there were paying attention.

I would like to offer an exception to his rule of thumb that numeric fields should be placed in the least significant bits (LSBs) of a register. If the numeric value represents a proportion of a range that is inherently limited, I suggest placing the field in the most significant bits of the register instead.

Consider a 12-bit signed number that represents the angle of rotation of a shaft: -180 to +180 degrees. Instead of sign-extending the value to fill the unused MSBs, we place the value itself in the MSBs and make the unused LSBs zero. If the resolution of the value ever needs to be increased, say from 12 bits to 14 bits, the added bits will replace two of the zero-padding bits, but calculations using the value will not have to be re-scaled to account for the added resolution. In many cases, the code can be written to use the full resolution of the register with no speed or size penalty, eliminating the need to update the software if the resolution changes with a future hardware revision. Calculations such as incrementing the angle may also be simplified because they will automatically “roll over” in the processor registers at the correct value.

The same principle applies when connecting analog-to-digital and digital-to-analog converters to a parallel bus (their range is limited by the minimum and maximum voltages they can read/output). Note that any bits not driven by the ADC will not necessarily read zero, but will float. Even if the software

doesn't mask off those bits, however, the total error they can cause will be less than a change in the LSB that is connected to the ADC.

Steve Strobel

Chris Leddy responds:

The proposed alternative can be very useful in certain situations, but it must be evaluated with regard to its impact on the system's numeric calculations. Use of the MSBs for numeric quantities may require the software to add scaling, shifting, or even variable type conversion code to the calculations that would not be present when using the LSBs. Fixed-point calculations within the native data type may also overflow, if not carefully ordered when evaluated.

Using MSBs for numerics does provide an interesting alternative, and is worth considering if the numeric impact to the system can be properly assessed. I will add it to my own personal “bag of tricks” for use on future projects.

eXtreme danger?

O ne thing that bothers me about eXtreme Programming, which Jack Ganssle wrote about in his December 2001 column (p. 75), is a lack of verification except by means of testing and over-the-shoulder audits by a partner. When we build safety-critical systems, we often have to resort to formal specifications and formal program verification to ensure the highest possible integrity and reliability.

Safety-critical environments are no place for extreme programming. If we can re-factor on a whim, what happens to our formal proof? We have to re-prove the function each time we re-factor it, or we have lost our integrity. Testing alone doesn't guarantee correctness; in safety-critical systems, this is a serious issue.

Another thing that bothers me is the lack of documentation. When developing a commercial product from a specification, technical writers can be writing the user's manual from the specs and design documents while the code is being written, allowing a parallel effort. In eXtreme programming, there are no written specs: the customer communicates them by word of mouth, and documentation is mentioned only in passing. If each iteration produces a new product, the documenters would be rewriting their manuals with each one. Parallel effort goes out the window and the final delivery might be slowed.

Another problem is defining requirements. How can you enter a legal contract with a customer when the product definition and schedule are foggy? What final acceptance test is specified in the initial contract when the requirements are unknown? How can costs or price be estimated and agreed upon? How are contract disputes resolved?

The big question is whether or not the consumer will be willing to use a heart pacemaker or anti-lock braking system that was eXtreme programmed. I don't know that I would.

Steve Hanka

What's on your mind?

Embedded Systems Programming welcomes feedback. Please send any comments to editor-in-chief Michael Barr at . By submitting a letter, the writer grants publishing rights to the submitted material in all media. Letters may be edited for clarity and length.

Return to the March 2002 Table of Contents

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.