William Wong
|
ED Online ID #13329 |
August 21, 2006
Starting cogs is where the Propeller’s novel architecture comes into play. Any cog code can run on any cog since every cog has the same interface to all the IO pins and to shared resources like main memory. Of course, you run into problems if you need to startup more than eight cogs simultaneously but that is essentially having eight tasks running at the same time. If a cog finishes running it simply shuts down and waits until a new cog is needed. A powered down cog uses minimal power so a Propeller only draws its full power complement when it is fully loaded.
Whether a logical cog is dedicated to continuous or transient operation depends upon the application. For example, a VGA display object (yes, a cog is powerful enough to generate video signals on the fly) would run continuously, or at least as long as you wanted to display something on the screen. A transient might be a filter that gets applied to data stored in main memory.
Now Parallax’s idea of an “object” is a bit different than say C++ or Java although there are some similarities. Parallax thinks of an object as a combination of Spin code, cog code, and main memory data. In fact, that is what a .spin file defines. The .spin file also includes constant definitions and documentation making an “object” definition a single file. In fact, the file is more of a class definition since an instance of an object occurs when it is loaded into cog memory and the cog’s local memory contain object’s variables. Shared variables in main memory could be considered class variables in a C++ or Java context. The big difference is that a Propeller can have only eight active objects at a time.
Actually, things are a bit more complicated. The Spin code associated with a .spin file provides the high level interface to an object. The cog code is what is run when it is instantiated on a cog processor. The two interface via the Spin (class) variables. Spin code from any object can call the Spin code of another object but not the cog code. Likewise, an object’s cog code can call functions defined within the object but not functions in other objects.
So if you can get your head around this concept then you are well on your way to coding a Propeller. It is actually quite elegant and simple once you understand it. It just tends to be very different from what you are used to with conventional architectures.
If you haven’t figured it out yet then check out the 400+ page manual for the Propeller. It is available as a free download from the Parallax website. It is actually that large because it gives you all the gory details for the system including the Propeller assembly language reference (i.e. cog code definitions).
In essence, cog code is designed to be tight and fast. The code tends to be dedicated to a particular aspect of the application. More complex problems need to be broken up into objects that will run sequentially or simultaneously in a cooperative fashion. The high level Spin code is designed to be slow but more flexible. Because it is interpreted, it is much slower than cog code but it has a higher code density.
SPINning A Program The Propeller development tool (PDT) (see Figure 7) is designed for editing and downloading a program to a Propeller chip. It does not include a debugger hence I did not refer to it as an IDE (integrated development environment) (see Figure 8). In fact, Parallax does not provide any sort of debugger with the system. More on that later.
Reprints
