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.

Throughput funda's

I have been quite inconsistent in updating the information presented on this blog. The one things that discourages me like any other new blogger is that very little traffic is seen here and since this is a technical blog, unless i get feedback it is difficult for me to judge if something is good or bad. However, for now i have considered that no feedback is negative feedback. Nevertheless i continue to write.
What is Throughput...This is the weeks question.
Wordweb tells me

Output relative to input; the amount passing through a system from input to output (especially of a computer program over a period of time)

The Throughput that i am talking is the one that embedded engineers often talk about. In simple terms this value is a measure of the CPU load under the worst conditions. What could be the worst conditions? These are basically situations which demand more processing power. For example, Image Stabilization, Red Eye Detection, Smile Detection, Ambient light detection along with Click detection or auto timer ( and image post processing) in a Camera perhaps put a great deal of performance demands on the CPU in a Digital camera and this also determines it worst case performance.
Unfortunately like many other engineering terms a higher value of throughput means that your system is more loaded. Often under some conditions the throughput reaches 100% in systems which means the CPU has almost no idle time and is being utilized all the time to its maximum capacity.
If i look at it from an EMS perspective then startup is the when there is very high CPU loads that are encountered. In an OS based system there are methods to determine for how much time the CPU is free. Usually, some background tasks which are not necessary to be done all the time are done in this free time. ( Example, CRC calculation or RAM Checks etc). In simple scheduler based systems the throughput is just the time remaining in the baseloop after all the tasks have been finished. One more parameter that influences the throughput to a great extent is the Interrupt Rate. A very high interrupt rate will ensure that the CPU loses a lot of time in context switches which are really an overhead and do not contribute in anyway to the functionality of the system.
[ This was my understanding of Throughput. After looking into wiki i think the origin of is term comes from the CPU bandwidth utilization. The term is primarily used for parametrization of Communication channel bandwidths]

How Do we ensure that we never reach 100% throughput?

• Plan your interrupts and their sources well. You should know the worst case rate of an interrupt beforehand. Example, the Door lock engage interrupt cannot come at say more than 1-2 times a second ( Due to the inertia of the lock).
• Write your code with throughput in mind. E.g if possible use binary search in place of linear search. Use macros instead of functions judiciously
• Overuns should be detected in software using some special variables or debug variables. Over-Runs occurs when the throughput goes more than 100%. Which means that you have asked the CPU to more than it is capable of handling in the given time. 

This is very brief and windowed perspective of Throughput. If you have some other inputs as to how this is related to your domain then do put a few lines of comments.
 Please leave your comment. You can subscribe to this blog by using the links under "Subscribe" section.

Powered by ScribeFire.

Const Keyword - Coding Myth 3

This post talks about the "C" keyword "const". It is very often thought that making a variable "const" ensures that it gets placed in the non-volatile memory (ROM or flash). But how true is this?

Well to start with w.r.t the ansi "C" compiler, the "const" keyword just tells the compiler that the user doesn't intend to modify the variable.
E.g.
           const unsigned int Gctrl_NoOfGears= 10;
so if i try to do this
           Gctrl_NoOfGears +=1;
