What goes into designing an interface

I decided to document the various considerations, requirements and issues surrounding the creation of the interface to connect the Strobe model 100 plotter to the 1130 and have it appear to be an IBM 1627 plotter. Walking through the process is a great illustration of how even a ultra simple device (both the 1627 and Strobe 100) can burgeon into a medium sized interface.

The 1130 has a very simple adapter for the 1627, it is constructed of just 67 simple logic gates, most of which are needed to latch in the command when an IO instruction is executed or to present the status of the request and of the device - in other words, most are common to the root requirements for any device on the 1130, only a few are involved with talking to the plotter.

The 1130 adapter has just six signal lines outgoing to the plotter and no incoming signals. It does monitor that the power is on for the adapter meaning that the cable is intact, because it determines this status by checking that power is on a line that is tied by resistor to the incoming power right at the connection. No internal state of the 1627 is checked or used for this pseudo-ready check.

The 1130 adapter can request:

 - take the pen one step to the left
 - move pen one step to the right
 - move the drum forward one step
 - back the drum up one step
 - lift the pen off the paper
 - lower the pen onto the paper

The adapter has a chain of two timers each of which waits 1.9 milliseconds (for the 1627 model 1), which is longer than the time needed to accomplish those requests, then reports that the command is complete. Since the model 1 can move 300 steps per second, each step will require 3.33 ms and the 1130 is providing 3.8 to give itself a bit of safety margin. Thus, the maximum rate at which the program can draw is 263 steps per inch if it waits for the response that indicates the plotter is done. If a step command is issued before the plotter has finished its prior motion, it is likely to be lost unless it arrives very near the end of the motion.

The signals from the 1130 are inverted - for example the signal is 'Not move one step to left' where a 1 value means don't do this, a 0 is a command to move. Apparently this was acceptable for the connection to the Calcomp plotter models that IBM sold as their 1627.

The Strobe model 100 has ten commands it can execute, similar to but not identical to the Calcomp's repertoire:

  - activate ring 1 of the left/right movement stepper motor
  - activate ring 2 of the left/right movement stepper
  - activate ring 3 of the left/right motor
  - activate ring 4 of the left/right motor

  - activate ring 1 of the drum forward/back movement stepper motor
  - activate ring 2 of the forward/back movement stepper
  - activate ring 3 of the forward/back motor
  - activate ring 4 of the forward/back motor
  - lift pen off paper
  - lower pen to paper

  The stepper motors move one step when a ring is deactivated and the adjacent ring activated - only one of the four rings is active at any time. Movement is a rotation thru the four rings and repeat cyclically, however in our case we only do one step at a time as that is all the 1130 requests.

The interface is normal polarity - a 0 means an inactive ring, a 1 means activate the ring. One of the rings must always be powered, as that holds the pen and drum in the position to which they were last moved, we just switch the ring being powered to affect a step. 1 means move pen up or move pen down, 0 means do nothing, same normal polarity for the control signals.

The Strobe plotter can only step at 120 steps per inch, less than the 1627 maximum rate for either model. I will need to modify the timer in the 1130 adapter, creating a mythical model III of the 1627 that requires the timer to wait 4.2 milliseconds in each timer instead of the 1.9 or 2.9 set for the two real plotter models.

The time reserved by the adapter for raising or lowering the pen is .1 second, which should be fine for the mechanism in the strobe plotter. No change needed to the timers in the adapter controlling those commands.

First observation - you may be able to take a faster device and invisibly mimic a slower one, but the reverse may require some adjustments to make the slower speed visible. Designing this interface required the realization of the timing issue and the need to provide a third configuration jumper for the 1130 adapter virtual logic cards - just as it has jumpers for the time delay for a model I and model II plotter, it will now have a third jumper choice for our model III.

Our interface must keep one of the rings powered and move the power to the adjacent ring in one direction when the command is to move a step one way, move to the adjacent ring on the other side if we are asked to move in the opposite direction. Each time a "move one step" signal goes to 0, we detect that transition and do a single movement in the appropriate direction.

This is easily imagined as a four bit circular shift register, initialized with just one of the four bits set to 1, then shifted to the right or to the left to change from the currently activated ring to the appropriate neighbor. One register for each of the two stepper motors and it would seem we will have a very simple interface.

A key requirement is that we do a single step when we get a 0 from the 1130 - not step more than once even though the signal line may stay zero for a long time before it is returned to 1 by the 1130 adapter. We need circuits to do an 'edge detection', spot when it first changes from 1 to 0 and only at that time do the shift of our register, then ignore any continuing level of 0 or 1.

Another issue - the incoming signal from the 1130 may arrive at any time - it is asynchronous to our interface and to the plotter. If we use a clock on the shift register, we must protect from the edge arriving at the same time as the clock switches, because the signals defining which direction to shift won't be stable or reliable yet. This can cause glitches, erratic failures very hard to pin down. Therefore, any time a signal coming in must be used in a clocked circuit, we need to synchronize the signal change to avoid this timing risk.

