Auto Transmission - I

With the advent of technology man has always asked for better systems to lower his efforts in doing things. The same story goes for Transmissions. Manual transmission served the purpose very well. However, soon the customer demands became higher and he wanted a system that could change gears on its own. No one wanted the clutch anymore!! Well atleast not the folks who always tended to over the engine by downshifting too early or lead the vehicle to stall by upshifting too early. This lead designers to come up with a system in which the clutch pedal could be totally eliminated. There were lot of solutions and some have been described here. Unfortunately, i dont know the order of their evolution but guess that that is not really all that interesting...
Lets take the case of the simple Hero puch or the TVS 50.....Can we call it an automatic transmission....?
Not really...however to some extent yes.
How does based on throttle the vehicle start moving?
This is because of a clutch that engages as the RPM increases. Such a clutch is called Centrifugal Clutch. Normally the clutch is disengaged. Which means that no power from the engine will be fed to the chain drive. However as the RPM increases a certain threshold the clutch engages. With the clutch engaging the power is transferred to the wheels. This is a very basic of how we can eliminate the manual clutch ( our initial aim ....). As it is clear that the centrifugal clutch will wear out with time and that means RPM points at which the power will get transferred to you chain drive will vary with time. The second disadvantage is that this method cannot transfer huge amount of torque from the engine shaft to the output shaft. I am not really using the term Transmission shaft because this is not a "Transmisison" in classical sense.
What are the other methods?
How about Kinetic Honda that has been ruling the roads since i was a kid?
Well a Kinetic Honda uses a different mechanism. It uses what is known as a belt drive...( atleast that is what i was told. I am not 100% sure!!). This is fed to a Stepped pulley or Coned Pulley. This coned pulley will be able to provided different Pulley Ratios based on which point of the pulley is used to Tap the output. A the most broad end of the pulley the Torque transmission will be less and a the thinnest end of the pulley the Torque transmission maximum. Centrifugal clutch is still used here.
Does that mean CVT ( The stuff we talk ed about...Continuous Variable Transmission) is a cheap and dirty technology?
No absolutely not. Like any other technology based on how much complexity is added one can make the system very sophisticated. The commonly used CVT's in bikes like Honda Activa, Honda Dio, Kinetec etc are fairly simple. However, some really complicated stuff from Audi can be found here and remember the core is still same....a coned pulley...

After taking care of these two aspects...i.e. some kind of autoclutch and a automatically shifting gearbox the other biggest challenge was to ensure that high amounts of torques are transmitted through the shafts. When you talk of cars like Mercedes, BMW's and high end Maybach's Torque can touch much more than 100 Nm's. 12 cylinders V's could not be "Auto-Transmitted" using a simple or complicated CVT...

Something new was needed...and that will be apart of the next blog ofcourse :P

Eeprom and Flash Emulated Eeprom

This post talks about some basics of EEPROM and FEE.
To start with the discussion it is necessary to know what EEPROM stands for. EEPROM stands for Electrically Erasable PROM. Where PROM means Programmable Read only memory. The very fact that we are highlighting the Electrically Erasable means that there are other methods to erase the PROM. I leave it to the reader to find out what these are and leave as a comment.
Why do we need it?
In any system there are some set of parameters that need to be remembered through power cycles and can/may change between power cycles. An example....Well Your monitor settings ( i.e. the brightness contrast etc that you do on your monitor) is remembered through power cycles even if you connect the monitor to another PC or whatever. One of the places to store this could be the EEPROM.
What does this mean?
To write to the EEPROM i should be able to erase it and then rewrite it. Also it should be capable of being written several times ( maybe a few lakh times). Also, it should have data retention capacity. i.e if i write it today and check after say some 10 years the data should be same in the absence of any power.
What is FEE then?
As you can see some of the properties of EEPROM are held by the flash memory also. Like i can write into the Flash memory electrically, it can retain information across power cycles, it can be written multiple times. However, the biggest different is that the flash technology ensures that it can be written only in huge chunks like 64 or 128 bytes. Also, the life of the Flash memory is much lesser than the EEPROM. On the other hand the best part is that it costs much less than the EEPROM.
So FEE which stands for Flash Emulated EEPROM is basically a method of emulating the behaviour of the EEPROM using the Flash memory. This means if a Flash memory has 10000 write cyles, i should make it some how work as if it is 100,000 write cycles ( like in case of EEPROM). Also, i should provide somehow the capability of writing a single word/ single byte as available in the EEPROM.
In short if i have FEE then the application should feel as if it is having EEPROM....
How to do this ? Well that is for another post....


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

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.

