Glenn Butcher

Home
About Us
foo
incexp
Journal Archive
onedrive
Photographs
Picture Albums
Slashdot Quotes
slideshow
Weather
Resume (.pdf, 17K)
Pictures

Transitory

Teaching

Research
Dissertation (.pdf, 446K)

News
CNN: Technology
CNN: Top Stories
COS Gazette: Headlines
COS Gazette: Metro
CSM
Honolulu Advertiser
Internet News
LWN
Newsforge
NPR News
NY Times
PCMag: Reviews
Slashdot
Space.com
The Hawaii Channel
Toms Hardware: Articles
Toms Hardware: News
Washington Post
Yahoo: Boeing
Yahoo: Missile Defense
Yahoo: Tech Tuesday
Yahoo: Top Stories

Software
HexDump
Home DNS
InOut Board
LOCOMGR
RRController
ttygcc
UBW IR Receiver
Walkabout
website
Gantt Chart
Trainsheet
Google Map Test

Railroading
LaBelle Long Caboose
NG TerraServers
Cumbres and Toltec Maps

Other Stuff
Gumbo Recipe
Links
Salsa Recipe
Weather Station
Website Tags

Software/RRController

Note: This page describes work I did some time ago, resulting in an assembly language program that implements the described functionality. Time and technology has marched on, and there are better chips (PIC, AVR, etc.) for the purpose. Therefore, I have not posted the code for download; I maintain the page simply to describe the approach.


RRController is a specially programmed Motorola MC68HC705C8 microcontroller designed to be used as a building block in model railroad control applications. RRController is designed to function in a RS-422 network at a user-selected address, performing tasks specified by messages sent from a master controller. The message protocol used is the SYNC-SYNC-STX...ETX protocol specified in Dr. Bruce Chubb's book, "Build Your Own Universal Computer Interface." In response to master controller messages, RRControllers can provide dumps of selected portions of memory, execute microprocessor instructions, or load and execute "personality programs" that define processing to take place on the RRController. The RRController can continue to respond to master controller messages while a personality program is executing. This allows for RRControllers to be used in a wide variety of model railroad control applications with minimal development effort.

1. Device Specifications.

This section describes features of the MC68HC705C8 microcontroller specific to its use as a RRController. Please refer to the Motorola publications MC68HC705C8/D, "Technical Data," and M68HC05AG/AD "M68HC05 Applications Guide," for information on the basic microcontroller.

1.1 Pin Designations.

The RRController firmware makes special use of the following MC68HC705C8 pins:

Pin DesignationsPin NumbersDescriptionUsage
PD2-PD5,PD731-34,36Device AddressProvide DIP switch-settable device addresses from 0-31.
PC028Transmit EnableEnable RS-422 transmitter. User must ensure that use of Port C does not interfere with operation of Transmit Enable.
RDI,TDO29,30Network InterfaceInterfaces RRController to the master controller. The MC68HC705C8's Serial Communications Inteface (SCI) is not available for application use.

1.2 Interrupts.

The timer, IRQ, and SWI interrupts are available for use by personality programs. When the RRController is reset, the EPROM vectors for these interrupts are set to jump instructions located in the MC68HC705's high RAM. These jump instructions are initially set to jump to a NOP-RTI routine located in EPROM; the addresses can be changed by a personality program ('I' message) or an Exec message subroutine to point to a user interrupt handler loaded anywhere in RAM. The RAM addresses for these jump vectors are:

InterruptAddressDescription
TIMER$0109TIMER JMP high-order byte
$010ATIMER JMP low-order byte
IRQ$010CIRQ JMP high-order byte
$010DIRQ JMP low-order byte
SWI$010FSWI JMP high-order byte
$0110SWI JMP low-order byte

1.3 Network Interface.

The Serial Communications Interface (SCI) of the MC68HC705C8 is configured by the RRController firmware at RESET for 4800 baud, 8 data bits, 1 stop bit, and no parity. The Receive Interrupt Enable (RIE) bit is set, and the interrupt handler software tests for Receive Data Register Full (RDRF).

2. Message Protocol.

The RRController firmware implements the slave side of a master-slave message protocol based on Dr. Bruce Chubb's Universal Serial Interface Card (USIC) described in "Build Your Own Universal Computer Interface." The general format of messages is:

NameRange of ValuesDescription
SYNC$FFSyncronization byte.
SYNC$FFSyncronization byte.
STX$02Start of message text.
DA (UA)Dev Addr + $41RRController device address. (0-31)
MSGTYPE'I', 'P', 'R', 'E', 'U'Message type
DATA...0-$FFBytes required by message type.
ETX$03End of message.

The firmware routines for message handling are interrupt driven; the interrupt architecture of the MC68HC705C8 saves the A and X registers on the stack before the routines are invoked, and returns their original values upon interrupt exit. Messages are stored in RAM starting with byte DA at $0111, except for 'I' messages; starting with DATA, they are stored in the low RAM starting at $30. RRController implements Data Link Escape (DLE) processing for DATA bytes as described in Dr. Chubb's book. Receipt of the ETX byte triggers processing based on the message type.

RRControllers implement the following message types:

Message TypeSend/ReceiveMessage NameDescription
IReceiveInitializationDATA contains a personality program to which the RRController transfers execution based on the jump address. The personality program must fit within the available RAM between $30 and $FF, leaving room for the maximum anticipated stack size.
EReceiveExecutionDATA contains a subroutine to be executed starting at $0113 of the message buffer. The last data byte must be an RTS instruction. RRController calls the subroutine; when the subroutine returns control, the firmware returns control to the personality program at the point where the interrupt occurred.
PReceivePollDATA contains a start byte and a stop byte corresponding to the section of memory to be returned in an 'R' message. Only memory from $00 to $FF can be returned this way.
RSendReceiveDATA contains the contents of memory from the start byte to the stop byte, inclusive, specified in a 'P' message.
UReceiveUser CommandNo DATA, triggers the software interrupt (SWI). The software interrupt must be previously installed and its vector loaded into $010F.

3. Application Development.

Using the message protocol described in section 2, RRControllers can be configured to perform almost any control activity required on a model railroad layout. Simple bit I/O applications do not require a personality program; 'E' messages are used to transmit subroutines to set and clear I/O port bits and bytes, and 'P' - 'R' message exchanges are used to retrieve I/O port input. Personality programs allow the RRController to handle logic based on local inputs, freeing the master controller from having to service the logic requirements of each individual port and/or bit.

RRController application development usually requires the following steps:

  1. Specification of I/O port utilization. Ports and/or pins are designated for specific input or output, and interface hardware is designed for each.

  2. Controller board development. RRController requires a minimum amount of peripheral circuitry for operation; the developer is referred to the Motorola publications for applicable circuits. The RS-422 interface is most effectively implemented with two 75LS176 RS-485 transcievers; one hard-wired to receive the master controller message input, connected to RDI, and one hard-wired to send RRController output messages, connected to TDO and PC7 for transciever enable. The input and output ports can be connected to a wide variety of circuitry to control signals, turnouts, and receive block occupancy and switch inputs; the developer is referred to Bruce Chubb's book, "Build Your Own Universal Computer Interface" for guidance. Controller boards can be easily point-to-point wired using prototyping boards or wire-wrap. One suggested configuration would be to design a standard RRController board containing the RS-422 interface, address DIP switch, RRController and associated support circuitry with Ports A through C wired to a header block; the interface circuitry for the particular application would then be hosted on a separate board, connected to the RRController board through a ribbon cable.

  3. Personality program development. Using the I/O port designations, a personality program is developed that reads port inputs, and sets port outputs according to the needs of the particular application. Personality programs are almost always infinite loops, performing the required logic over and over again.

  4. Interface message development. 'E' message and 'P' - 'R' message combinations are developed to allow the master controller to provide input to the RRController application, and to receive status for display and subsequent processing. The RRController processes these messages as interrupts to the normal execution flow of the personality program.

  5. Network implementation. Controller boards using RRControllers are built and interfaced to the inputs and outputs they are to service. Each controller board is connected to the master controller programmed to send and receive the protocol messages developed for the application via a RS-422 network. RRControllers initialized with different personality programs can exist on the same network; it is up to the master controller software to interact properly with each RRController.


As of: 10:30 pm, 9 December 1998.
Questions? glenn_butcher@pcisys.net