Embedded Control Using the STD BUS

There are many ways to do embedded control operations. It may also help to 
explain something about what embedded control is about. The main reason for 
all this is explaining where the Standard Bus fits into the picture.


The term embedded control has become the buzz word of industrial controllers. 
These computers, that are dedicated to controlling things that perform work, 
have been around for some time. Almost all early versions were custom built 
for the application to be controled. The first ones were built to control 
lathes and milling machines. The object was getting parts to be built the 
same every time. Humans have problems making the same part the same way every 
time with the same accuracy, typically .001 inches of tolerance.

Setting up the machines in the old days, usually amounted to using some form 
of "JIG" or "PATTERN" for the operator to follow. With computers the jig or 
pattern is contained in a program that runs the machine. The operators job is 
to make sure it is done correctly and stays in specification. The early 
computers had lots of electronics in many cabinets, and yet in computing 
power it was practically none.

The earliest machines I worked on were simply AND, NOR, OR circuits arranged 
in ways to make program decisions. Later FLIP-FLOPS and other more advanced 
logic was added. Giddings and Lewis makes large lathes and for their first 
actual computer control, they got Motorola to allow them to put the 6800 CPU 
design in discrete logic on a single printed circuit board. The design was 
for 16 bit operation, all on a two foot square board.

As you can see these early computers used lots of real estate (very large 
printed circuit boards (PCB's)) and required multiple boards. Typically a 
CPU, MEMORY, INPUTS, OUTPUTS. The inputs were more than just single point 
status that might tell if the horizontal cutting tool had travel too far down 
the lathe. The machines usually had some fancy way of knowing exactly where 
the cutting tool was to within .001 inches. These indicators are called 
synchro and servos and determine small phase differences between two sets of 
signals to know where they are.

The first buses

The first buses were designed by each company for their own products. The 
problem with this approach - no compatible boards, so you had to make them 
all yourself. At first that enabled you to one up your competition until 
things started getting more complex. The more complex and computer like the 
longer the development cycle and chances of loosing your industry position. 
As CPUs moved form boards to chips and the whole computer was possible to be 
on one reasonable sized board, the question then became, why build the 
computer at all. Simply build only what could not be bought.

Both Motorola and Intel were producing their own BUS systems for industry to 
use. These BUSes were controlled by the handshake signals the CPU used. 
Intel's was the Multibus, while Motorola had the Exorcisor Bus (8 bit) and 
the Versabus (16/32 bit). Both have since upgraded these buses and added 
piggy back boards for even more enhancement. They however are the high cost 
or Cadillacs of the industry. They are also large and only BIG companies with 
BIG projects use them.

While Intel and Motorola had the idea big is better, others thought 
differently. Mostek and Pro-Log got together and developed the STD or 
Standard Bus. The idea was small building blocks for small jobs. Only use the 
exact amount of hardware for the project at hand. About 30 other vendors 
agreed with this concept which has kept it very much alive to this day.


For industrial control, there is nothing special about using a BUS. Early 
S-100's found themselves in many industrial situations. I sold Teletek 
systems to a cloth manufacture for their weaving systems. In fact some are 
still running today. The not so good ISA BUS or the bus used in most PC 
Clones is finding it's way into industry more every day. So why would STD bus 
be better than any of these others.

As I see it, two reasons make it still ideal for industrial control. The 
first and probably most important is number of vendors supporting the 
product. The more making the cards, the lower the prices and the greater 
options available. The ideal situation would be all cards needed available 
from other vendors (don't have to build any that way).

The second feature to me is size and design. Unlike some other buses, the STD 
bus is small, compact and designed mostly for simple 8 bit work. Although 32 
bit variations are available, the idea is to use 8 bit CPU's and limit the 
amount of work to within the abilities of the CPU of choice. And yes, almost 
all CPU's have been built on standard bus cards.

A typical STD system might have one CPU board (CPU, RAM, ROM, Serial and 
Parallel I/O), and then special digital I/O boards (48, 64, 128, lines of Ins 
or Outs), or Analog boards (8, 16, 32, or 64 Analog to digital inputs, or 
digital to analog outputs). Communications is typically RS485 or RS422, which 
are high speed multiple station serial protocols ( one master, multiple slave 
units.) Synchro and Servo boards, as well as PLC (ladder logic) boards are 
also available. Now days even PC Clone compatible systems with hard drives 
and SVGA monitor systems in small 6 inch by 12 inch cabinets are available.


One difference I have found with standard bus is the typical ROM based 
debugger. While the newer systems are all DOS based and use LARGE C based 
development programs that require massive amounts of computing power to run, 
the typical debugger in ROM allows you to test and often reassemble the whole 
program. Or simply put, the ROM's are built for people to use to get the 
program running and tested.

Forth development systems are available, that give you a full Forth in ROM. 
Whether Forth or BASIC, or just assembly based, these ROM based tools have 
simple menus, a command line editor to leave code in memory, and test tools 
to see if it all worked as planed. 8-Bit systems are manageable by normal 
human beings. You can actually understand and modify these programs without 
needing 10 or 15 years of hands on experience. This too helps the STD stay 
viable. When other buses became more complex, simple OEM's had no choice but 
to stay with STD products or farm out development to other more expensive 

New Options

The newest kid on the block is the PC104 and PCI bus products. Pro-Log who 
started the STD bus is moving to the PCI industrial version as the new and 
upcoming replacement for the standard bus. These buses are all based on the 
PC Clone design and basically are popular because you can migrate your 
development form the PC to the smaller and more rugged platforms.

The PC-104 is just the ISA bus (PC Clone) put on header pins. This allows a 
smaller, about 4 inch square product, to be built. The items are stacked one 
a top each other and a full SVGA, Hard disk, system can be put in a 4 inch 
cube. The last Embedded conference had these machines sitting on top of demo 
17 inch monitors everywhere.

The PCI is the newest bus upgrade to PC Clones and is suppose to be Forth in 
ROM for intelligent interfacing. The industrial variant has other features 
which I need to research more before taking a stand on their good or bad 
features. As reported last issue, I have heard the bus is slower, but has 
other features that make it more ideal for use. In this case, I think about 
another two years is needed before we know just how well this product will 

Homebrew Projects.

For home brewing up an industrial controller, just about anything will do. If 
the product is really small and needs only a few bits of I/O, you might try 
one of the newer embedded controllers that I reviewed in issue #72. Old XT's 
or Kaypros will even provide the bases for using the parallel port for I/O 
and certainly BASIC will work as a programming language.

If your application needs more complex I/O, or just bunches of it, then STD 
or S-100 might be a choice. If money is no problem, then use one of the many 
digital I/O cards for the PC Clone bus. I find those products for the most 
part over priced, but if you only need one, your time is probably worth more 
than the overcharging.

Design a board, well not normally. I have just finished several designs based 
on the 8051 since we were unable to find ones already made (the most common 
reason for making your own). Our company is also in the business of making 
I/O products and thus justified in doing original work. And yet the prototype 
was tested on one of our proprietary bus products. So if it turns out you 
need to build it, you might consider using one of the buses to test the 
product before laying your money down on PCB prototypes (expensive to 
prototype). The CPUZ180 prototype work was done on the S-100 bus.

Tips on Trouble shooting

The standard practice with any bus product is trouble shoot by substitution. 
That means having a complete set of spares (one for each type) and a spare 
set of software ROMs if used. The most important tool will be the ROM based 
debugging tools. I like to use and test known running systems before being 
tossed out to the job site. That way I understand what the tools actually can 
provide and what they can't.

One ROM we use can do dumps of memory, 8 bytes at a time. A good aid in 
trouble shooting is having a listing of RAM from a good running system. To do 
that use Pro-Com/PCPLus or any good modem program, write a script that asks 
for all the RAM addresses you want, then upload it to the computer with the 
send spacing set at max. What happens is every request line of text gets a 
response, and you turn on the capture feature (saves data to disk) running in 
half duplex (only see response). This took about an hour, but I was able to 
get a complete map and data capture of 32K of RAM. A terrific trouble 
shooting aid which I did use later to solve a problem.

I can't stress enough the need to learn how to use tools of all kinds. I use 
List (a file viewer) to see binary files, first in text mode to see where the 
text strings are and then later in hex mode to see code groups. There are 
many viewers available, just get one and learn all about it. Get a bunch of 
dis-assemblers for your CPU of interest. I often find bugs from the 
assemblers or C-Compliers are the source of the problem, and knowing what it 
actually put out and not what you though it put out can solve many a problem.

For BUS problems, know what makes a minimum system. Start with the CPU only. 
Does it work? How well? Then add one card and see if it still works. Continue 
on till problems develop. Write programs in small steps or modules so you can 
test it in the same way. Load or burn a ROM that only does one thing. When 
that one thing works, add next step. Only have as small a part of the code as 
possible to see if it is working, never more. Avoid programming using 
languages that require it all before you can do a test. Even C can be done is 
small chunks, although most programmers don't (and thus need big bad 
debuggers to see what went wrong.)

Lastly think small. Break projects or problems into small parts. See if some 
task can be done outside the main program. Avoid in line coding and macros, 
since they often bloat the program for marginal gains and often make trouble 
shooting almost impossible. Always keep in mind the idea that I will have 
problems and thus how does the hardware and software design aid me in finding 
the solution(s).

Signal Descriptions

Power Buses (Pins 1-6 and 53-56).  The dual power buses accommodate logic and 
analog power distribution.  As many as five separate power supplies can be 
used with two separate ground returns as shown in figure 1-3. Pins 5 and 6 
provide for alternate use. If used for their alternate purpose these pins 
shall provide for disconnect capability on the card for conflict resolutions.

Data Bus (Pins 7-14). (8-bit, bidirectional, 3-state, Active-High).  Data Bus 
direction is controlled by the current master and is affected by such signals 
as read (RD*), write (WR*), and interrupt acknowledge (INTAK*).

All cards should release the data bus to a highimpedance state when not in 
use.  The permanent master shall release the data bus in response to bus 
request (BUSRQ*) input from a temporary master, as in DMA transfers.

The Data Bus lines may be Multiplexed for address space expansion.  The pin 
assignment for address expansion shall be as shown in figure 1-2.

Address Bus (Pins 15-30). (16-bit, 3.-state, ActiveHigh).  The address 
originates at the current master.  The permanent master shall release the 
address bus in response to a BUSRQ* input from a temporary master.

The address bus provides 16 address lines for decoding by either memory or 
I/O.  Memory request (MEMRQ*) and I/O request (IORQ*) control lines 
distinguish between the two operations.  The particular microprocessor that 
is used determines the number of address lines and how they are applied.

The address bus may be extended by multiplexing on the data bus.  The pin 
assignment for address expansion shall be as shown in figure 1-2.

Control Bus (Pins 31-52).  The control bus signal lines are grouped into five 
areas: memory and I /0 control, peripheral timing, clock and reset, interrupt 
and bus control, and serial priority chain.

Memory and I/O Control lines provide the signals for fundamental memory and 
I/O operations.  Simple applications may only require the following six 
control signals.  All STD BUS cards shall support the memory and I/O control 

PIN 31 WR*-Write to memory or output (3state, active-low).  WR* originates 
from the current master and indicates that the BUS holds or will hold valid 
data to be written to the addressed memory or output device.  WR* is the 
signal which writes data to memory or output ports.

PIN 32 RD*-Read from memory or input (3state, active-low).  RD* originates 
from the current master and indicates that it needs to read data from memory 
or from an input port.  The selected input device or memory shall use this 
signal to gate data onto the BUS.

PIN 33 IORQ*-I/O request (3-state, active-low).  IORQ* originates from the 
current master and indicates an I/O read or write or a special operation.  It 
is used on the I/O cards and is gated with either RD* or WR* to designate I/O 
operations.  For some processors, IORQ* is gated with other processor signals 
to indicate a special operation, IORQ* with STATUS 1* (Ml*) indicates 
interrupt acknowledge for the Z80.

PIN 34 MEMRQ*-Memory request (3-state. active-low).  MEMRQ* originates from 
the current master and indicates memory read or memory write operations or a 
special operation.  It is used on memory cards and is gated with either RD* 
or WR* to designate memory operations. For some processors, MEMRQ* is gated 
with other processor signals to indicate a special operation, MEMRQ* with 
STATUS 1*(DT/R*) and STATUS 0* (SS0*) indicates Passive for the 8088.

PIN 35 IOEXP-I/O expansion (high expand, low enable).  IOEXP may originate 
from any source and should be used to expand or enable I/O port addressing.  
An active-low shall enable primary I/O operations. I/O slaves shall decode 

PIN 36 MEMEX-Memory expansion (high expand, low enable). MEMEX may originate 
from any source and should be used to expand or enable memory addressing, An 
active-low shall enable the primary system memory. MEMEX may be used to allow 
memory overlay such as in bootstrap operations. A control card may switch out 
the primary system memory to make use of an alternate memory. Memory slaves 
shall decode MEMEX.

Peripheral Timing Control Lines provide control signals that enable the use 
of the STD BUS with microprocessors that service their own peripheral 
devices.  The STD BUS is intended to service any 8-bit microprocessor.  Most 
peripheral devices work only with the microprocessor they are designed for.  
Four control lines of the bus are designated for peripheral timing.  They are 
defined specifically for each type of microprocessor, so that it can best 
serve its own peripheral devices.  In this way, the bus is not limited to 
only one processor.

PIN 37 REFRESH'-(3-state, active-low).  REFRESH* may originate from the 
current master or from a separate control card and should be used to refresh 
dynamic memory.  The nature and timing of the signal may be a function of the 
memory device or of the processor.  In systems without refresh, this signal 
can be any specialized memory control signal.  Systems with static memory may 
disregard REFRFSH.*

PIN 38 MCSYNC*-Machine cycle sync (3-state, active-low). MCSYNC* shall originate from the current master. This signal should occur once during each machine cycle of the processor. MCSYNC* defines the beginning of the machine cycle. The exact nature and timing of this signal are processor-dependent. MCSYNC* keeps specialized peripheral devices synchronized with the processor's operation. It can also be used for controlling a bus analyzer, which can analyze bus operations cycle-by-cycle.

MCSYNC* should be used to de-multiplex extended addressing on the data bus.

PIN 39 STATUS 1*-Status control line 1 (3state, active-low). STATUS 1* shall originate from the current master to provide secondary timing for peripheral devices. When available, STATUS 1* should be used as a signal for identifying instruction fetch.

PIN 40 STATUS 0*-Status control line 0 (3state, active-low). STATUS 0* shall originate from the current master to provide additional timing for peripheral devices.

Interrupt and bus control lines allow the implementation of such bus control schemes as direct memory access, multiprocessing, single stepping, slow memory, power-fail-restart, and a variety of interrupt methods. Priority for multiple interrupts or bus requests can be supported by either serial or parallel priority schemes.

STD Vendors

These vendors still sell 8 bit CPU based cards. Vendors no longer selling any 8-bitters are not listed.

Computer Dynamics (Z80/6809), 803-627-8800. Datricon/Scientific Tech. Inc. (6809,68008), 800-221-7060. Matrix Corporation (Z80/6809), 800-848-2330. Micro-Aide Corp. (Z80), 818-915-5502. Micro-Link Tech. Inc. (Z80/8085), 800-428-6156. Micro/Sys Inc. (Z80), 818-244-4600. Microcomputer Systems Inc. (8051, NSC800, Z80), 504-769.2154. Mitchell Electronics (Z80), 614-594-8532. Robotrol Corporation (Z80), 408-683-2000. VersLogic Corp. (Z80), 800-824-3163. WinSystems Inc. (Z80, 64180, 8085 NSC800), 817-274-7553. XYZ Electronics (6809, 68008), 800-852-6822. Zwick (64180), 613-726-1377.

Bill Kibler, Kibler Electronics, PO Box 535, Lincoln, CA 95648-0535, USA. bill@kiblerelectronics.com
Copyright © 1995, Kibler Electronics.