In fact, the most straightforward way to do the shift is to use the 1130 signal itself as the clock for the shift register (inverted so that it is going from 0 to 1 when we want to do a shift). The shift register only changes state on the rising edge of its clock, thus the continued state of the signal after the edge is ignored. Further, we have no clock to synchronize to.

We have one shift register for a stepper motor that must be bidirectional - shift to the left or the right - with the bit shifted out of one end shifting into the other in a perpetual circle. We can 'OR' together the two signals for a stepper, e.g. step left and step right, so that either button causes the shift register to shift. However, setting the direction of the shift requires us to set two control bits for the shift register. The signal that tells us which way to shift is the same one activating the register as a clock. That means it just arrived, so the control bits have not been at a stable level for their minimum time before the clock input is changed. This too causes glitches. We need to present the bit pattern for left shift or right shift, depending on which key is pushed, let it set up for a minimum time, and only then take the clock input from 0 to 1.

This means we need to use the 'step' signal as a control bit but also delay it to use it as a clock. There are many techniques to do this - a even number of inverters in a chain, for example, or a quick timer, or a delay component, or many others.

Now for the next complications. The Strobe plotter has four direction buttons, just as the 1627 has knobs that the operator rotates to signal 'step left', etc. These buttons are sent as input from the plotter to our interface, as inverted logic signals - 0 means the button is pushed. It is up to our interface to see this button push and cause the shift register to move the stepper motor, just as if the 1130 sent us a step command.

These are simple buttons that ground a line, otherwise pulled up to logic 1 by a resistor to +5V inside the plotter. This is why they provide an inverted signal, 0 meaning activated. However, any such electromechanical switch can suffer from a condition called bounce, where during the instants when the contacts are coming together or parting, they quiver a bit and actually produce an alternating series of very short signals - 1, 0, 1, 0, 1, 0, 1, 0 etc until they settle on their final value.

Each transition from 1 to 0 would be an edge that caused our shift register to take another step. The user would push the button once but the pen or drum might move multiple steps. To avoid this erroneous behavior, we have to remove the effect of the bounce, called debouncing the signal. Our method of doing this leverages a chip, the MC14490, that will remove the bounce from up to six switches that ground a signal or leave it to be pulled up by a resistor. This is exactly the situation with our plotter switches, and a well chosen capacitor value will block bounces for a reasonable number of milliseconds to ensure we get a clean snap to 1 or 0 every time. We only need one of these chips as we have only five buttons to debounce.

The button is another kind of async signal, just like the step command from the 1130, and has to be treated the same way - the signal has to set up the control bits of the shift register for a minimum time before the signal edge, suitably delayed, can be delivered to the clock input of the shift register. We can combine the two signal - the 1130 and the button - with a logical OR (although complicated because both are inverted signals not normal polarity so this is an AND we are doing) to get a 0 if either of them presents a 0.

Already you can see how layers are getting added to the interface logic as each button and requirement is considered. The worst is yet to come - both the 1627 plotters and the Strobe plotter have a 'fast' mode. When the "fast" button and a direction button are pushed together, the plotter steps 120 times each second until the buttons are released. Similar things are done by the 1627 with a fast movement control.

This requires us to create some kind of clock and use it to shift repeatedly while a control signal remains at a constant 0 level. The asynchronous signals from the buttons now require synchronization to our clock, adding more circuitry, plus we need to switch between the edge detecting self clocking of normal buttons and the routing of our clock instead when the 'fast' button is depressed.

We don't need a very precise clock, since we are only looking for a method that moves the stepper motors 120 times per second which just requires 120 rising edges spaced roughly evenly apart. The time spent in the 1 state compared to the 0 state (duty cycle) isn't important and the exact frequency or steadiness of the frequency isn't important. Because of this, I created a simple RC oscillator with a pair of inverters whose output is fed back through a resistor and capacitor to the first input. The choice of resistor and capacitor value gets the frequency near enough to 120Hz for our purposes. The output is fed through another inverter to clean up the signal and deliver it to the gates that need it.

This clock is going to drive the D flip flops that serve as a synchronizer, to align the change of the async external signals to the timing of the clock. We feed the async signal to the D input and use our clock to drive the two flip flips. The output of the first is passed into the D input of the second. This dramatically reduces the chance of a glitchy behavior due to bad timing between signal change and clock edge.

The clock has another purpose, to drive the shift registers to move the stepper motors, but we only want that behavior when two things are true - a directional button is pushed and the fast button is pushed. We need some gating to keep the clock from coming through unless these two conditions are true, then OR that with the normal self-clocking signal that comes from the switch signals themselves through the D flip flop pair. The self-clocking pulses the shift register to make one move, but if the real 120Hz clock has been let through the gate then it keeps pulsing the register to make repeated steps until our conditions end (either fast or direction button is released).

