ADVENTURES IN PROPELLER PROGRAMMING SPIN
■ BY JON WILLIAMS
Discuss this article in the Nuts & Volts forums at http://forum.nutsvolts.com.
From time to time, I just want to tell my Propeller project what to do — and
it seems others do, as well. In recent months, I've worked with many who
have asked about passing information between a PC and the Propeller, or
even Propeller to Propeller. My focus will be on the former, that is, using a
terminal to exchange information with the Propeller. What I needed was a
protocol, and there are certainly any number of those available. Cutting right
to the chase, I created my own called HFCP: for Human Friendly Control
Protocol. Yep, cheesy name — but very easy to use. Now, this isn't going to
be appropriate for everything you develop, but for small projects that want to
"talk" to you via your PC, this works really well.
So, what makes HFCP human friendly? Well, it's text based so that we can use a simple terminal to
exchange information. Secondly, it uses (by default)
decimal values so we don't have to decode anything. If
you've ever looked at a MODBUS ASCII stream, you
know what I'm talking about. Of course, I'd love to have
you think that I'm some wildly clever guy. The fact is, I'm a
regular guy who knows a good idea when he sees one.
The idea for my protocol structure came from GPS.
GPS strings (NEMA 0183) are easy to read: plain
ASCII text with fields separated by commas and
terminated with a carriage return. The values are
decimal — easy. Having worked on a GPS parser last
year, I knew that if I adopted GPS string properties I
could adapt some existing code. As you know, the devil
is in the details and it did take a bit of time to get
everything together — especially with the features I
decided to add — but it's done now, ready to use, and it
works very nicely.
A message from the system master (usually a PC) will
start with the ">" character. The header is followed by two
or more fields, and the fields are separated with commas.
Spaces and a few special characters in the message are
tolerated. The structure is as follows:
>target, command, parameters, value1, … ,
■ FIGURE 1.
In my stock version, I can support a
message with up to eight parameters. If
your applications tend to require more
values, you can easily change the P_MAX
constant in the object. What I should note
is that — other than the terminating CR — all
fields are numeric. Thus we have our first,
"Shoot, how do I get around that?" moment
when actually working through a project.
If we want to transmit text in a
message, there is a special message type:
The parameters value is specified as the "@"
character and the text is placed in the
fourth field. Later, we'll see how we can
determine which kind of message was
received (numeric versus string).
Some messages will not require any