[rjstyles69]

You answered my question DRC. This was the query(volatile and non-volatile) on my rattled brains at this hour still sitting at office .

[DRC]

Originally Posted by rjstyles69

You answered my question DRC. This was the query(volatile and non-volatile) on my rattled brains at this hour still sitting at office .

Fix the rattle dude! Go home and have beer, sleep

[Pankaj401]

Way lesser. Even the space shuttle wouldnt have a processor as powerful as what you have on your laptop!

... or the software as bloated as well.

[tsk1979]

Originally Posted by DRC

Here again, I am diggin deep into the details.

Over clocking is a x86 specific feature. It has more to do with thermal management. Let us not digress here..

Wrong! Any processor/chip/DSP can be overclocked as long as you dont exceed its limitations.
When processors/or rather any chip is designed, the set clock frequency is such that the chip works at that frequency in worst case scenarios too(high temp etc.,).
So if you are operating in better conditions(eg better cooling) you can give a higher clock speed, which is possible by modifying the divider values in the clock controller.

[mithun]

But I've also heard another advantage of more no of bits in an ECU....

More processing power is required to meet the Euro III emission specs so it's used to derive more efficient combustion through better engine management and is cheaper than modifying the engine...

Then why Santro(Bharat III) is still having a 8 bit ECU ? But Wagon R is having a 32 bit ECU to meet the stringent emission norms of the future.

So will the current Santro eRLX flunk in the future PUC checks ?

[DRC]

Originally Posted by tsk1979

Wrong! Any processor/chip/DSP can be overclocked as long as you dont exceed its limitations.
When processors/or rather any chip is designed, the set clock frequency is such that the chip works at that frequency in worst case scenarios too(high temp etc.,).
So if you are operating in better conditions(eg better cooling) you can give a higher clock speed, which is possible by modifying the divider values in the clock controller.

Yes! technically all processors can be over clocked if they are not operating at their obsolute maximum specifications. I stand corrected. However it is not the case in specific applications like ECU. For the reason that difference in clocking may mean a different software, especially when there are time dependant applications are run. So, I actually meant, over clocking is not a user option as in case of x86 systems. (Apple uses(d) PPC processors, but I am not sure if there was over clocking facility in their Macs)

[tsk1979]

Originally Posted by DRC

Yes! technically all processors can be over clocked if they are not operating at their obsolute maximum specifications. I stand corrected. However it is not the case in specific applications like ECU. For the reason that difference in clocking may mean a different software, especially when there are time dependant applications are run. So, I actually meant, over clocking is not a user option as in case of x86 systems. (Apple uses(d) PPC processors, but I am not sure if there was over clocking facility in their Macs)

The firmware is usually designed that it does not rely on the PLL clock to measure event duration. So as long as relative clock frequency is same, the same firmware will work in *MOST* cases.
The reason is that in case of the clock generator PLLs the circuitry is analog and clock frequency changes slightly during operation. There is shift and jitter. To get an extremely accurate clock generator, costs will be prohibitive. So the firmware takes this into account, and event duration is usually measured in terms of external Stimuli.
Some companies make their processors such that the clock generator circuit cannot be tweaked at all to minimize failure etc., The limitation is more of a design rather an a functional limitation.