Starting with SPIN on the Parallax Propeller

• Share on Facebook
• Share on Twitter
• Share on Google

In my last article I introduced hobbyist veterans Parallax and their Propeller Microcontroller. The oft-overlooked multi-core gem is available in many form factors, but I got my hands on the Arduino-shield-compatible ASC+ to test.

I imagined that this article would be about C, and the new-fangled C compiler and development tools that have all but replaced Parallax’s house language, SPIN, and Parallax’s own development tools. But then I found myself intrigued by the SPIN language, and by Propeller Assembly and couldn’t help but dig deeper. So, I’ll reserve my C tinkering with blinky lights for the next article and instead walk you through my journey of discovery with SPIN. This is something of a brain dump, so apologies if it’s erratic and poorly structured, otherwise I hope you enjoy!

This article isn't going to detail how to get started, but rather an attempt to make you want to get started!

What on earth is SPIN?

SPIN has been described as a cross between Pascal/Fortran and BASIC. I’ve no experience with Pascal or Fortran, but I can detect a little of BASIC’s DNA within the language. It’s no surprise that Parallax would take this direction, given their strong association with BASIC through the BASIC stamp microcontroller. SPIN is clearly a beefed-up BASIC that I'd guess was designed to be at least somewhat familiar to their existing users, while working in a whole lot of useful syntax sugar and, of course, support for the multi-core nature of the Propeller.

SPIN is compiled into bytecode and executed by a software interpreter which is stored within the Propeller’s built-in ROM. This interpreter is copied to each cog ( core ) that needs to run SPIN. The astute should spot two potential “problems” with this setup- first and foremost, precious memory is being expended on the interpreter, and second, interpreted languages are inherently slower than their raw machine-language counterparts.

Contrary to the first point above, however, SPIN can actually be more space-efficient than Propeller Assembly. A SPIN opcode is only one byte long, with optional byte-long parameters following it. Propeller Assembly opcodes, however, are always 4 bytes long.

I put this to the test fairly unscientifically with an I2C driver available in both SPIN and PASM. The PASM driver compiled to about 1000 bytes ( 250 longs ) and the SPIN driver compiled to 612 bytes ( 153 longs ). Now these are functionally similar, but not exactly equivalent libraries, but it illustrates a point- you can, if you wish, trade performance for size.

Except that you don’t need to do this with the Propeller. The multi-core design is ingeniously architected in such a way that you can use PASM for lean bits of code you need to run quickly, and SPIN for bulky chunks of code that aren’t performance critical. Any cog ( core ) can run one or the other, and running a chunk of assembly on a cog is as simple as telling it where to look. At runtime the assembly opcodes are copied from the primary code memory into the cog you’re starting, and then executed.

Propeller Magic!

This leads me onto one of my little Propeller discoveries ( I’ve had a number of pleasant surprises playing with this Microcontroller ), which I happened upon by chance while playing with some basic Blinky examples in PASM.

Because the assembly is copied from memory to the cog in which you want to run it, and because even data flashed to the EEPROM is copied into the Propeller main memory before you actually run it, something magical is possible. You can modify assembly opcodes at runtime before sending them to a cog.

The practical upshot of this is slightly bonkers. You could, for example, run a serial terminal monitor on one cog, accept packets of assembly code, execute them on other cogs and return the results. Now, I’ve not tried this and couldn’t think of a reason why you’d want to, other than it’s cool, but... well... it it’s cool!

My first steps with SPIN

Now it’s probably time to cut the waffle and get to the point. Working with SPIN on the Propeller requires, of course, a compiler and an IDE.

Now, there are great tools out there for the Propeller, but Parallax don’t make it particularly straightforward to find them. The ASC+ product page, which was my starting point for information about the board I’d been given to test, links only to a dry schematic ( none the less useful ) and a somewhat crusty wiki page that recommends either Brad’s Spin Tool, which was seemingly last updated in 2010 and decidedly crusty ( although perfectly functional ) or Parallax’s own Propeller SPIN Tool, which is Windows only and apparently last updated in 2010.

I downloaded both of the above, using Parallax’s own SPIN Tool quite happily on Windows, and then switching to Brad’s Spin Tool on my Mac. Both of these applications worked perfectly fine and allowed me to get a brief look at SPIN, which appeared daunting at the time, but I quickly abandoned them and switched to the C/C++ capable SimpleIDE. Until a couple of days ago...

I’d had a sudden urge to try SPIN again, and it was through a Parallax news post, of all things, that I discovered they had a recently-opened GitHub account full of juicy open-source software repositories. If you were around when Arduino first landed and was being touted as “The Basic Stamp Killer”, you’ll know that, aside from price, one of the major criticisms of Parallax’s BASIC stamp offering was the lack of open source software and, more so, the lack of anything other than Windows support. It’s taken them a long time, but Parallax are finally beginning to embrace, support and publicise the growing effort to make their products easier to use and more widespread.