There are other switches on the Strobe plotter - a "motor release" toggle switch, a "pen up/down" toggle switch, and a "start/enter" pushbutton. The start/enter button does not have an analog on the 1627 plotter on an 1130 system, so we will ignore it. The other two accomplish their functions entirely locally inside the plotter cabinet, by interrupting the power to the stepper motors or to the pen down solenoid, respectively. They don't need anything from our interface.

The stepper motor requires that only one of the four rings is powered at any instant, yet when power is first turned on the shift register may have any value at all in it, many of which have more than one bit as 1 and there is an all zero state that will guarantee no motor movement in spite of any number of shift operations. We must initialize the state of the shift register to our desired value (I chose "1000" arbitrarily). The shift register chips have a clear function but it sets up all zeros. We need to inject the right value at startup time.

We could set the shift register control bits to 11 during the initilization period before our long timer goes off. That pattern tells it to load the value on the parallel load input pins, which we can permanently wire as 1000. However, it needs a clock transition to make this happen, and we don't have a clock going to the register except for fast mode button pushes. The initialization time logic has to get more complicated, because it has to generate a one time 'clock pulse' to the shift register after it has stabilized the control bits to their 11 value, then shut off after initialization time has expired to allow normal clocking by 1130 command, button or fast button mediated clock signals.

To implement the initialization logic, I use a resistor and capacitor in series between the +5V power supply and ground with the connection between them routed to the input of an inverter. When power is first applied, the voltage seen at the inverter rises slowly until it passes a threshold and flips the state. Thus, the inverter emits a logical 1 at startup which flips one time to 0 after our preset time interval. A 'long' interval of about .1 second is used for the main initialization, which forces the control bits on the shift registers to '11'.

A short and a medium timer of the same design are combined together to form a single positive pulse that starts when the short timer goes to 0 and ends when the medium timer flips to 0. This is a single clock pulse which is routed to the shift registers in an OR with the other clocking sources that drive it.

But wait - there is one more consideration! The fpga operates at 3.3V with logic levels commensurate with that. The plotter operates with TTL 5V signal levels. We need to accept valid commands from the 1130, thus we have to put in level shifting circuits to convert a logic 0 or 1 from the low voltage CMOS 3.3V standard levels to the TTL 5V standard levels.

One also has to think of how the circuit will behave if conflicting signals are pressed simultaneously - both step left and step right. If one arrives before the other, we get a step in the direction that is activated first, the other ignored since we have only one self-clocked pulse for the shift register and it is likely that the second button hasn't activated its control signal by the time our self-clock arrives at the shift register. If they come simultaneously or close enough, then the control bits cause the shift register to initialize to its '1000' pattern, causing only a minor movement of the stepper motor which then holds that position.

If the fast button was pushed also, then the repeated clock pulses passed through to the shift register just cause it to initialize repeatedly to the same pattern, so the motor stays in the one position. This is a reasonable behavior and we don't need to add additional logic to handle the condition.

This can also happen if the 1130 commands a step and the operator has pushed a button at the same time (and they are conflicting directions), but the outcome is the same reasonable behavior. If the operator commands one stepper motor to move while the program is commanding the other stepper motor to move, we just get a diagonal movement between pen shifting left/right and drum moving forward/backward. No issue here either.

This gives us a final interface design with 31 simple logic gates, 2 shift registers, 5 debouncers, six level shifters, eight D and 1 JK flip flop.  (more than a dozen chips plus a couple of dozen capacitor and resistors); it is somewhat larger in gate count than the 1130 adapter logic, yet just mediates between the adapter and the plotter. The simple logic gates are inverters, NAND and OR gates. Good hygiene with the chips includes tieing unused input pins to +5V or ground and the insertion of capacitors across the chip power pins, this added bit is tossed into the mix.

In many places other choices would yield the same logic outcome, where but the choices I picked made the best utilization of the available gates with minimized chip count - inverters come six per chip, the others types are quad - four per IC except the JK flipflop that controls the pen movement up or down onto the paper, which is a dual FF package of which we use only one. Almost all the chips are fully utilized.

All this without any real protocol to deal with. More complicated devices may have long dialogs of signals that go back and forth to handle various needs, not just a single "raise pen" kind of signal as found in this plotter. Interfaces for those more rich, complex devices require quite a bit more logic to implement everything. Generally, they quickly reach the point where it is easier and more compact to put in a microcontroller (small processor) that you have programmed to raise and lower all the signal lines based on what it senses on its input lines, instead of putting in discrete logic gates and timers.

For most of the more complex devices, I just multiplex all the signals from the device straight on through to the fpga where I have millions of gate equivalents and can instantiate processor cores to handle protocols if needed. As a backup method, I could use an mbed or Arduino or other microcontroller in an outboard interface box, which might be better if timing requirements are challenging to meet with the multplexors running over I2C links. Finally, for the most complicated of needs, a simple computer like a Raspberry Pi might be used to handle extremely complicated work interfacing to the 1130.

No comments:

Post a Comment