different clock speeds - why?

RobertW

Hello,

It seems like for as long as I have read this forum, there have been questions related to clock speed.· Some want to give their chips an eletronic heart attack by speeding things up·and some are looking for the slowest they can run and still have their application run.· My·basic question·is why?· I see that by using pll_ _ x an external clock can be sped up to 80MHz for example, but then why are there options for 1x, 2x, 4x, 8x, etc.?· Is this to conserve power?· I can understand that a faster clock speed can handle more 'calculations / processes' per second, etc., so faster is better...· Also, if the internal clock of 20kHz and 12MHz are only approximate speeds, then why were they included in the design of the chip?· Or, is something required for the internal workings of the chip?· Not trying to sound negative, just curious.

Lastly, how do you know how fast the clock speed should be for an application?· I know that many (if not all)·of the files in the OBEX have this defined but what about new objects?· I would think there is a better way then trial and error.

Thank you.

SRLM

Mostly, clock speed decrease is in an effort to save power. IIRC there is a graph in the datasheet that details clock speed in relation to current consumption. The internal RC clocks are included so that you don't need a crystal, and probably the bootloader needs at least one of them. For certain applications like button monitoring and simple LED displays, the processor speed is irrelevant.

As for the speed you should be running at, it depends. If you need to conserve power, than lower clock speeds are good. If you need high performance, then faster clock speeds are good. If you don't care, than 80MHz is the best.

Ken Peterson

Not to mention EMI concerns. Faster clock speed puts more noise on the power lines and can cause interference in radio receivers and sensitive equipment. In automotive applications the rule of thumb is to run it as slow as you can and still get the job done.

Ken

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"I have not failed. I've just found 10,000 ways that won't work. "
- Thomas A. Edison

Mike Green

The tradeoff is simple. Higher speed allows the chip to do more in a given period of time. Low speed takes less current, thus less power given a fixed supply voltage (in a square law relationship). It's a little more complicated in that the cogs (processors) can go into an idle state waiting for either time to elapse or some change in I/O status and this state uses very little power. Some things, like video output, require a minimum clock speed to work properly. The datasheet for the Propeller has some nice graphs showing current consumption vs. clock speed and vs. number of cogs active and there's some information on the power consumption of the non-cog portions of the chip that have to run all the time whether a cog is active or not.

Usually the comments at the beginning of the source code for an object give some information about the requirements for the object. Most objects are described for an 80MHz system clock. Some will work with a slower clock, most (but not all) will work with a faster one. The FullDuplexSerial driver for example will support Bauds over 115KBps at 80MHz and will adjust for lower clock speeds. At 40MHz, it should support Bauds over 56KBps. The Simple_Serial driver will do 19.2KBps at 80MHz, but probably no better than 9600 Baud at 40MHz. The TV driver will work with system clocks above 16MHz, but is limited in the number of characters in a line below 80MHz. There's just not enough time to produce the pixels needed.

The internal clocks are provided for situations where exact timing is not important. In particular, the RCFAST clock is used for the bootstrap process (downloading from PC or EEPROM). The communication between the Propeller and PC is done in a self-clocking manner so the exact system clock speed is not important. The EEPROM is not sensitive to clock speeds, you just want to do the download relatively quickly. The RCSLOW clock is intended for very low power applications where the Propeller has to monitor some inputs periodically. It's very simple for the Propeller to switch clocks, to turn the crystal oscillator on and off so an application can sit using the RCSLOW clock most of the time then, in response to an input, turn on the crystal oscillator, allow it to stabilize, then switch to a crystal-controlled 80MHz clock for a short period of time to send (and maybe receive) some high speed serial information. When the transaction is done, it can switch back to the RCSLOW clock and turn off the crystal oscillator, then wait for the next input while drawing only microAmps.

Unless you have a reason to do otherwise, you should use an 80MHz system clock. That's the highest system clock supported for the full temperature and supply voltage range. You should allow for other system clock values if possible, probably at least 40MHz to 100MHz. Over a narrower temperature range (0C to 70C), the Propeller can use a 6.00MHz or 6.25MHz crystal for a system clock of 96MHz or 100MHz and many people are using these because of the higher throughput, particularly for emulators (like Zicog for the Z80).

RobertW

Thanks for the replies. I knew that the slower internal clock is good at monitoring switch inputs and LED outputs and that a faster clock was needed for serial communication, but I never thought about changing the clock speed within an application like Mike suggested (slow internal clock while waiting and faster external clock only when needed, etc.). Sorry, probably a no-brainer to most, but, I'm still learning as I go.

Thanks again for the replies. I have always appreciated the helpfulness of this forum.
-Rob W.

photomankc

I have a battery powered project just as Mike described.· The Propeller is there to watch the batteries and if they get low enough to hold down the shutdown pin of the 5v regulator to send it into low power shutdown.· In order to do this it has to stay active enough to hold that line low but it also has to draw very little power to do it so it can last a few days and not kill the batteries just holding the shutdown.· In this 'sleep' state it draws 60 microamps total for the system.· When it is running normally it provides battery state info when requested via some buttons and some other functions as well.· 40Mhz dropped the current consumption of the running system from ~30mA to ~14mA.· That made it a reasonable level of loss in battery run time to get the desired operation.· It would do even better at 20Mhz drawing only about 8mA but that was too slow for some of the support code to do it's thing.

Flexibility is nice.·

HollyMinkowski

Lower speed = longer battery life.

I have some pico-power AVR projects that can run years
on a single tiny battery. Mostly they sleep with just a slow clock
running but when called to duty they jump to 20mips for a second or two.

You can do much the same with the prop by changing clocks
while the application runs.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Where am I? Where am I going? Why am I in a handbasket?"

ElectricAye

Thanks to everyone who answered this question. I was wondering about this, too!