A different way to target boost by gear

[rabid]

I have an idea that I want to try and I need help from programmers. Currently there is the option to target a boost level per gear if the tps is over an amount. My thought was to rescale the tps value up to an amount per each gear. For example. In 1st gear you could put 50% and then if your throttle position was at 100 the table would target along the 50% throttle line. If throttle position was at half then it would target along the 25% line. I would like to test my idea but I'm running into an issue.

This is the current code when the throttle is over the set point.

Code: Select all

targ_load = ram5.boost_geartarg[tmp_gear];

I am testing this code.

Code: Select all

int tps_target, rescaled_tps;
tps_target = ram5.boost_geartarg[tmp_gear];
rescaled_tps = outpc.tps*tps_target/100;
targ_load = intrp_2ditable(outpc.rpm, rescaled_tps, 8, ect ect ect);

If I get it working, I can clean up the code to avoid using extra variables but for now my issue is with outpc.tps. Normally the function intrp_2ditable is called by putting outpc.tps directly into it. I'm trying to rescale it by using the value from the boost_geartarg array. That actually works. I confirmed that by replacing outpc.tps with a value such as 50.

As it is, I'm getting wildly fluctuating values when I try to rescale outpc.tps. Can anyone give me any insight into this? I'm guessing it is a signed integer value from which is 0 at the low calibration and 1000 at the high calibation?

[jsmcortina]

Almost certainly a maths overflow. Try this.

Code: Select all

rescaled_tps =  ( (long) outpc.tps*tps_target) /1000L;

When you multiply two 16bit numbers together they frequently need 32bits of space.
on this chip/compiler the (long) casts one of the numbers to signed 32 bit before the multiplication. The scale of most variables is in units of 0.1 so we need to divide by 1000 in integer maths. The L specifies this number as a 'long' also, possibly redundant due to the cast.

James

[rabid]

Thank you James!

I was researching overflow and was trying to figure out if it was the case. I knew it would overflow over over 32767 but my testing seemed to overflow at very low number multiplication so I was even more confused. But logging is slow and not helping me debug well at this level. I am still learning c++ and megasquirt is giving me a reason to learn.

[jsmcortina]

We always use braces in the code to force the calculation order to prevent overflow or mistaken rounding.

Note that the code is in C and S12X assembler, there is no C++.

James

[Reverant]

Note that the code is in C and S12X assembler, there is no C++.

James

Some C++ programmers (myself included) often like to use a subset of C++, commonly referred to as (C++)--.

Dimitris

[jsmcortina]

Some C++ programmers (myself included) often like to use a subset of C++, commonly referred to as (C++)--.
Dimitris

No doubt you do, but are they supported in the version of gcc we use with S12X ?

James

[rabid]

Almost certainly a maths overflow. Try this.

Code: Select all

rescaled_tps =  ( (long) outpc.tps*tps_target) /1000L;

James

A quick test shows that this works. I will need to see how this works out for driving.

[rabid]

Some C++ programmers (myself included) often like to use a subset of C++, commonly referred to as (C++)--.

Dimitris

I will bite. Sooooo C+1-1 or just C programming.

[rabid]

So far, this is working well.
I confirmed that this line of code works.

Code: Select all

			int rescaled_tps =  ( (long) outpc.tps * ram5.boost_geartarg[tmp_gear]) /1000;

Screenshot 2015-03-07 13.48.58.png

[93supercoupe]

Can we have an optional Boost By Duty Cycle table?

[muythaibxr]

Can we have an optional Boost By Duty Cycle table?

Do you mean the open loop boost feature we've had for ages?

Ken

[piledriver]

Can we have an optional Boost By Duty Cycle table?

Do you mean the open loop boost feature we've had for ages?

Ken

...In his defense there are a LOT of features now. its easy to miss a few...