IT’S A COG’S LIFE

Following along as Propeller comes to life after reset helps clarify the big picture. The first thing that happens is that the chip looks for either an external EEPROM or PC to fill the entire contents of the on-chip shared RAM (32 KB) with all your application code (i.e., Spin and ASM programs).

Next, a copy of the tiny (2-KB) Spin interpreter is moved from the shared ROM (which also contains math look-up tables and a bitmap version of the documentation font mentioned earlier) into cog 0’s 2 KB of local RAM. If you’re inclined to complain that Spin doesn’t have every language feature, consider the fact that it fits in less than 512 instructions and bite your tongue.

Next, Propeller starts executing the boot-up Spin program. What that actually means is that the interpreter, running in cog 0, fetches and interprets the first Spin program stored in the shared RAM. In other words, from the interpreter’s point of view (running in cog 0), your Spin program is really data stored in the hub’s shared RAM.

At this point, you’re off to the races. That boot-up Spin program can spawn additional programs (Spin or ASM) on the remaining cogs. Spawned ASM programs are loaded and run in their entirety in the new cog. For spawned Spin programs, another copy of the interpreter is loaded into the new cog’s RAM, where it (like the copy on cog 0) interprets Spin code in shared RAM. The fun part is that spawned programs themselves can spawn additional programs, including copies of themselves! With that in mind, one point to highlight is that Spin programs running on multiple cogs can use a single copy of common code held in shared RAM (i.e., multiple copies aren’t required).