I'll ponder the whole Read-CheckOverflow-ReadAgain thing later. I'm not sure it really makes a big difference. If it's off by 256usec (or 1024), it only affects a calculation at that moment, and it's not cumulative, so what are we really losing? There's a total of 11 clock cycles (< 0.7usec @16mhz) between cli & sei here.
The original recursion code was testing against 4290560000, which is 4407296 less than FFFF FFFF. That means it would recurse, except during the last 4.4 seconds of the timer's 68 minute life cycle. I tried googling around for those numbers, but was only pointed back to the mpguino code, so it doesn't appear to be an established practice.
Also, i only removed that recursion thing very, very recently, so i dont think it was preventing any freezes or resets i was having.
Remember also that if you happen to read TCNT2, it might roll over and overflow right before you read it, thus giving a false lower value. This is why it's generally better to read the value, check for overflow condition, then read again and adjust for the overflow if the overflow condition is found to exist. All this, of course, is done while interrupts are disabled.
Looking at this again, I thought cli also shuts off timers, thus preventing any undesired counter hijinks.
Looking at this again, I thought cli also shuts off timers, thus preventing any undesired counter hijinks.
Nope. cli() only disables interrupts. The timers themselves will keep on going, with all that that implies.
For instance, say you disable interrupts inside MPGuino using cli(). Timer 2 is still merrily going on its way at 1/64th of the system clock, as it was configured. During the course of your routine, timer 2 overflows. It sets the overflow flag, but since interrupts are still disabled, your routine will continue to execute without any interruption. Once interrupts are re-enabled (via sei(), or restoring the SREG from a pre-cli() state), the timer 2 overflow interrupt will now fire.
vago; where'd you get your fuel pressure from because everything i've read for every chrysler produced from 99 or earlier, on is suppost to be 49+/-5psi?
if your fuel pressure reg is actually getting 58+psi(you said 58psi over atmospheric so 72psi) you might want to replace/fix it; it might fix your problem
from a factory service manual
(4) If operating pressure is above 54.2 psi, electric
fuel pump is OK, but fuel pressure regulator is defective.
Replace fuel filter/fuel pressure regulator. Refer
to Fuel Filter/Fuel Pressure Regulator Removal/Installation
for more information.
vago; where'd you get your fuel pressure from because everything i've read for every chrysler produced from 99 or earlier, on is suppost to be 49+/-5psi?
if your fuel pressure reg is actually getting 58+psi(you said 58psi over atmospheric so 72psi) you might want to replace/fix it; it might fix your problem
from a factory service manual
(4) If operating pressure is above 54.2 psi, electric
fuel pump is OK, but fuel pressure regulator is defective.
Replace fuel filter/fuel pressure regulator. Refer
to Fuel Filter/Fuel Pressure Regulator Removal/Installation
for more information.
From page 14-2 of the 2005 LX platform Factory Service Manual:
58 psig, or 400 kPa.
Now, my truck, on the other hand, does have that 49.5 psig rating. That's good to know information - I will need to add another eeprom parameter to compensate.
Today, on my drive to work, the calculated injector correction factor was a bit off, from what I expected, leading to lower-than-correct fuel consumption readings.
However, my code was easily able to read and process MAP sensor readings for each individual fuel injector event. Given that said events can occur from once every 150 ms to once every 19 ms, this represents a very significant capability.
Equation 1 below is used to correct the fuel injector pulse length reading for a returnless fuel system-equipped vehicle, when said vehicle uses a constant-pressure fuel pressure regulator.
However, the equation for determining the pressure differential across the fuel injector,
(2) - P(diff inj) = P(fuel system) - P(intake)
has some complication associated with it. In particular, P(fuel pressure regulator) is a gauge pressure reading, while P(intake) is an absolute pressure. Or,
Where P(fuel pressure regulator) is the rated fuel pressure of my fuel pressure regulator, and p(baro) is the absolute atmospheric pressure. Thus, equation 2 above turns into:
Right now, my P(baro) estimator works by setting P(baro) to P(intake) when it senses that both the engine is turned off, and the vehicle is not moving. Ideally, this would give an accurate P(baro) right before the engine is turned on. However, in real life, this isn't always the case. The MPGuino hardware is always turned on, but the engine computer is sometimes shut off. When this happens, the power to the MAP sensor goes to 0 VDC, so the MAP sensor output itself goes to 0 VDC. This is what happened today.
I noticed that my estimated P(baro) was effectively at zero psi. This will (and did, of course) throw off the correction factor, rendering it useless for its intended purpose. Clearly, I will need to do something about that.
Now, I could recode the P(baro) estimator, but it would cause my code to grow more than it already is. As of right now, the code sits at 19640 bytes. Or, I could retain the existing code, and simply wait for a few seconds or so, after turning the ignition key to On, and before starting the engine. That would certainly give me an accurate P(baro). However, that would require that the driver wait before starting the engine every single time. Maybe the average MPGuino user would be this anal... I don't know. However, I don't want to depend on that.
Just had this thought - even if I did get an accurate P(baro) right before starting the engine, that P(baro) would only be accurate for a little while. Weather changes, elevation changes, and temperature changes all affect P(baro). My engine computer gets around this by estimating P(baro) based on throttle position, the MAP sensor, engine speed, and a lookup table. However, to implement something like that into my code would require both using the remaining analog input, and a calibration to generate a suitable lookup table. That could prove to be very challenging.
Were I to add a separate pressure sensor dedicated to solely measuring atmospheric pressure, that would certainly get rid of any costy estimation code, and any undue expectation on the part of the driver, but it would do so at the cost of using up the remaining analog input. This might not be a problem, but then again, it might be. For instance, I've read in this forum that other users saw how system voltage changes cause changes in injector reaction time, and went about coding to compensate for that. Well, that needs an analog input to be able to measure system voltage. If that input were instead used for barometric pressure, one would have to assume a more-or-less constant system voltage (which the base MPGuino code does, BTW).
Not to mention that a separate MAP sensor costs in the range of $40 or so.
I will probably end up going with adding a separate MAP sensor that is dedicated as a barometric pressure sensor. It will, of course, eat up that remaining analog input. However, it might be beneficial to members like KY Metro, who are looking to add a fuel pressure sensor due to how they operate their fuel pump. As long as the fuel pressure sensor would also read absolute pressures, this would not pose any problem with my code.
The buttons are a big waste of analog inputs. I plan to add resistors to mine, and have all 3 (plus a 4th) share a single pin.
The idea to use one pin for the buttons, it is a good idea but in other projects, this project is more difficult due to the combination of buttons, that causes the value of resistances combined, is identical in some combinations of buttons .
But try it yourself.
Today
Other popular topics in this forum...
WARNING - Novel Alert
