Who runs their MCU faster than the default speed?

[corrado33]

Today, as I was cutting grass (the time for all intellectual thought) I was wondering, who wouldn't want to run their MCU at it's fastest clock speed for a robot? 

I'd say all (fun) robots have some sort of sensor.  So why not get that sensor data back faster?  ESPECIALLY for important ones like drop off sensors!  You wouldn't want your robot falling off of the edge.  I mean I'm sure the slower clock speed is still plenty fast for detecting these things.

I mean sure, if you're building something with no sensors, and just has to measure out relatively long periods of time, you'd want the slowest clock speed.

The atmega8, for example, defaults to 1MHz, but it can be run up to 8MHz off of the internal oscillator. 

What's the disadvantage of running it faster?  Why would you ever want 4MHz?    How fast do you run your MCUs?

I'm just wondering because if I want to program something robot like, I might as well start with it at 8MHz. 

Actually, now that I think about it, is there a way for the software to read the clock speed?  That way you could switch it and keep pauses the same amount of time.  (Without manually changing them). 

[Soeren]

Hi,

Overclocking microcontrollers is an old idea from back in the days where it mattered.These days, there's no reason to, just select a faster controller.

The disadvantage of overclocking (which it only isif you go above the specified max. clock frequency) is that the current consumption rises (almost logarithmically in some instances) and the heat takes a good cooling scheme.

"Why would you ever want 4MHz?" - 4MHz isn't all that much if you wanna make eg. super precise timing.
I do have a 40MHz project on the side bench that I'd like an XMOS for, or at least a 100MHz capable core for, to get a better resolution, but with the PIC18F2220 that I have already, the limit is 40MHz and anyway, it should be replicable by "anyone", so I'll stick to the '2220 (unless I add USB, which would be nice, as the data it captures have to go into a PC).

To get a controller to find its own frequency, you could reference a counter to eg. a cap charging through a resistor - the count you reach will be a measure of its clock.

On some of the newer controllers, you can switch the clock speed and I'd be surprised if there's not a register to shift and read the clock from.
But... If you wanna go faster, don't slow down just for delay timing - Use eg. a compiler directive to set some parameters according to the clock speed


Before you speed up at all, do consider that even a measly 1MHz means 1,000 clocks in a single millisecond.
For average type sensors (i.e. no video etc.) there's no real need for extreme clock speeds and you should always calculate the max. needed speed, when starting out a project.

[TrickyNekro]

I'll just add a quick reply there. clock speeds are only relevant to what you measure based on an acceptable accuracy. For example, if you want to count months, it would be nice to have a clock that tick every day. Of course you can have a clock that ticks every microsecond,but how practical would that be. On the other hand,if you want to count hours and your clock ticked once every day, that could totally mess your readings.

As a summation of the above, you use the right clock speed when it only matters to. If not, you are doing something wrong or like to waste resources for nothing. Your call.


Best Regards,
Lefteris, Greece

[Admin]

The ADC, or analog to digital converter, becomes less and less accurate the faster your measurement. It is dependent on the charging of capacitors within the microcontroller.

But the reading of sensors isn't why you'd want a faster controller, but the processing of huge amounts of data - ie computer vision for example. But if you go to fast, the mcu could become unstable and on rare occasion write a 0 when it should be a 1. The clock could also become unstable, interrupts might fail to trigger, the UART might be mis-matched, etc.

[vinniewryan]

I'm working on a 4-prop UAV that requires a 64-MHz processor. It's doing about 600 calculations per second and processing pixel data, comparing pixels, using trig to find edges and shapes in the pixel grid, monitoring power to each motor, revolutions of each prop, tracking timing for internal functions, transmitting and receiving wireless data to and from a computer/ controller, and much much more. This kind of application requires a high-speed MCU because of the load of processes needed to run simultaneously. Typically when making a prototype, the last thing I do is slow down the processor clock speed once I know the requirements of the specific application. I wouldn't want to run an MCU at 40MHz powered by button cells just to blink an LED when an input is detected as that would be a waste of energy.

[TrickyNekro]

But the reading of sensors isn't why you'd want a faster controller, but the processing of huge amounts of data - ie computer vision for example. But if you go to fast, the mcu could become unstable and on rare occasion write a 0 when it should be a 1. The clock could also become unstable, interrupts might fail to trigger, the UART might be mis-matched, etc.

I really had in mind high speed multi step encoders when posting this... And encoders in my book are sensors...
And there are times you can't be dead sure that they not misfire so you kinda use pin polling.
If you need processing power you target first microcontrollers with bigger natural bus... (16bit, 32bit, 64bit.....)

[WaterPig Master]

I often run PICs at 4MHz as the internal clock divides by 4, giving me a nice simple 1000 instructions per second — adequate for my simple robot requirements and makes timing very very easy! I have been using 8MHz recently, though.

Thanks,
Barnaby

[Soeren]

Hi,

I often run PICs at 4MHz as the internal clock divides by 4, giving me a nice simple 1000 instructions per second

When I run PIC's at 4MHz, I get the full one million, so you really have to complain to Microchip 
(Or your math teacher )

[corrado33]

Hi,
When I run PIC's at 4MHz, I get the full one million, so you really have to complain to Microchip 
(Or your math teacher )

I noticed that too.   

Anyway, I was reading atmel's document about noise in electrical circuits and I read something interesting.  It said that to reduce overall system noise, run your MCU at the lowest speed possible for your application.  So I guess that's a reason not to crank it up.   

[Soeren]

Hi,

Anyway, I was reading atmel's document about noise in electrical circuits and I read something interesting.  It said that to reduce overall system noise, run your MCU at the lowest speed possible for your application.  So I guess that's a reason not to crank it up.   

That's really a no-brainer
Running a micro at any speed will have the same noise each shift, but the less shifts per time unit, the less overall noise of course

If you shield the complete board (or give a damn about EMC), the noise shouldn't be the reason to avoid over-clocking.