I found it surprising that only the new post really drew attention to this GitHub goldmine; I’ve been involved in evaluating alternatives to the AVR at Pimoroni, and one of the biggest considerations is the availability of good tools. Parallax should be beating makers around the head with this software, waving their arms, and shouting from the rooftops about it, it’s a big deal! Okay, so it was only announced a couple of weeks ago, but when it comes to selling makers a shiny Arduino alternative, then the availability of actively maintained, multi-platform software support is second only to good documentation and support.

Parallax have nailed the latter; their forums are a vibrant and bustling hive of Propeller and BASIC Stamp veterans, all eager to share their passion for the devices. Even Parallax’s own engineers drop in from time to time, how often does Joe-maker get to talk to chip designers at Atmel?

Stumbling upon Propeller IDE

So, after much deliberation, exploration and several good barks up several wrong trees I arrive at Propeller IDE ( https://github.com/parallaxinc/PropellerIDE ). For the remainder of my Propeller articles I’ll be talking about either Propeller IDE, or the PropGCC-based Simple IDE- everything else, functional though it may be, seems outdated, unmaintained, out of fashion or poorly documented.

Propeller IDE is an open-source IDE for the Parallax propeller that’s built around OpenSPIN, an open-source compiler for the SPIN language. Unlike the, *cough*, festering sack of ungainly awful broken and horrid Java kludge that is the Arduino IDE ( I tend to use AVR GCC and any other editor ever and avoid the Arduino libraries completely ) the Propeller IDE is lean, fast and somewhat more capable.

Okay, to be fair the Arduino IDE is at somewhat of a disadvantage by comparison, having to support multiple Programmers, and multiple different architectures really holds it back. With the sum total of one single Microcontroller to support, the Propeller IDE is expected to be much more focussed, far more uncluttered and much easier to get started with.

And it really is. I love using Propeller IDE. It touts everything from uncomplicated code-compiles, to automatic detection of the serial port your Propeller is connected to. It boasts extremely fast, straight-to-memory uploads of code. It brings a tear to the eye with a one-click code-upload and serial terminal button, and leaves minds thoroughly melted with tree-view browsing of objects and methods, and auto-complete, and ... I think that’s actually everything I’ve learned about it to-date.

The only thing Propeller IDE isn’t, is aesthetically pleasing. Somewhere, at some point during the inception of the SPIN language someone decided that sections should be highlighted with garish and obnoxious background colours.

Let me just fill you in on what I mean by sections, since I glossed over that in my summary of the SPIN language. A section is a portion of the code with a very specific task and SPIN has a number of these. The CON section is where you define all your constants, the VAR section all your variables, the OBJ section all your objects, each PUB section describes a public subroutine ( you might know them as a function or method ) and each PRI section describes a private subroutine. You can also have a DAT section, where you can simply switch seamlessly into PASM and write assembly to be loaded into cogs for those time-sensitive tasks.

I love the section structure, it promotes good practises and keeps code tidy and readable. There’s also something brilliant about the background highlighting, the alternating colours make it really, really easy to visually parse code, and any two adjacent PUB, or PRI sections will have alternating shades of the same colour to make it obvious where one subroutine ends and another begins.

Unfortunately it looks horrible. Fortunately, however, PropellerIDE is open source... so tweaking these colours to a simple dark-navy-blue alternating pattern shouldn’t be too much of a struggle! I must try!

Incidentally you can also have adjacent CON sections, and these are handled with alternating shades... why in the world you’d ever want to do this is beyond me, but it’s handled gracefully if you do.

Wrapping up!

Okay, I think I’ve written quite enough for one post. The important points to remember from this wall-o-brain dump is that the Propeller is cool, the software is painless, responsive and fast, and Parallax are clearly making every effort to appeal to the maker community in order to, perhaps, make up some ground while Arduino appear to be somewhat grasping for direction and meaning ( I love Arduino, but I feel they’ve really lost the plot lately ). I found it easy enough to find the guidance I needed to get started with SPIN, even with the Parallax forums being offline for the past few days, and I feel that it’s really quite a good prospect for a maker looking to stray away from the trendy brand-name platform.

Disclaimer

Although Parallax were kind enough to supply me with an ASC+ to play with, they are neither paying nor encouraging me to extoll the virtues of their product. I use AVRs on a regular basis as part of my job at Pimoroni, but am always ready to get excited about something different- these articles serve to chronicle that excitement, and hopefully instill it in you.

« Back to index Posted on 2014-11-22 by Philip Howard