Showing posts with label Intermediate. Show all posts
Showing posts with label Intermediate. Show all posts

September 18, 2009

The Early Fuel Pulse

This post again goes back to the EMS basics that i have been writing about in the previous posts.
Early systems when started to use the Gasoline Fuel injection ( Manifold injection) only controlled the Fuel pulse. Fuel pulse is the industry term that has evolved for the duration for which the Fuel Injector electrical signal is enabled. How does the Fuel Pulse help us to control the fuel?
The fuel line is maintained at a specific pressure. This pressure is usually created by a pump either in Fuel tank or outside of it. The Fuel is maintained at a fairly high pressure. The Injectors are solenoid based valves. A electric signal running through the solenoid opens the valve. The valve closed back with the help of a spring. This spring ensures that once the fuel pulse is cut off the valve closes immediately. However, this is not true and there is adjustment added in the EMS software to take care of this variation.
As in the earlier discussions the Fuel pulse directly depends on the engine load and the engine rpm. Now i explain in some bulleted points why some sensors are needed and how they contribute to calculation of the fuel pulse.
Intake Air Temperature Sensor : The density of air depends temperature hence the temperature sensor is used to indirectly calculate the density of air. Warm air is less dense while cold air is more dense.
Air Flow Sensor: In systems which use the Air-Flow to determine the intake air mass a Air Flow Sensor is used. This is basically done using a simple logic. 1) Calculate the volume of air that has passed the flow sensor. 2) Use a Lookup table based approach to get the density of the air based on the temperature 3) use the density and volume/sec to get the mass air flow into the manifold.
Manifold Absolute Pressure : Not all systems use the Air Flow Sensor, some ( like the Bosch D-Jetronic) use the pressure in the Manifold to calculate the Mass air flow into the manifold. This system has a drawback because as the engine revs up the pressure fluctuations inside the manifold are immense ( Because at the other end of the manifold we have the engine which is acting like a pump!!). Using the Gas equation it is easy to derive the Volume of the air using the Pressure and the temperature information.

Just a small deviation here.....Air Flow Sensors come in two type....1) Vane Type 2) Heating element type.
  •  The vane type is pretty straight forward....you put a piece of thin metal in the path of the air flow....faster the flow more the vane will be pushed. The other end of the vane is connected to a potentiometer which will show variation of resistance to the ECU.
  • The Heating element uses a small coil and maintains it at a particular temperature using a small current. The air flowing over this coil cools it down changing its resistance and thus varying the current.
The RPM of the engine is detected easily by a magnetic pick up and a gear. Note that early systems did not control the Ignition Timing. It was fully controlled using the Camshafts and a Distributor. However, LE- Jetronic systems from Bosch implemented Electronic spark distribution, However even in these systems there was very little control on the Ignition timing which still heavily depended on the Camshaft.

Corrections and Compensations
Though the base Fuel pulse width was calculated using Lookup-Table ( i.e FuelPulse = f(rpm,engineload)) there are some special diets for the engine based on some special conditions.
  1. Startup : The mixture leaning effect is seen in a cold engine. What does this mean? When the engine is cold ( manifold and other portions also) then the mixture formation is not at its best...Which means that all the fuel that is injected is not going to burn. Hence to achieve the same behaviour more fuel needs to be added. Conclusion : Increase in PW
  2. Low Battery: This means that the battery voltage has dropped below a specific value. This directly translates to insufficient current supplied to Injectors. Since there is lesser current on the injector solenoids the do not open so well hence we need to elongate the pulse to ensure that the same quantity of fuel is delivered as we intended to. Conclusion : Increase in PW
  3. Idling : The engine needs a certain RPM to be maintained to that in can overcome its self resistance and continue to function. However, if the throttle position supplied by the driver is taken into consideration....there is none...i.e the driver doesn't push accelerator to keep the engine idling. Hence the EMS should understand this condition and automatically provide a finite amount fuel.  Usually a special switch is incorporated in the Throttle pedal assembly which detects a no throttle press condition.
  4. Acceleration Enrichment: This sudden demand for power occurs when the driver floors the throttle. This sudden flooring of the throttle can cause the mixture to lean out instantly making the engine under go a "lean stumble". This is avoided by providing a throttle floor switch which is activated when the throttle is floored and indicates the ECU about a sudden power demand. Conclusion : Increase in PW
In my current project there have been fierce discussion about which one is a correction and which one is a compensation....I say does it matter ? If you understand how we can classify these please let me know too !!
[Note: The above is just the beginning and talks only about early Manifold injection system, Next post will contain how other signals were added to this base system to improve the performance!!]





Powered by ScribeFire.

June 9, 2009

Inlining code - Coding Myth 2

