Propeller clock speed

charlieamercharlieamer Posts: 2
edited 2012-11-16 - 14:49:04 in Propeller 1
Hi, I am amateur in electronics, and I am transfering from Arduino platform, because of my new project which involves camera, and arduino is too slow to handle it. I've read wikipedia articles about propeller, and I couldn't find propeller's actual speed in MHz. Can you please help me determine it, or someone to simplify these informations for me (from Wikipedia):
The Propeller can be clocked using either an internal, on-chip oscillator (providing a lower total parts count, but sacrificing some accuracy and thermal stability) or an external crystal or resonator (providing higher maximum speed with greater accuracy at an increased total cost). Only the external oscillator may be run through an on-chip PLLclock multiplier, which may be set at 1x, 2x, 4x, 8x, or 16x
How do I choose if I am going to use internal or external clock ? Are these actual values for speed of execution per cog ?
And another thing, I am not sure if this can go on this forum, but still, I couldn't find the answer:
What is the frequency of clock or crystal, which executes code on "Gadget Gangster QuickStart" ?
Thank you in advance, Amer.


  • Mike GreenMike Green Posts: 23,000
    edited 2012-11-10 - 12:24:44
    For most uses, you'll want to use a 5MHz crystal and the 16x setting of the clock generator for a system clock of 80MHz. Although most software is written to adjust for different clock speeds, this (80MHz) is used most of the time. The internal slow clock (about 20KHz-32KHz) is used for power critical applications, but is not accurate or reliable since it's temperature and supply voltage dependent. The QuickStart Board, like most boards, uses a 5MHz crystal. The default for the Spin compiler is to use the internal fast clock (about 12MHz-20MHz), so most programs start with "_clkfreq = 5_000_000" and "_clkmode = xtal1 + pll16x" which sets them for a 5MHz crystal and the 16x PLL setting. Programs can easily switch back and forth from one clock setting to another, but code that depends on accurate timekeeping will lose track of time.

    Most instructions take 4 system clock cycles to execute ... 50ns per instruction with an 80MHz clock. Spin is the most commonly used programming language and is translated into an interpretive code (byte codes) executed by a built-in interpreter with the bytecode instructions taking a few microseconds depending on their complexity. There are several C compilers available as well as other programming languages and tools.

    The Propeller can be overclocked with a more limited temperature range (see the datasheet for test details), careful supply voltage regulation, and good PCB design principles used. 96MHz (6 x 16) and 104MHz (6.5 x 16) have been used.
  • John80John80 Posts: 4
    edited 2012-11-16 - 04:09:25
    I want to incorporate Date and Time into my prop project/device. But it must hold the the data and time for months and years. The device will be battery operated so, I will use a coin cell to hold power when batteries go low or are being replaced, but I don't want time to be lost. Therefore I will need the prop to enter low power mode when turned off. I understand that if I reduce the clock frequency I will reduce power consumption. But if I normally run s 5.00MHz crystal when the device is on how can I suddenly switch to say a 32KHz crystal for low power mode. I cannot use the internal osc as it is not accurate enough... I am trying to avoid having to use an external RTC chip.
  • Mike GreenMike Green Posts: 23,000
    edited 2012-11-16 - 06:09:49
    The power consumption goes up as the square of the clock frequency, so you can continue to use the (accurate) 5MHz crystal oscillator, but with a PLL1X setting so the system clock is 5MHz when the device is "off". You'd have only one cog running with the others either stopped or waiting for some I/O condition using WAITPxx and the timekeeping cog waiting using WAITCNT and "waking up" about once every 30-45 seconds to update the time and date from the system clock (CLK). If you look at the power consumption charts in the Propeller datasheet, you'll see that, when running at 5MHz, a single cog draws under 1mA and the clock oscillator and PLL should draw well under 500uA. When a cog is waiting or stopped, its clock is stopped and it's drawing only a few uA. That's still a lot but may be manageable.

    It's easy to switch back and forth between different PLL multipliers and you lose timekeeping for only a clock cycle or two ... not much if you do that only for turning "off" and "on".

    If that's still too much current, you'll have to use the 32KHz internal RC clock and go to some kind of external RTC or at least a 32KHz crystal oscillator and divider connected to an I/O pin.
  • MagIO2MagIO2 Posts: 2,181
    edited 2012-11-16 - 07:06:04
    You should also tell us what you want to do with the propeller in regards of the camera. For image processing the prop might be a missmatch as well.
  • John80John80 Posts: 4
    edited 2012-11-16 - 08:18:39
    I might need to keep the current down to 100uA or less.
    So could I apply a 32KHz crystal to an I/O pin and update every time it crosses from logic high to low. Then divide the result by 32000. That would give me a second. If I use this for my clock, can I switch from external 5MHZ crystal to internal RC osc. when the device is switched to "low power" mode? Is it possible to switch from external clock to internal during program?
  • Mike GreenMike Green Posts: 23,000
    edited 2012-11-16 - 08:53:41
    Yes, you can switch back and forth between either of the internal clocks and the PLL (actually between any of the clock sources). There are examples in the Propeller Manual. When starting up the external crystal oscillator, you have to allow time for it to stabilize, then you can switch clock sources. The internal clocks run all the time, so you can always switch to them.

    I wouldn't just apply a 32KHz crystal to an I/O pin. It probably won't oscillate. At least use a package of CMOS gates (usually a hex buffer) as an oscillator / buffer. Better would be something like this cheap oscillator / counter that would run continuously at 32KHz with very low power consumption and put out pulses at a selectable submultiple of 32KHz that the Prop would use as its time standard while running off the (roughly) 32KHz internal clock. I would run one of the cog counters off this and periodically wake up the Prop to update the stored time and date and act on any scheduled actions.
  • charlieamercharlieamer Posts: 2
    edited 2012-11-16 - 13:28:01
    MagIO2 wrote: »
    You should also tell us what you want to do with the propeller in regards of the camera. For image processing the prop might be a missmatch as well.

    I have to do both catching frames from camera and process it, but it doesn't have to be in realtime. I've thought of using DRAM for storing a frame. My project requires me to do heavy calculations on picture, and when it finishes with those calculations, start the same calculation on a new frame.
  • KyeKye Posts: 2,200
    edited 2012-11-16 - 14:47:17

    Have you seen the CMUcam4?

    Its a propeller powered color tracking sensor. It interface with a camera module.

    You can find the source code here:

    Additionally, I wrote a simplified interface object to control the CMUcam4 in SPIN that can be found here:


    Programming the propeller is a radically different experience from the Arduino. As an Arduino programmer, you usually use other people's libraries and never have to write your own. This makes programming easy but it also means that you learn less. You you program the propeller, you need to know how the chip works, and how to program it in assembly to really get the full benefit of the chip. You can do some stuff in SPIN, but it won't be speedy.

    That said, the C programming environment for the propeller chip also also available, but not that many libraries have been written for it like the Arduino that make it super easy to use. If rolling your own stuff doesn't bother you too much, then you should be fine in the C environment.

  • KyeKye Posts: 2,200
    edited 2012-11-16 - 14:49:04
    Also, if you are planning to do something way more complex than the CMUcam4 can do, then you may wish to look at other processors.

    It is possible to buffer images in memory, but there are limitations.

Sign In or Register to comment.