I can either except a warning or an error. something like this
error: assignment of read-only variable `Gctrl_NoOfGears'
However, does this warrant me that the variable is now placed inside the memory in an non-volatile area.
Well, the answer is it is compiler (settings) dependent.
Why?
Most embedded compilers are very smart and automatically place the constants in the ROM/ flash area. However, some times the flash or ROM is used only as program memory and NOT as data memory. In which case there is no way (directly) that the compiler can place this in the program memory. Also In these processors the program memory is not directly accesible because the program & data are stored in differrent memory location & have different busses to access.  In such processors writing

const char DisplayStr[] = "Welcome";

will not cause DisplayStr to go into the ROM area.
You will have to do this via some compiler pragma's like

#pragma section start ROM
const char DisplayStr[] = "Welcome";
#pragma section end ROM

to make the compiler understand that it has to place the value in ROM & not in the RAM area.
Do I have to worry?
As a novice or some one programming for a simple system NO. However, when you are running low on resources and for various other reasons it makes sense to have a look at what the compilers is doing when you say "const". I repeat MOST compilers are clever enough to put the data into the ROM automatically.
The best practice is always to have a glance into the map file to ensure that you have everything at the right places.
Also, in one of the future posts i will be talking about another usages of const and how some constants are present even without your knowledge ( also little talk about const volatile...the common question in any interview on "C").

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

Previous coding myths here {1} ,{2}

Powered by ScribeFire.

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.

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.

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.

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.

Where does it run ?

This post comes in the wake up some discussions i had with few people working the embedded domain a few days back.

The question was, where exactly does our code in the micro controller run? The answer again unfortunately is not so straight forward. The reason is because different micro controllers behave in different ways. Let us therefore try to understand how the whole process works so that we can judge it better.

Frankly, the micro controllers at its core are just a bunch of registers on which a few mathematical operations can be done by another piece of hardware ( part of the core) called the ALU(Arithmatic Logic Unit). Most of the micro's thus have a Accumalator(Acc). This is like the mother register and most of the operations (mathematical or logical) will use the Acc register (There are instructions that do not involve the Acc also. like mov H,L does not involve the Acc). To ensure that some instrucution is executed, it must be first fetched, decoded and only there can be some action. To fetch an instruction, it should be readily available. Readily is a fuzzy word here because what is readily on 8Mhz system is really too slow on a 1GHz processor. The readiness depends on how fast we can read the said instrucution. The simplest micro controllers like 8051 keep the instructions in their flash memories. These are accessed by the core and then executed. Some industry folks call this as "Executing from the Flash".

Modern micro's have the concept of cache. This means they will pre-fetch and keep some of the instructions in a faster re-writeable memory. The core thus will use the cache to read the instructions instead of reading from the flash. Crude and simpler implementations of cache are in the form of instruction queue etc. These don't have the capabilities of the cache memory but never the less helps in making execution faster. So, now the instructions are stored in flash, but executed really out of cache memory.

Some micro controllers also provide a wonderful feature where in the instructions can be stored in the RAM. This is generally done while reprogramming. More about reprogramming will be there in future posts. Here the real program resides in the flash memory but one can copy the program to RAM and then set the core to fetch the instructions from the RAM instead of the flash.
Some folks call this "Execution from RAM".

The fact is that most modern micro's can read instructions from both Flash, Ram or in some cases even from communication buses (like CAN/FlexRay). The last part is tricky one and will be discussed in some other post ( because i have to get more information on that yet).

My take is this, all code gets executed in the core. All that can vary is where we are fetching it from.


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

Powered by ScribeFire.

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.

ILS - Intelligent Light System

MERCEDES Intelligent Light System

This is real technology. The Intelligent light system from Mercedes. The ILS has a lot of features which include

• Country mode driving
• High Intensity fog lamps
• AutoBahn mode for going on freeways
• Automatic adjustment and correction for the headlight so that even on bad road conditions best illumination is provided. 
• Cornering lights

From what i gather from various websites and people aware of this technology is what i am putting here. All of it might not be fully correct and complete.

Well so much for the disclaimer part :-).

The AutoBahn mode has a very important feature that increases the output of the Xenon Headlamps based on the speed. This means that you get better road visibility ( up to 120 m). Also the Light cone is designed in such a way that it doesn't blind the traffic coming from the opposite lane.

The cornering lights use the Steering angle and the indicators as in input, along with the direction in which the vehicle is moving to calculate the angle by which the headlamps need to be swivelled to ensure that the corners of the road are illuminated. Basically, in simple terms the light beam is kept parallel to the tyres of the vehicle rather than the body ( as in conventional systems).

This is done by having a clever set of actuators which control the light beam by moving the light bulb as well as lens in from of the xenon bulb to accurately reposition the beam. A horde of sensor inputs coming from the steering angle sensor, vehicle speed and the camera mounted on the windscreen help the control algorithm to readjust the light beam and position it accurately.

Of course, cool technologies come at a cool price and the same is true for this system which is available only on the high end Mercedes cars including the new E-classes.

Ref: articles here  [1]   [2]    

Simulate Emulate and Debug....

Here i try to talk about a widely misunderstood topic. It is about Emulators, Simulators and Debuggers.

For starters, these three are different things and have different ways of operation and capabilities but have a common intent. Helping the embedded developer, develop his software in a more robust way with lesser number of bugs.

Lets start with the most common one, Simulator. A simulator is a software that runs on the host pc ( Your personal computer), and is able to mimic some/all of the behavior of micro controller. I use the term µC because that is what we will be dealing more in the future posts. However, this is equally applicable to the µC too. Some/all is in bold because simulators often cannot mimic all the functionalities that can occur in the real hardware. Some of the very good simulators i have seen are the AVR simulators. This should be available to you if you download AVR studio which i discussed in my earlier post here.

Next is a Debugger. A debugger is a device ( Typically an external peice of hardware connected to your PC via a serial link like USB) which talks to your µC and provides information to the host PC which is displayed in some kind of a debugging environment. Often the external hardware debugger is accompanied with a PC envirnonment to debug it and people confuse this environment to be the debugger. Unfortunately, that is incorrect. E.g of Debuggers 

• Nec Mini Cube with IEQB850 as the debugging environment
• ATMEL -ICE with AVR studio as the debugging environment.

Technically speaking, if you are a great PC prorgammer, then it should be possible for you to create your own debugging environment which talks to the hardware debugger and displays relavent information on your screen.
It should be obvious that to really use a debugger u needed a µC to which you can talk to. Without having a µC ( often called Target), there is not much you can do with a debugger.


Finally we have the Emulator. This is where everyone gets confused. An Emulator emulates the functionality of the µC. This means that the real µC is not present in the system. This is in contrast with the Debugger which requires an external µC to really talk to. Since, the Emulator emulates the functionality of the µC, there is no need for an extra µC. The question now arises why do we need an Emulator at all if we have a debugger? Why take pains to emulate the functionality of the micro when we already have it available?

Answer

• Often the real micro controller will be in developmental stages, while companies still want to use them. So Micro vendors like NEC come up with Emulators.
• Emulators can have more debugging capabilities compared to the real µC.
• Since, the Emulator is emulating the µC, it can be reconfigured via different means ( we will discuss this else where) to emulate more than one type of µC ( of course, not at the same time!!).

Eg: Nec IE-CUBE is a emulator for NEC V850 micro controllers

Costwise, typically simulators are cheap, Debuggers are costly and Emulators are very costly. Also, for debuggers to exist the µC should provide some kind of debug interface ( remember the debugger needs to talk to the micro!!). We will talk about debug interfaces in one of the future posts.

I hope this post helps people to lose some myths about the three components.

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

ISR - Interrupt Service Routine

When i was in college i always wondered how my mouse clicks where recorded by winamp while it was actually busy playing music.
Only later during my second year in Engineering did i come to know about interrupts. This post is basically a quick and short intro to ISR's.

Interrupts are hardware or software generated events that get registered with the µC/ µP. So when i click my on my mouse, the hardware event generates a signal that goes and gets registered with the processor.
( Note: Actually this process is far more complicated since the interrupt passes through a Interrupt controller etc)

Once it is registered / recognized by the CPU, it then depends on the CPU is configuration whether the interrupt will be processed immediately or will it be kept pending. Processing or servicing of in interrupt is done by saving the current state of the µC and then executing the ISR. The fuzzy word here is current state. It is fuzzy because current state can mean different things in different situations. However, at minimum we know that we would need to save the address of the instrucution which we are currently executing so that after the ISR servicing we can return back to this point.

In real world situations, there can be many events that occur concurrently.

E.g. -> You can right click on the mouse while pressing a key on the keyboard.

How does the CPU handle it all?

The CPU handles this by using an on-chip  or off-chip peripheral unit called the Interrupt Controller. The Interrupt controller is capable of providing priorities to various interrupt sources.

E.g. -> In a Heater control system, the overtemperature event takes higher priority when compared to the User input event.

Apart from Handling the priorities of various interrupt sources, it also ensures that some of the events are masked. E.g you dont want an interrupt to bother you when you are doing some highly critical computation.
In many µC's the interrupt controller is on-chip. Usually, the software during the intialization of the system configures the interrupt controller so that it can prioritize the interrupts etc. In some controller dynamic priority is not available.

E.g. -> A watchdog Interrupt will always take higher priority than a timer interrupt.

So where is the ISR here?

The ISR is a set of instructions that the CPU executes when i detects and acknowledges a said interrupt. The Key word is acknowledges, because in some cases even though the interrupt is detected it will not be acknowledged.

E.g  ->while windows is booting up it might not want to acknowledge any mouse clicks.

At the end of the ISR (i.e the code in the ISR), the CPU returns back to the point where it has broken off to execute the ISR. Note that based on micro-controller architectures this will have differing behaviours when more than one interrupts are in pending state.

The concept of interrupts is very essential and is widely used in almost all embedded applications. Hence, a sound understanding of this concept is essential for anyone who wants to do some kind of embedded programming.



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.