This post is regarding the inline keyword.
Very often we learn C & C++ together and end up mixing one language with the other. I learnt this the hard way when i found out in some debate that the "inline" keyword doesn't belong to the C language.....Boohooo!!..
Inline keyword natively belongs to C++.  It serves the purpose of just ensuring that the function is pasted inline instead of having a call to the function at every instance of the function call.
It was not a part of C. In "C" we achive similar functionality by using what are termed as "Function Like Macro's".
E.g.
#define Max(a,b)  ((a)>(b)?(a):(b))
The funciton like macros have a major disadvantage over Inline functions and that is the blindness to the compiler.
#define macro's are processed by what is known as the "C Preprocessor". The preprocessor looks for the macros and does a macro pasting operation. Which means that where ever in the above example Max is used the equivalent code is pasted.
E.g
y = Max(5,6); is equivalent to y = ((5)>(6)?(5):(6));
Then what is this blindness funda?
Well if iwrote this code
int *ptr;
y = Max(ptr,'5').
Then even this would work as for the Macro-Processor. Infact in this particular example even the compiler will not complain. However, if this was a inline function then the compiler would have been flag an error.  So it is easy to see that the inline key word has benifits over the #define macro.
Now some interesting stuff
  • - Did you know that the inline keyword is just a request to the compiler. The compiler might choose to ignore you fully and would just make the function a normal function if it feels that by making it inline it is losing out on optimization.This is in contrast with #define function like macro's which are outside of the compiler's control.
  • - Modern C compilers provide you various methods of inlining function by compiler extensions. E.g some compilers provide pragma's
