Breaking News
Blog

Fixed-point math in C

Joe Lemieux
10/7/2003 04:00 PM EDT

 4 comments   post a comment
NO RATINGS
View Comments: Newest First | Oldest First | Threaded View
gbmhunter
User Rank
Author
re: Fixed-point math in C
gbmhunter   10/12/2012 3:00:37 AM
NO RATINGS
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;

abdul529
User Rank
Author
re: Fixed-point math in C
abdul529   7/6/2011 12:18:54 PM
NO RATINGS
Good article

tevvybear
User Rank
Author
re: Fixed-point math in C
tevvybear   8/14/2009 3:02:26 AM
NO RATINGS
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

rocral
User Rank
Author
re: Fixed-point math in C
rocral   11/28/2008 11:09:55 AM
NO RATINGS
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.

Most Recent Comments
michigan0
 
SteveHarris0
 
realjjj
 
SteveHarris0
 
SteveHarris0
 
VicVat
 
Les_Slater
 
SSDWEM
 
witeken
Most Recent Messages
9/25/2016
4:48:30 PM
michigan0 Sang Kim First, 28nm bulk is in volume manufacturing for several years by the major semiconductor companies but not 28nm FDSOI today yet. Why not? Simply because unlike 28nm bulk the LDD(Lightly Doped Drain) to minimize hot carrier generation can't be implemented in 28nm FDSOI. Furthermore, hot carrier reliability becomes worse with scaling, That is the major reason why 28nm FDSOI is not manufacturable today and will not be. Second, how can you suppress the leakage currents from such ultra short 7nm due to the short channel effects? How thin SOI thickness is required to prevent punch-through of un-dopped 7nm FDSOI? Possibly less than 4nm. Depositing such an ultra thin film less then 4nm filum uniformly and reliably over 12" wafers at the manufacturing line is extremely difficult or not even manufacturable. If not manufacturable, the 7nm FDSOI debate is over!Third, what happens when hot carriers are generated near the drain at normal operation of 7nm FDSOI? Electrons go to the positively biased drain with no harm but where the holes to go? The holes can't go to the substrate because of the thin BOX layer. Some holes may become trapped at the BOX layer causing Vt shift. However, the vast majority of holes drift through the the un-dopped SOI channel toward the N+Source,...

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
Like Us on Facebook
EE Times on Twitter
EE Times Twitter Feed