Engine basics - Knocking

This post talks a bit about a concept called "Knocking" which is very common in Spark Ignition Engines having very high compression ratio.
The question we need to answer first is what is Knocking?
"Knocking" is a metallic pinging sound that is caused inside the engine cylinder & leads to high intensity vibrations in the Engine block ( usually causing metal fatigue in the cylinder walls). If the engine knocks for very long duration then this might have serious impact on the usability of the engine and on the engine life.
What causes "Knocking"?
Flame front:
The power inside the cylinder which is generated when a spark ignites the air-fuel mixture leading to a flame front. The flame front is a high velocity pressure wave that travels, after originating near the spark plug, downwards to push the piston head and ensure that our engine keeps running.
Now, what happens is that based on the fuel quality among many other factors there are certain spots inside the cylinder with some carbon deposits.If the cylinder temperature keeps rising due to ignitions then at some point of time these hot spots reach a temperature where they are capable to ignite the air fuel mixture or the yet unburnt gases (also called End gas). Simply put there is sufficient heat accumulation at certain points that these act as potential spark plugs.
The Problem:
This causes a problem because we do not have any control over these spontaneously created spark plugs ( so to say). This means that they can ignite the end gas at any point of time. In homogeneous operation of engine ( more about this mode in future posts), the mixture is fairly rich and these hot spots have energy sufficient to create a ignition of the air-fuel mixture.  This phenomenon  is often known as "Detonation".This ignition causes a pressure wave to travel from the spot towards the periphery. This Flame-Front if collides with the flame front travelling from the spark plug will result  in wo very high pressure waves to bang into each other. This leads to very high pressure peaks which put extreme amounts of stress on the cylinder walls. Continuous Knocking might lead to permanent stresses getting formed in the cylinder walls & the piston head which eventually will lead to their failure.
How to Avoid it ?
A few years back when "leaded Petrol" used to rule the market the folks added something known as Anti-Knock in the petrol to ensure that it did not knock. This however, lead to higher amount of particulate matter in the exhaust and also was not good for the cylinder walls.The anti knock was a Lead compound which i cannot remember at this point of time.
These days we use more of "Unleaded Petrol" and there has to be  different mechanism to control the "Knocking". This is done these days by ensuring that the engine temperature doesn't reach very high ( then there is lesser chance of hot spots getting created). One of the methods employed to do this is EGR. Exhaust Gas Recirculation, ensures that he temperature of the engine come down apart from having benefits like enhanced fuel efficiency and reduced NOx in the exhaust. However, that is a different topic and will be dealt a little later. The other method used in conjunction with the EGR is spark retard. Spark retard will ensure that you ignite the air-fuel mixture late enough that there will be no pressure peaks. When we do not have pressure peaks the chances of knocking are lesser.
Finally, use of high octane fuel will result in better combustion of the fuel and lesser hot spot contribution because of poor fuel quality. The reduction of hot-spots will result in reduced Knocking even at higher engine temperatures.
Some links that give more info on how it is detected etc
[1]

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.

Fuel Injection - Evolution Journey-II

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

