About the Propeller P8X32A

The Propeller P8X32A is a multicore microcontroller that excels at parallel processing. It contains eight processors, or cores, (called cogs) which can operate simultaneously at your will. Using the Propeller is like employing a team of up to eight workers for a project; the team members can work in parallel on given tasks and coordinate as needed to achieve a common goal. Being truly flexible and efficient, they can share, shuffle, and dedicate to duties, quietly wait for events, start and stop, and direct each other as needed.

Cogs have exclusive access to their own internal memory and unimpeded access to the System Clock and all 32 I/O pins. Each cog tracks I/O pin states with its own input register and influences pin outputs using its own output and direction registers; the collective of cogs determines an I/O pin's ultimate direction and state.

Cogs share access to main memory in a round-robin fashion through a central hub. Among other things, main memory is used in this fashion for coordination between cogs.

In addition, each cog contains hardware to assist with certain high-speed, repetitive tasks such as signal detection and video generation.

See the P8X32A Block Diagram for a functional view of the Propeller.

Many years of thought and effort went into designing the Propeller to solve the problems plaguing modern embedded system designers. Every aspect of the Propeller was meticulously crafted using elemental concepts and building blocks. Read Why the Propeller Works by designer and Parallax company President, Chip Gracey, for some insight on the thought process and design quality of the Propeller.

In the Propeller chip, a cog is a processor; the Propeller P8X32A has eight of them.

Each cog is identical (except for their unique numerical IDs) and runs independently, so it is possible to have eight different processes executing simultaneously. Each cog has its own internal memory, its own configurable counter module hardware, its own video generation hardware, access to all the I/O Pins and the System Clock, and shared access to main memory (RAM and ROM). The cogs can communicate with each other through Main RAM, can synchronize with each other through the System Clock and Locks (Semaphores), and can even silently monitor each other through the I/O Pins if necessary.

A Propeller Application is a compiled set of one or more objects that is downloaded to a Propeller chip to create an intelligent embedded system. Each object is designed to handle a particular task well; the collective of these objects forms a more advanced system.

The Propeller Application's first object, called the top object, determines the nature of the overall application by specifying any additional objects, called building block objects, and providing management code to coordinate all efforts at a high level.

The Propeller has two native programming languages: Spin and Propeller Assembly. They can be used together, or Spin can be used by itself.

Spin is the high-level object-based language Parallax designed specifically for the Propeller chip. Spin provides control of the Propeller's multicore hardware and encourages the principles of the Propeller's real-time application design in ways that were not represented by existing languages. Spin was inspired by portions of C, Delphi, and Python, and a host of problem/solution scenarios explored by its designers.

Propeller Assembly is the low-level 32-bit instruction set designed specifically for the Propeller chip. Though most of this language's instructions will be familiar to experienced assembly programmers, there are many that are specific to the Propeller's multicore architecture and a few features are unique to the language.

There are also other development environments available from third parties, such as PropBasic, Catalina C, ICC, and 12Blocks (graphical).

An object is any file with a .spin extension that contains comments, data, and executable Spin code and serves as an encapsulation of that data and the methods to operate on it. A Propeller Application is made up of one or more objects. An object may be designed to achieve the goals of the whole application by itself, or it may only focus on a small portion, and be included by another object as part of a larger application. An application’s top object is where execution begins.

A method is similar to a subroutine in other languages. A method is a section of source code that accepts parameters as input, performs a specific function, and then returns a result value. Methods in Spin are declared with PUB, for public methods, and PRI, for private methods. There must be at least one public method in every Spin object. Propeller Application execution begins with the first public method in the application’s top object.

A memory collision occurs when two or more cogs operate on a block of memory at the same time in a way that causes conflict between them.

A cog has exclusive access to its own Cog RAM, so no memory collision between cogs can occur there. However, all cogs share Main RAM; care must be taken to avoid collisions there.

