■ FIGURE 2.
rtc[T_TICS] := 0
rtc[T_SECS] := 0 #> hfcp.p_read(1)
rtc[T_MINS] := 0 #> hfcp.p_read(2)
rtc[T_HRS] := 0 #> hfcp.p_read(3)
if (n == 0)
longfill(@rtc, 0, 4)
We start by retrieving the command and parameters
count from the message, then drop into a case structure that
handles the messages known to this node. The parameters
count helps further qualify each message, especially in the
case where one or more parameters are required.
As you can see, it's very straightforward stuff.
Remember that we are calling this from the middle of our
main loop, so we dare not dally. Let me point out a little
"Easter egg" that I neglected to mention earlier.
If you look at command #9, you'll see that it takes a
single parameter and then calls the dig_set method (new to
the LED modulator) to set the LEDs. This method treats the
outputs like a standard parallel port; we turn on an LED with
a "1" bit in the parameter and a "0" bit will extinguish the LED
for that position. So, if we wanted to turn on the MSB LED
and extinguish the others, we could do something like this:
Most of us know that 128 is the MSB bit of a byte,
but what happens when we want to set three or four
random bits, and it's not an easy to remember value? No
worries! The asc2val method in the strings library can deal
with binary values — so long as they're indicated.
I took a page from the BASIC Stamp and Propeller editors:
They allow us to use binary and hex values in our code;
62 January 2012
we alert the compiler by using special symbols. What this
means is that the command above can be changed to:
And, yes, the parser also allows the use of the
underscore character to separate groups of digits in a
number. As with the editors we use, is the designation
for hexadecimal values.
Now have a look at command #90; this requires no
parameters but does give something back (the current
values in our timer/rtc). The write_block method is used to
quickly transfer the working values of the timer/rtc to the
parameters list in the HFCP object. Since that list uses longs,
we use longs for the timer/rtc values to accommodate this
transfer. The next step is to build the output message which —
like the input — will be a string with comma-separated
fields. The difference is that the response string will use "<"
as its header. This allows us to monitor a system and
distinguish between command and response messages.
The build_msg method is used and we will pass the
response address, the command we're responding to, and
the number of parameters to have in the response
message. Now, you understand why we loaded the
parameters first. Finally, we can send the message by using
the str method of our serial object.
So, there you have it. An easy protocol handler that
will simplify talking to your Propeller projects. Have a look
at Figure 2 for an exchange with the demo program.
Of course, there are features we don't have space to
cover, like the ability to set the numeric style (decimal, binary,
hex) of parameters in the response message, etc. I know that
those of you who have experience in data communications
are asking, "Where's the checksum?" You're right. In this
version, that doesn't exist. It's an easy add, though, and down
the road I will take another page from the GPS strings and use
the "*" symbol to indicate that there is a checksum appended
to the message. This will be optional, of course, and will
only apply when the messages are being generated by a
computer — be it another Propeller or a PC on the network.
Okay, then. Load up the demo and start talking. This
"talking" stuff is really a lot of fun and we will continue
next time. If you missed Fred Eady's excellent article on
CAN networking (November ‘ 11), you may want to go
read it as that's where we're headed next. We'll build a
CAN module for the Propeller Platform and I'll show you
how to put it to use. It's really neat stuff.
Until next time, Happy New Year and keep spinning
and winning with the Propeller! NV
JON “JONNYMAC” WILLIAMS
Propeller chips and programming tools