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. INTRODUCTION 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. A BUS 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. GOOD DEBUGGERS 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 vendors. 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 do. 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 lines. 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 IOEXP. 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.