Fixed point mathematics [now with POLL please vote]

[Fred]

Just a few links I thought I would put up for discussion. I have very vaguely thought about variable types and point location for a few things, but not in too much detail, and with no thought to overflow etc.

http://www.seattlerobotics.org/encoder/ ... point.html
http://www.embedded.com/columns/1520157 ... tid=328246
http://www.allegro.cc/manual/api/fixed- ... -routines/

It may even be worth coding some fixed point functions in ASM for use inside C.

http://www.mactech.com/articles/mactech ... index.html

Just trying to clear out some of the tabs my firefox has accumulated.

Thoughts?

Fred.

[AbeFM]

No major breakthroughs, but to what extent does a good compiler take care of cleaning up this code? I hate to play both sides of the fence as I think too many people write bad code since it'll get compiled anyway, but it would be nice to write some speed tests and see if doing it yourself is actually any better.

[Fred]

Certainly, for some of the mathematics it is likely to be better. If we are careful we *may* just be able to use arbitrary fixed points of known position and a scale factor at some point to make it right etc. Those links IIRC show why you can't "just" do that in the more general case though.

[AbeFM]

As does common sense. The nice part about hardware, while it doesn't always work, it's computationally very cheap.

I think some of the data smoothing that the MS does isn't what I would do, though it may well be a product of their constraints.

[Fred]

One little idea really brought home in the last few days is the following :

For VE tables, use the 256 values not as 0 - 255, but rather as 0 - 127.5 as no ones real VE is likely to exceed that, and it will make everyone use the maximum possible resolution by default. Of course, if we go 16 bits for that, then something similar should be done.

65000 / 50 = 130 max or 65000 / 60 = 108 max or similar.

Fred.

[SleepyKeys]

Some of my cell values are 140 in order to get a really rich mixture with high boost. I'm not so sure limiting to 127 is a good idea. Though one could change a constant or two and "shift" the table making the numbers superficial............. I'll do some searching.........

[GartnerProspect]

When you say 127.5 instead of 256, do you mean that you're running 8 bit, but for the front end looking at half point VE adjustments? Just to bring the resolution up without forcing users to use arbitrary VE numbers to attain the resolution from 8 bits?

If so, I rather like the idea...

[GartnerProspect]

What I'm actually saying is that I have no idea whatsoever.

My thought on that was in order to use the full 8bit width, why not prescale on the front end... I'm probably confusing myself on the math.

But lets say, I'm running an N/A Car, which I know won't ever reach 100% VE, but for the sake of this example lets say it does.

So my VE table maxes out at 100. The tuning software asserts a scaling factor, and interpolates between points to expand the table out to the full 256 points. Loads up the cells and the scaling factor to the flash. Would this not give you a higher precision?

But this concept completely ignores all interpolation done in ecu hardware which I have no idea about how it works and what it does.

In my head, I kinda just figured it took the VE, and 100% ve meant 10.0ms + required fuel + WUE or whatever... So I think I need more background to understand.

[Fred]

You are onto it in your first post Gartner.

Basically right now you have increments of 1 and max of 255. Sean, you are a perfect example of why this is a good idea :-p Ideally that 140 should be 255 and all the other numbers larger too scaled with "req_fuel" whatever that is ;-)

My "VE" table was also high in the top end of boost, but what the numbers are displayed as doesn't matter. VE is never far from 100 (or less) and if you try to get accurate numbers in the table, you are wasting the potential resolution...

Hence if we make it default that 255 MEANS 127.5 and display it as such and understand it as such on the inside of the code, it's win win win :-)

I'd prefer 16bit numbers though, but you wouldn't want the max VE to be 65000 would you??? nope :-) you'd have to scale it. You wouldnt scale it to a value that can't be used like 255, but rather one that makes sense a bit above 100 so that people are automatically (without thinking about it) close to the ceiling always.

Maybe I'm failing to articulate myself. I'll flick someone that can probably explain it better an email and link this thread :-)

Fred.

[hassmaschine]

I think there are a few ways to use 16 bit VE values - you could either have a whole number in the VE table, and divide it by X to get the "real" VE, or you could simply add decimal places. I don't know if that much resolution is truely neccesary though - highly accurate injector PW control would be required (definitely using true PWM low-z injectors). I also don't know how much of a load a divide function requires (not a programmer!).

A simpler way (to code anyway) would be the trick I found in MS2/e - using the second VE table set to multiply. the regular VE table would be a normal 8 bit table, and you would have to tune that as closely as possible. the second table would be a trim map to fine tune with - if your multiplication factor was 400%, values of 400 would give you 0.25% resolution (1/400), even if you only had 1/10 resolution at the lowest parts of your main VE table.

Something like 0.1% resolution would be enough to really fine tune things - injector resolution would then become the biggest bottleneck. It would be better if resolution wasn't related to the actual VE number like it is in the regular MS VE table - the trick of using a second table to multiply the first one solves that, but the best I can do is 0.4% resolution (since 255 is the largest value you can have). unfortunately this requires you to tune two maps. I actually ditched this method after I discovered what multiply map really did, as I gained the same resolution (or better) without requiring two tables.

Alternatively, you could just use the raw 16 bit number - maybe have a way to display it as a "real VE" number if it was required. but having a raw number that doesn't really correlate with VE isn't a big deal (to me). I'm more interested in resolution, personally.