Misc code questions

[jonr]

I see this in the code but I don't understand the units. How is 16384 = 500 and 9387 = 550?


#define typicalCylinderSize 16384 /* 500cc per cylinder */
#define typicalInjectorSize 9387 /* 550cc per minute */
#define densityOfOctane 22496 /* 703 grams per litre */

[Fred]

http://docs.freeems.org/doxygen-html/d7 ... tml#l00113

Those variables have different range requirements, and as such different ranges and associated scaling. Once it is UI tunable it will all be hidden anyway. I believe you've highlighted a documentation issue though, as things don't match up. I'll file an issue to sort out various doc problems later today.

EDIT, just saw this in another thread: "Another interesting thing about the EEC IV sw was that it made extensive use of fixed point fractional arithmetic." - FreeEMS is no different, hence the above.

[jonr]

Yes, I am used to seeing things like:

#define PulseWidth (500 << 8) // 500 msec bin 8

Or use macros. Losing track of the bin point is a common coding error, so it needs to be well documented.

[Fred]

Fair point! I'll add it to the list :-)

[jonr]

I wonder if bin point errors could be automatically detected. For example, adding a bin 4 number to a bin 8 number always results in garbage, but going back and looking for the definition comments (if any ) is hard. Maybe in C++. Or perhaps the name should include it "Pulse_Width_b8". Of course adding something in usec to something in msec is also an error that has to be manually detected. Unfortunately, the engine sometimes runs OK anyway and it never does get detected.

[Fred]

Have you got a link for this "bin 4" and "bin 8" terminology? I understand what it means, it's just that some of my vars are not scaled in a binary way.

Another thing that I remembered after posting that is that this stuff will all be generated from a data source file at some point in the medium term, so is kinda irrelevant. We'll document it in a formal and machine parsable (but readable) way at that point such that the tuning tool can automatically interpret and display all fields correctly regardless of offsets and scalings.

Fred.

[jonr]

Some people prefer to use base 10 scaling. For example, something might be in 1/10 msec instead of msec for more accuracy. But this is less flexible (10x is a big jump) and slower than binary scaling where you can just shift to correct.

Common code might be:

unsigned Pulse_Width; // msec, bin3 (can represent 0 to 2**13 with .125 accuracy)
unsigned Temperature = 85 << 3; // degrees C, bin3
int Something; // bin3

Pulse_Width = (Temperature * Something) >> 3; // bin3 * bin3 = bin6, correct back to bin3

I found this mind boggling when I was first exposed to it. But it worked very well (as long as you were careful). I completely agree that the tuning tool or debugger needs access to the bin point info (and units) to make any sense of the numbers.

http://cnx.org/content/m11054/latest/
http://en.wikipedia.org/wiki/Q_(number_format)

Looks like some call it "Qm.n" format. Ie, Q13.3 or Q12.3 (signed) in my example.

[Fred]

I strongly prefer to be more explicit about types and casting and overflow than the above. The other thing is, that many of these values are not manipulated in that way, they migrate through those forms into some other final form so correcting them back doesn't make sense.

Another related link that could make a good addition to code docs at some point, stored here.

http://en.wikipedia.org/wiki/Fixed-point_arithmetic

[jonr]

> I strongly prefer to be more explicit about types and casting and overflow

Do you have a code example? It would be great if a compiler could do full binary point checking and units cancellation. For example, grams per msec multiplied by msec must result in a variable that stores grams (anything else is an error).

Checking for overflow would be a useful optional debugging tool. Some MCUs have an interrupt for it.

[Fred]

Do you have a code example?

Code: Select all

unsigned short Pulse_Width; // msec, bin3 (can represent 0 to 2**13 with .125 accuracy)
unsigned short Temperature = 85 << 3; // degrees C, bin3
signed short Something; // bin3

Pulse_Width = (unsigned short) (((signed long)Temperature * Something) >> 3); // bin3 * bin3 = bin6, correct back to bin3

Which actually doesn't make sense as the value of Something could be negative and therefore you could be storing a negative 32 bit value into a positive only 16 bit value :-/ But it's crystal clear.

It would be great if a compiler could do full binary point checking and units cancellation. For example, grams per msec multiplied by msec must result in a variable that stores grams (anything else is an error).

Welcome to the modern languages that I left behind in order to start this project ;-)