■ FIGURE 2. SX-Net power
and RS-485 connections.
One of the great aspects of SX/B is the ability to easily
fold assembly code segments into a BASIC program — that’s
what I did here; the UART code is really a modification of
that found in Günther Daubachs’ excellent book,
Programming the SX Microcontroller. I modified the
buffering to work within the same RAM bank as the other
transmit variables and, for this project, included control of
the MAX489.
In the section at TX_Buffer, the DE pin (called TxEnable
in the program) is taken high with SETB when a byte is
about to be moved from the transmit ring buffer into the
transmitter output (txHi). Since this byte won’t start going
out until the next interrupt, there is plenty of time for the DE
pin to stabilize. The DE pin will stay high until the transmit
buffer is empty (txBufCnt is 0) and there are no more bits to
be transmitted (txCount is 0).
Okay, now that we can receive and transmit bytes in
the background, it’s time to talk protocol. The neat part
about this is we get to make it up, which, in fact, turns out
to be the tough part too; sometimes it’s just easier to work
from an established specification. In my case, I borrowed
quite a lot from Peter’s protocol, making a few changes that
simplify the system and tie into my long-term goals.
The protocol is, essentially, peer-to-peer, so any node
can talk to any other node. This opens the door to all kinds
16 January 2008
of interesting possibilities. The “sender” node will transmit
a four-byte header that is followed by a data packet if
required for the specific message. The entire transmission
is configured as follows:
Receiver
Sender
Message
Packet Size
Data Bytes
Receiver node (1 to 127) + $80
– to designate start of header
Node sending the packet (1 to 127)
Request or Command Message
Number of bytes in data packet (0 to n)
Data used by Message (optional)
The minimum transmission size will be four bytes (the
header): the receiver, the sender, the message, and a zero
when there are no data bytes. The receiver address will
have BIT7 set to designate the start of a new header —
the MIDI protocol uses this strategy and we’re going to
borrow from it.
The node we’re going to create will be a simple I/O
slave that will respond to (valid) commands and requests
from another node. We’ll use a VB program to send the
messages from a PC. Since the node is a slave, it waits
for bytes to show up in the receive buffer and then
processes them accordingly. The first part handles the
basic message header.
Main:
rxNode = RX_BYTE
IF rxNode.7 = 0 THEN Main
Validate_Start:
rxNode.7 = 0
IF rxNode = GLOBAL_NODE THEN Get_Sender_Node
IF rxNode <> MY_NODE THEN Main
Get_Sender_Node:
txNode = RX_BYTE
IF txNode.7 = 1 THEN
rxNode = txNode
GOTO Validate_Start
ENDIFValidate_Global_Sender:
IF rxNode = GLOBAL_NODE THEN
IF txNode <> MASTER_NODE THEN Main
ENDIFGet_Message:
msgNum = RX_BYTE
IF msgNum.7 = 1 THEN
rxNode = msgNum
GOTO Validate_Start
ENDIFGet_Packet_Length:
packLen = RX_BYTE
IF packLen.7 = 1 THEN
rxNode = packLen
GOTO Validate_Start
ENDIFWhen a byte comes in, we need to check to see if BIT7
is set as this indicates the start of the header. When we get
such a byte, BIT7 is cleared and we pull the next byte from
