Fuel Injection - Evolution Journey

This is a fully automotive powertrain article.
Disclaimer: I am a novice in this area. If experts read this kindly correct...

Q: Why & How did FI ( Fuel Injection) systems evolve?
For a long time carburetor based engines dominated the automotive world. The were good and could make your car run smoothly. However, increasing emission norms & better systems being used by the air planes eventually led to their extinction  in the four-wheeler world ( Though my XCD-135 bike still uses a carburetor for managing the air-fuel mixture). The major things that led to the death of carburetor engines are :

• Too many compensations where needed making the design look like spaghetti code. The were compensations for idling, for cold start among other things.
• Carburetor icing had plagued high altitude flying machines, this led to development of what we today know as EFI systems ( Electronic Fuel Injection). They started off as SPFI  (Single Point Fuel Injection) & then evolved into MPFI ( Multi Point Fuel Injection)

With the new FI systems it was necessary to have electronics to control the fuel injection. This was done by having solenoid controlled fuel injectors. These injectors could be actuated by providing what is generally called the "Fuel Pulse" and the timing & the duration (pulse width) of the pulse could control the amount of fuel sprayed into the manifold. The Advantages of  the new Fuel Injection system ( Now of course its quite old) were :

• Better efficiency due to the fact that the fuel-air mixture could be made LEAN or RICH ( not fat for god sake !!).
  
• No carburetor icing wherever it was applicable. Just in case you are wondering what is Carburetor icing, it is the basically formation of ice in the carb's venturi due to condensation of humid cold air (due to further drop in the venturi). This is often accompanied re-conversion of the fuel from its atomized format to more liquid format.
• EFI systems will also help in reduction of NOx emissions due to which it is better complaince with emission norms is possible.  

The story is more compilicated than what has happened so far because soon a need was felt to control the ignition, Cams, valves and what not. There was also emergence of the EGR concept ( which was present even the carb engine days). The compensations & corrections that were needed to the various parameters based on vehicle parameters like Engine RPM, AC ( air conditioning), vehicle speed  ABS etc has transformed the electronic control systems into a work of art.
In the next post on this topic, I will be going into the various systems that influence a engine & how the EMS ( Engine management system) handles them.
more on....
carb icing
EFI


Please leave your comment if you have one. You can subscribe to this blog by using the links under "Subscribe" section.

Powered by ScribeFire.

When Size does matter - Coding Myth 1

Again i am slow in updating this blog and this time it is really because I was busy with some GUI building activity on Matlab. I will write more about in another post. However, today the topic is more about "C" coding myths.

Some dudes I have met write really write complicated code like the one below stating that it will be more efficient. Some how they seem to feel that compact code ( in terms of number of lines & characters used) translates directly into lesser code volume in the microcontroller. I just tried this....

Code:

unsigned char alt2(void)
{
    unsigned char var=10;
    unsigned char output;
    if(var==1)
        output=3;
    else if(var==2)
        output = 2;
    else
        output =1;
    return output;       
}
unsigned char Alt(void)
{
    unsigned char var= 10;
    unsigned char output;
    output = (var==1)?(3):((var==2)?(2):(1));
    return output;
}
void main(void)
{
    int x;
    x = alt();
    x = alt2();
}
Now on compiling this with avr-gcc with -S option you should be able to get the assembly code output also. Let us compare the functions Alt and Alt2 which have same functionalities.
alt2:
    push r29
    push r28
    rcall .
    in r28,__SP_L__
    in r29,__SP_H__
/* prologue: function */
/* frame size = 2 */
    ldi r24,lo8(10)
    std Y+2,r24
    ldd r24,Y+2
    cpi r24,lo8(1)
    brne .L2
    ldi r24,lo8(3)
    std Y+1,r24
    rjmp .L3
.L2:
    ldd r24,Y+2
    cpi r24,lo8(2)
    brne .L4
    ldi r24,lo8(2)
    std Y+1,r24
    rjmp .L3
.L4:
    ldi r24,lo8(1)
    std Y+1,r24
.L3:
    ldd r24,Y+1
/* epilogue start */
Alt2 takes a stack frame of 2 bytes and the code is readable to a great extent. I am sure it is more maintainable compared to Alt. However, Alt generates a stack frame of 4 bytes.
Alt:
    push r29
    push r28
    rcall .
    rcall .
    in r28,__SP_L__
    in r29,__SP_H__
/* prologue: function */
/* frame size = 4 */
    ldi r24,lo8(10)
    std Y+2,r24
    ldd r24,Y+2
    cpi r24,lo8(1)
    breq .L7
    ldd r24,Y+2
    cpi r24,lo8(2)
    brne .L8
    ldi r24,lo8(2)
    std Y+3,r24
    rjmp .L9
.L8:
    ldi r24,lo8(1)
    std Y+3,r24
.L9:
    ldd r24,Y+3
    std Y+4,r24
    rjmp .L10
.L7:
    ldi r24,lo8(3)
    std Y+4,r24
.L10:
    ldd r24,Y+4
    std Y+1,r24
    ldd r24,Y+1

We see that now the stack frame is 4 bytes & to  add to the woes the code is not so much readable as well.
Thus, we break a myth that complicated & compressed "C" files give compressed code. More often that not modern compilers are clever enough to do everything that is needed for optimisation. So please spare yourself the troubel and let the compiler do its job.
However, that doesn't mean that we should write inefficient code. What it means is that -  "Dont think you have optimized the code by just changing some "if" statements to "ternary"  operators. It is more than that and quite usually compiler dependent". The best way to optimize is to read the compiler manual and try to understand the compiler and its capability. Then you can use tricks in "C" to optimize the code.
 

Powered by ScribeFire.