G
gnuarm.del...@gmail.com
Guest
I don\'t know why I thought it would be easy. The arithmetic is not so hard by itself. But changing all the equations to normalize the variables is not so easy. Then there is the issue of needing to assure the results don\'t grow out of range and I hadn\'t even given thought to the need for saturating arithmetic in some cases.
I\'m designing a fixed point math engine to do moderately simple calculations. I\'m trying to avoid a large barrel shifter, so the data format is generally Q1.17. The first problem is getting the data into that format when it generally is in a range of 0 to 167772 or less. The formulas for using the various data are calibrated for whatever the intended units are which results in changes to every coefficient and constant. It\'s a big job just mapping it all out.
The saturating arithmetic seems to be required when subtracting offsets. Most of the sensors have a built in offset that needs to be calibrated out resulting in a nominal zero result as a baseline value. With a modest amount of noise the zero wraps around. I think it is less of a problem at the high end as plenty of margin can be provided between the max values handled and the upper bound of the data format. Q1.17 provides a range of 0 to <2 and the goal will be to keep values in the range 0 to 1.0 as practical.
Anyone have advice about all this?
--
Rick C.
- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209
I\'m designing a fixed point math engine to do moderately simple calculations. I\'m trying to avoid a large barrel shifter, so the data format is generally Q1.17. The first problem is getting the data into that format when it generally is in a range of 0 to 167772 or less. The formulas for using the various data are calibrated for whatever the intended units are which results in changes to every coefficient and constant. It\'s a big job just mapping it all out.
The saturating arithmetic seems to be required when subtracting offsets. Most of the sensors have a built in offset that needs to be calibrated out resulting in a nominal zero result as a baseline value. With a modest amount of noise the zero wraps around. I think it is less of a problem at the high end as plenty of margin can be provided between the max values handled and the upper bound of the data format. Q1.17 provides a range of 0 to <2 and the goal will be to keep values in the range 0 to 1.0 as practical.
Anyone have advice about all this?
--
Rick C.
- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209