#pragma InlineStart
void Inlinefunction(void)
#pragma InlineEnd
or things like
@inline void Inlinefunction(void)
  • Inlining is very useful to ensure modularity & keep your code clean. However, In "C" if this was natively available then we embedded users would not have resorted to function like macro's.
  • Evils of the keyword "inline".....Well it is difficult to debug your inline function because there is no call to the function and also it is not really visible to your debugger:-(.
Now that we have some idea of the keyword "Inline", you can try to check out the statements made above using our good old GCC compiler with "-S" option and have a look at the generated assembly code.
Please leave your comment. You can subscribe to this blog by using the links under "Subscribe" section.

Powered by ScribeFire.

June 4, 2009

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.

May 7, 2009

Time Out!!

This question came from a very good friend and ex-colleague. So just responding it via this post which i trust will be useful to others also.

The question

What is a "Cyclic Wakeup Timer"?

The question can be answered if we understand each of the three terms.

We start with Timer. Timer is a hardware or software that keeps track of time via counts. If we know that each count takes say 10ms then we know that 10 counts will mean 100ms. The timer is controlled by its clock which is usually derived from an external crystal or internal PLL circuits.

Next we take Cyclic. It is clear from the word that this shows a repetitive process. The timer runs continuously and maintains time. Which means i can configure a cyclic timer to create an event every 10ms. When 10ms elapses there is a event generated by the Timer (called the timer interrupt by some people). In the event handler we can choose to reinitialize the timer to count for another 10ms. Various configurations are possible, we will not discuss all of them here.

Last part is Wakeup. This is simple, we do this everyday. In this case we are talking about the microcontroller waking up.

To put it all together, a timer that wakes up the microcontroller at periodic intervals is a CWT or Cyclic wakeup timer.

The pertinent question is now, why do we need this?

I can talk only for automotive and perhaps for some other battery powered devices.

Many devices go into sleep mode when they are not doing anything useful, however the periodically wakeup to check if there is something useful to be done. I quote a few examples :

  • A PKE ( Passive Keyless Entry) system might wakeup periodically to see if there is a key in the vicinity of the vehicle. If there is then it automatically unlocks the door. (Note: It is technically quite challenging and complicated)
  • A BCM ( Body Computer Module) needs to wakeup periodically to check for monitoring certain inputs.However, this is usually because multiple external events might try to wakeup the ECU but there might not be so many interrupt pins available. 
  • I know of a system which used to maintain the time. The system would go to sleep and wakeup every 1 sec to update its time variables. Only when the vehicle was on the system would display the time else it would go to low power mode and wakeup only every 1 sec.
As you can see that the CWT is quite useful. However, it might be a tough job to handle the CWT along with other wakeup sources which try to interfere with its operation.

Hope this clears my buddy's query...

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

 



Powered by ScribeFire.

May 6, 2009

Let Us Model

I am not really an expert in this domain. I switched companies about 3 months back and with that i also changed my working area to some extent. Now instead of writing code i model it.

Why does one need to model code?
The reason is that model acts like a common language between the coder and the provider of requirements. However that is not the only reason. Most of the Modeling languages these days provide a mechanism to directly convert the model into code or partial code.

Simple cases:
  • UML modeling: These days many if not all commonly used high level languages are object oriented. UML provide a very nice method to model the system in terms of classes, packages and their interdependencies etc. There are free and paid tools that are can directly convert from UML models to skeleton code.
  • Simulink modeling : Simulink is a very powerful tool available from mathworks. The tool provides you simple gui based interface to create models. These models can be fed with inputs and then the corresponding outputs can be tested for their validity etc.
In the automotive domain currently, Matlab is used very often for verification of complicated algorithms. Once the simulink models are tested extensively, then it is possible to automatically generate floating point code using RTW and Embedded Coder. This code can be directly flashed into controllers which have sufficent floating point muscle power be used to verify the functionality in the real hardware. However, more often than not, floating point muscle power comes at a heavy price and is not preffered for production programs.

So what is the next step?

You got it right!! Convert the floating point code into fixed point code. The fixed point code can run faster on simple µC's. Caution: Note that all processors are capable of doing floating point operations however, in simpler micro processors there is no dedicated hardware unit for doing this. Which means that this has to be done in software which is time consuming and memory consuming. Some processors like PPC are capable of doing this in their hardware
---------------------------------------------------------------------------------------------------------------------------
— Floating point
– IEEE® 754 compatible with software wrapper
– Single precision in hardware, double precision with software library
– Conversion instructions between single precision floating point and fixed point
---------------------------------------------------------------------------------------------------------------------------
Excerpt from PPC mannual.

Obviously we have to understand that due the limitations of the fixed point code there will be resolution error also called quantisation errors. Based on how we choose our scaling ( will talk about this later) we can ensure minimal quantisation errors. Of course, note that fixed point code is not really all that fast but ofcourse faster than floating point code ( slower than unscaled code!!) .

To conclude, these days quite often the system engineers etc use the simulink models to develop their algorithms while software developers work on the simulink models as inputs and create the fixed point code that goes into the ECU.

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





Powered by ScribeFire.

April 24, 2009

Lets do a Ctrl Alt Del

I had written about interrupts in the post here. This post is specifically about a particular interrupt which in most cases in Non-Maskable. The word Non-Maskable tells us that come what may the µC software will not be able to avoid it. This special interrupt i am talking about is "Reset".
Is Reset an Interrupt?

It is technically an interrupt however, some people feel that it is a microcontroller state. This is because when the µC is in Reset it really cannot do anything useful because the code will not be executed. However, we state it is as an interrupt because of the following reasons perhaps
  • There is a place for the Reset in the Interrupt Vector Table(IVR)
  • There are different reasons for reset to occur and in some µC's all the reasons cause the code to branch to the above mentioned vector.
What are the different types of Interrupts?

The most commonly known is the Power-On-Reset (POR) as it is commonly known in the embedded world. Note that just by applying power it is really not gaurenteed that the micro controller is undergoing a RESET. This is a very common mis-understanding that if we just apply power for the first time the micro will be under going a POR. For a µC to really under a proper reset it is needed that RESET pin is correctly handled. This is done via a reset circuit which looks like this. Note that this is for a 8051 micro which for some reason is RST high, compared to the conventional micro controllers where this is active low.
The other type which happens very frequently if you are a bad programmer like me is the Running reset. A running reset can be caused by many different sources. These include Watchdog reset, Illegal opcode reset, Illegal memory access reset and finally software reset. Each of these will be discussed in greater detail in the coming posts. As of now it is sufficient to know that this occurs because of something bad that has been caused in our software or in some cases we intentionally did it ( because we feel the best way is that way!!). In both cases the CPU starts from the Reset vector and starts executing code ( Except for in higher end 32 bit micro's where Reset vector is not the only criteria!!). Of course it is also useful to note that some µC's provide various vectors for WDT reset, Illegal opcode reset (PowerPC from Freescale is an good example).
Reset handling is a tricky issue for the hardware designers and not so much for the software guys. In coming posts, I will talk about some of the issues i have observed.

Wanna add your point or provide more info ? Please leave your comment. You can subscribe to this blog by using the links under "Subscribe" section.


April 12, 2009

Automotive ECU

About a couple of decades back there where very few cars plying on the Indian roads which had ECU's in them. This post provides a brief insight on these small units which crunch a horde of signals to make our vehicle smoother, faster and more efficient.

The Term ECU stands for Electronic Control Unit. The key terms here are Electronic and Control.

Electronic - This means the device is an electronic component. Typically, a ECU contains a Control Unit and more often than not it is a micro-controller (µC). However, in some modern vehicles ASIC and FPGA based solutions are also available. Apart from the µC there are  tons of peripheral hardware blocks which constitute to make the ECU's electronic hardware components.

Control  - This word describes the functionality of the ECU. It is often meant to control something. However, this is not always the case, but the term still seems to hold because of legacy reasons. In the vehicle one can classify the EU ( Electronic Units as i would call them) broadly into two categories.
  1. Control Units - These control some functionality of the vehicle. E.g. Control the fuel going into your cylinders based on how much you push the gas pedal.
  2. Information & Entertainment Units - These units provide vehicle information to the driver and also entertain the drivers. E.g. Navigation units, Car radio and Driver information system ( You can find one on the Mahindra Xylo)
On a after thought, I think we have one more category and this is a fairly new category. These are systems that help to interface different ECU's. E.g MOST-CAN gateway which is very common in high end cars.

There are lot of terms in this article which maybe jargon's for all newbies. However, I shall try to cover most of these Jargon's in future articles.

Coming back to the ECU...These days vehicles have as many as 90-100 ECU's (high-end) and about 8-9 (in mid and low end). The Tata Nano for example has a EMS which control's fuel and spark and ensures that the engine runs smoothly even under varing load conditions.

In the coming days, there will be more posts under automotive electronics (which is my area) and general embedded systems ( which some of my friends may add in!!).

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