Is there a typo in the header file? The range for the 11-21 fixed point numbers looks too low (specified as 0-127.99).
/***************
*
* Range 0-127.998046875
* Granularity 0.001953125
*
***************/
typedef union FIXED11_21tag{
S32 full;
struct part11_21tag{
U32 fraction: 21;
S32 integer: 11;
}part;
}FIXED11_21;

Very nice. I like it a lot. Fixed point math in C is certainly something which is needed. It'd be nice if it was native to the language.
I currently use a different method, which is to define a constant multiplier for each value. E.g. if you have a variable which you want to express the range of 0 to 100 with granularity of 0.1, you can simply use a multiplier of 10 (so a raw reading of 476 is actually 47.6).
Another advantage of this method is during debugging. If you do a memory dump, or can monitor RAM during emulation, simply read the value (e.g. raw percentage = 476), and in you head, insert the decimal place (real percentage = 47.6%).
Of course, if you want traditional fixed point, like 3 bit integer, 5 bits fractional, simply define the MULT_ value to (1 << 5)
I've done all of these examples using 16 bit values, because they're what I use most. There's enough precision for most values (it's more accurate that many sensors and A->D converters).
Examples of use:
#define MULT_0DP 1 //gives 0 decimal places
#define MULT_1DP 10
#define MULT_2DP 100
#define MULT_3DP 1000 //gives 3 decimal places
To do compare a variable to a constant:
#define MULT_PERCENTAGE MULT_1DP
uint16_t percentage = 15 * MULT_PERCENTAGE;
if(precentage < 10 * MULT_PERCENTAGE) ...
To compare two variables:
if((int32_t) a * MULT_B > (int32_t) b * MULT_A) ...
//as done here, you usually need to typecast to a higher type to do these comparisons.
To do multiplication:
#define multiply_s16_s16(a, mult_a, b, mult_b, mult_result) ((mult_result == mult_a * mult_b) ? a * b : (((int32_t) mult_result * a) * ((int32_t) mult_result * b)) / (mult_a * mult_b)))
//If MULT_A * MULT_B is a nice binary number, the division can be done by shifting, which can be faster. If MULT_RESULT is a nice binary number, the multiplications by mult_result can also be shifting.
Or, if you know that MULT_RESULT == (MULT_A * MULT_B), you can simply do "result = a * b;" - though this becomes wrong if one of the MULT_ values is changed.
To do addition:
If all MULT_ values are equal (i.e. (MULT_RESULT == MULT_A) && (MULT_RESULT == MULT_B)),
you can do normal addition/subtraction (e.g. "result = a + b;").
Otherwise, the following macro should work:
#define add_s16_s16(a, mult_a, b, mult_b, mult_result) ((mult_result == mult_a && mult_result == mult_b) ? a + b : (((int32_t)MULT_RESULT * a) / MULT_A + ((int32_t)MULT_RESULT * b) / MULT_B))
//if the MULT_ values are nice binary numbers (e.g. 128), the multiplications and divisions will be done by binary shifting, which is often faster.
Of course, subtraction is simply:
#define subtract_s16_s16(a, mult_a, b, mult_b, mult_result) add_s16_s16(a, mult_a, -b, mult_b, mult_result)
Notice that if you use traditional fixed point methodology (i.e. a number of bits is reserved for the fractional component), or the MULT_ values are chosen appropriately, the maths can be quite fast.
I suppose one downside is having to keep track of the MULT_ values, but I don't find it problematic, since I don't use "MULT_..." for any other variable or macro names. I also name the MULT_ after the variable in question.
Anyway, I'm interested to hear what people think.
Cheers,
Tev

CONGRATULATIONS!
You have re-invented my old friend the BINARY-FLOAT numeric data type of the PL/I programming language.
PL/I was developed by IBM as a commercial and scientific programming language and start to be used in the earlies 1960's.
In Spain was very common as business programming language on several banks, insurance companies, public adm. institutions on the 1970's
Today is still used as the main programming language in the "La Caixa" (www.lacaixa.es), the 2nd bank in spain, and supports transactions from the backend to a lot of channels through a multichannel SOA architecture.
I personally have used Binary Float data types for internal computing in several transactions instead of the common DECIMAL FLOAT (equal to float data type in C), due to its less CPU use.
Greetings from Barcelona
Alex G.

Autonomous vehicles on our roads soon? What could go wrong with that? Listen in as EE Times' Junko Yoshida asks industry experts what the intended and unintended consequences will be.

To save this item to your list of favorite EE Times content so you can find it later in your Profile page, click the "Save It" button next to the item.

If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.