New processor architectures are rare, especially in the microcontroller arena. But Parallax created a chip that could rotate right into your next application. The Parallax Propeller consists of eight identical RISC-style processing units called cogs (see the figure).
The chip runs on 80 MHz, but it only consumes 75 mA with all cogs running. If you cut back to one cog using the internal clock at 20 kHz, the power drain drops to the 3-µA range.
Each cog can access all of the 32 I/O pins. Usually, though, an application running on a cog will use only a few pins. A typical example of a cog application is a full-duplex serial port interface that would utilize two pins. Hardware flow control adds two pins. Want two serial ports? Fire up another cog.
A COG IN THE MACHINE This chip takes a new approach to running code in multiprocessing applications. To start up another cog, you just specify what routine to begin executing, or the address of an assembly program, and it automatically loads up and begins executing code internally. The cog can later shut itself off so that it can be reused for some other purpose.
Code can be run on a specific cog. Generally, though, the next idle cog is used instead, because each cog is identical and has the same access to memory and I/O pins. A cog needs to be identified so that another cog can start or stop it, although most communication is completed using the shared system memory.
Access to the shared resources— memory, semaphore bits, and other cogs—is provided in round-robin style, with each cog getting one time slot. This makes system access significantly slower than access to local cog memory, but it simplifies the architecture. The Propeller contains a single memory for code and data.
Self-modifying code is an option. This tends to be less of an issue given the limited memory size. Code modules are likely to be small and concise. In fact, tight coding will be the norm. There's no hardware stack support, but a co-routine switch instruction allows a stack to be implemented in software if necessary.
TAKING A COG FOR A SPIN Don't take off your propeller hat yet. This chip takes a two-level approach to programs.
Spin, a Basic-like programming language with recursion, is executed by a Spin interpreter program that runs in a cog. Spin code resides in shared memory, so Spin runs slower (60 KIPS) than cog code (20 MIPS). Spin applications handle the high-level portion of the application, with cog code handling peripheral control.
Spin isn't multithreaded, but multiple Spin interpreters can be run on different cogs. By default, a Spin interpreter runs on a cog when the chip starts up. Actually, the startup process is a bit more complicated, since the ROM contains a boot loader. Application code and data can be automatically loaded into system RAM via a serial EEPROM or serial port.
Parallax supplies its own development tools designed to handle a mixture of cog and Spin code. The development environment is both polished and rough—its debugging features could use some work. Still, the integrated development environment contains neat features like automatic code documentation support. The hardware architecture and software environment is different enough so that even experienced developers will need to stop and think—and that's a good thing.
The Propeller can perform some surprising tasks, like drive a VGA display from software. It also takes applications like motor control to a new level. Ultimately, though, a new mindset is necessary to take advantage of the architecture.
A low-cost, USB-based dev kit is available for the Propeller. Also, the board contains its own serial EEPROM. Time to fly!
Building in one or more HW UARTs into a chip that may end up in an application that doesn't need them, THAT is inefficient. (It would also have made the chip more expensive, and delayed launch with months, at least)
Examine ANY microcontroller project made the last 5 years, and you'll see that there's PLENTY of spare computing capacity. Now examine all of them again, and see how many of them uses a serial port? How many of those again have the spare processing capacity to 'bit bang' a pin to create a SW UART? Plenty, I'll wager...
What else did you want to stuff into it and waste silicon real-estate with? SPI? I2C? 1-Wire? (It has all been implemented in SW already)
DMX? (250Kbps) Done...
Trygve Henriksen -August 07, 2006
using a 32 bit core for uart purposes is a very innefficient way of implementing this communication peripheral
Anonymous -July 13, 2006
Your Comments:
Enter the text from the image below
Please refresh the page if you have trouble reading this text.
Search Electronic Design
Web Seminar
Sponsored By:
Title: Read Pacing: A Performance Enhancing Feature of PCI Express Gen 2 Switch Devices
Reprints