Q: What are the different fuel injection methods used?
Fuel injection systems evolved over the years from being a simple Manifold injection to DI ( Direct injection). The injection of the fuel into the Intake Manifold based on the Air Mass that is currently sucked into the cylinder is controlled either electronically or by mechanical methods. This is typically a function of the engine load. The engine load can roughly be determined by the throttle opening. The terms "Full-Load" ( i.e. Throttle valve is fully open) and "Idle" (i.e. when the Throttle valve is closed & the vehicle is stationary) are very frequently used in the discussions further.
After the SPFI ( Single point fuel injection) where the fuel was sprayed into the manifold the next thing that became very popular was multi point fule injection (MPFI). Here multiple injectors were placed at suitable positions in the intake manifold to get finer control over the air-fuel mixture. Also having multiple injectors ensured that the injector closest to the cylinder going into suction stroke could be activated. In some cases this is called Port Fuel Injection (PFI). This provided also the following benefits:

• Fuel going into each cylinder could be precicely controlled.
• Air & fuel would get mixed just before inlet into the cylinder. This ensured that the atomised fuel did not have condensation problems. i.e. in manifold injection with single injector the air-fuel mixture when suddenly expanded in the cylinder under cold start conditions the fuel would condense & form larger particles inside the cylinder which led to higher emissions

The MPFI injection systems came in two variants, though this is not really something great !!..

• Batch Fired : In this all the injectors for one bank of cylinders where activated in one shot. i.e. for a 4 cylinder engine, injectors for cylinder 1 & 4 were activated together similarly 2 &3.
• Sequentially fired: Here the injectors where activated sequentially based on which cylinder was going into suction stroke.

Finally came the Direct injection. The direction injection opened up new domains of controlling the air fuel mixture because now only air would enter the cylinder and it could be the ECU that would control the fuel being injected into the cylinder. This ensured that by injecting at different points inside the cylinder & by different cylinder head profile one would achive higher spread of the atomized fuel. This lead to better flame front propagation, ensuring higher power output.
Why did we not go for Direct Injection to start with ?
The manufacturing processes in earlier days did not provide us with methods to have injectors that could bear the very high pressures generated inside the cylinder. Also, the fuel injector tip has to bear extreme temperatures which are generated inside the cylinder. Also, the pump which pumps fuel into the injector needs to generate very high pressures because if fuel is injected in the later stages of compression ( like it is done in Stratified mode of operation). The injector nozzel design also has undergone many design changes to ensure that a extremly fine spray with precise control on droplet size could be created.

Powered by ScribeFire.

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.

Faster and Hotter chips!!

I have not been able to blog here due to two reasons. One I got lazy, two is first as the same. Any way now i have woken up from my slumber. This neat article talks about a new 8 core chip ( for servers) from Intel. However, have you ever wondered why suddenly there was a paradigm shift from having faster chips (3GHz or more) to having more cores?

The main reason ( though there might be many others) is the problem of heat dissipiation. Just to give a little bit more information in this regard i will try to go a bit below the layer. The modern chips are all based on CMOS technology. Though most magazines call them as transistors they are really MOSFET's ( which means MOS Feild Effect Transistors). CMOS has this wonderful property that it consumes literally no power when it is holding a logic 'O' or logic '1'. So why the power loss? The power loss really occurs when there is a switching of the CMOS from the logic '0' to logic '1' or visa versa.

This means that more you switch the transistor the more heat you dissipiate. The more heat you dissipate the more cooling need for your chip. Now we are left with two options, either ensure that  we cool the chip well or we reduce the heat generated. To a great extent we can cool the chip by adding bigger fans and heat sinks, however there is a limit to this ( because the heat generated takes a finite amount of time to get carried out and be dissipiated!!). If we concentrate on the second option we observe that if we do not switch the transistors so fast we can control the heating. This is what Intel has chosen to do by not trying to pump up the gigahertz. However, to boost performance now there are two cores ( which run at a slower rate!!) which can parallely execute instructions which are not directly dependent on each other . The story i am sure is more than this and i am not technically competant enough to put in that stuff here. However, someone i know does. I would be requesting him to add a few lines to this blog in a few days.
Please leave your comment if you have one. You can subscribe to this blog by using the links under "Subscribe" section.

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.