A cog can read or write a byte, word, or long from Main RAM as an atomic operation—a single operation that no other cog can interfere with. In contrast, cogs can unknowingly interfere with each other's successive atomic operations (multiple reads or writes of bytes, words, or longs from Main RAM) since their respective operations are naturally interleaved when accessing a mutually-exclusive resource.

This situation can cause problems if two or more cogs simultaneously perform multiple opposing operations on the same logical block of memory. For example, two cogs may be tasked to cooperate on data contained in a block of memory 10 bytes in length. If one cog starts writing to the 10 bytes while another is reading, timing variations in their respective program loops can easily cause the "reading" cog to read a mixture of both new byte-sized data and old byte-sized data.

To prevent such misreads or miswrites, the cogs must coordinate their efforts through an agreed-upon synchronization mechanism. This mechanism serves as a "flag" to signal when a cog is performing a non-atomic operation on a mutually-exclusive resource. All cogs involved with that resource must check and set the "flag" before proceeding, and must clear the flag to indicate when they are done.

In many situations where memory is involved, a simple solution is to designate a byte, word, or long within the memory block to serve as this synchronization flag, but since that memory-based flag can not be read and written within the same atomic operation (it requires a read operation followed by a write operation) it may not work flawlessly for all situations. For this reason, a dedicated synchronization mechanism exists, called Locks, or semaphores.

The Propeller has 8 global lock bits which can be read and written simultaneously, as a single operation. When used properly, the lock bits can facilitate synchronization between cogs for any purpose desired; not just for Main RAM usage. The lock bits are managed through four commands: LOCKNEW, LOCKSET, LOCKCLR, and LOCKRET.

The Propeller can have up to eight cogs executing processes at any time. This does not limit your application to eight objects, eight Spin methods, or eight assembly routines– just eight cogs executing code at the same time. Some processes may need to perform continuously, like the main program loop, or code that is parsing a constant stream of data. Other processes may only need to occur once in a while; when they are done, the cog’s resources can be freed up for another process.

Each cog also has two counter modules that can each handle a separate high-speed repetitive process in 32 different operation modes, monitoring or controlling up to two I/O pins each. Once the counter modules are configured, the cog may continue executing code while the counter modules operate simultaneously.

So, theoretically, the Propeller chip can be running a maximum of 24 simultaneous processes; 16 counter operations and 8 sophisticated, programmatic processes.

In Propeller Assembly, it is also possible to use the JMPRET instruction to achieve simple multi-tasking in a cog. This logically adds processes to the system, though they are executed sequentially, rather than in parallel.

The Propeller chip does not support traditional interrupts for two reasons:

1. Interrupts were invented as a way to handle multiple events with a system's only processor, without wasting valuable time in polling loops.
2. Interrupt-based systems often burden developers with complicated programming issues that extend development time and inhibit real-time response.

Rather than provide traditional interrupts, the Propeller solves both of these issues by way of its parallel-processing design and the inclusion of dedicated "wait" hardware.

1. Instead of using a single processor to multi task, you can use multiple processors each with a single task– they can "sleep" until their moment arrives.
2. Instead of struggling to solve multiple issues with a single complicated routine, you can solve individual issues with dedicated routines– and run them concurrently in one application.

The Propeller's wait commands put the affected cog into a very low-power state where no further instructions are executed by that cog until the specific event occurs. This makes dedicating processors to specific tasks very efficient and practical. It also means that the Propeller can process multiple asynchronous events with dependable response times, completely unaffected by coincidental occurrences that would cause single-processor, interrupt-driven devices to fail.

The wait commands are: WAITPEQ, WAITPNE, WAITCNT, and WAITVID. They wait for activity from the I/O Pins, System Counter, or Video Generator.

WAIT Instruction Effect
WAIT Instruction	Pauses cog execution until...
WAITCNT	System Counter = Target Value
WAITPEQ	I/O AND'ed with Mask = State
WAITPNE	I/O AND'ed with Mask <> State
WAITVID	Video Generator Ready