Propeller Applications

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.

In its purest form, a Propeller Application is written in one or both of the Propeller's native programming languages: Spin and Propeller Assembly. They can be used together, or Spin can be used by itself. This documentation is written with respect to using Spin and Propeller Assembly.

 

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).

The Propeller Application image resides in the Propeller's Main RAM, not in Cog RAM. Spin code (in Main RAM) is executed by the Spin Interpreter; an assembly language program running in Cog RAM that fetches and executes chunks of code from the PUB and PRI blocks of the application from Main RAM. However, Propeller Assembly code is loaded from Main RAM (the application image) into Cog RAM and executed directly, which is why it is so much faster than Spin code.

An application's initial entry point (the code in which execution begins) is always the very first public method in the top object. It doesn't matter what that method is called, but developers often call it "main."

A top object is simply the first object in the Propeller Application; code execution begins at the first public method in the top object. It is called the "top" object because it determines what "building block" objects are also included in the application "beneath" it. The top object also configures initial global settings for the application, such as the clock speed, and is usually the object that "lives" for the entire length of time the application is running. Every Propeller Application has one, and only one, top object.

No. There is no direct relationship between objects and cogs. Applications are limited by the size of the Propeller chip’s Main RAM, which is 32 KB (kilobytes) and not by the number of object files that make up the application. An application may consist of a single object, or many objects, as long as the total size of the application is less than 32 KB. An application, whether made from one object or many objects, may execute with one, two, or up to eight cogs depending only on the collective objects' "requests" to launch cogs.