Interface "How it works"

In my last update, I explained how my Armdroid's circuit was identified as a prototype model.

I'm going to now describe how this works and the differences to standard production models, and what this means to the controlling software.   This update may not capture every detail, but everything will fall out in the wash later...

The interface, as we all know is designed around a standard eight bit bidirectional parallel port, which may be latched or non-latched.  This is similar to production models but there are subtle differences to note...

When the port is operating in output mode (data transmitted from controlling computer), the port is configured as follows :

D8    X2
D7    X1
D6    CCLK
D5    CDIR
D4    A3
D3    A2
D2    A1
D1    OUT (LOW)

Output Bits
X1, X2 unused (could be used with CCLK, CDIR for direct stepper drive)
CCLK clocks driver circuitry
CDIR gives motor direction
A1, A2, A3 motor address
OUT indicates data to travel from microprocessor (logic low)

The first four bits (D1 - D4) are roughly the same as production variants.  I say roughly because reading on the internet appears to be discrepancies, but as far as I'm concerned they are the same.

When the stepper motors have been connected up using the suggested channels, the motor addresses (A1 - A3) relate to these functions:

000   x  (not used)
001   Gripper
010   Left Wrist
011   Right Wrist
100   Forearm
101   Shoulder
110   Base
111   x

The next four bits however are totally different....  On the production models, the controlling computer is responsible for issuing the stepper motor step pattern.  This requires 4-bits to encode North/East/West/South and other combinations.  But on my prototype model, only 2-bits (D5 - D6) are used, and the remaining bits are not used.

As you may recall I said my circuit is complicated... This is because it includes it's own Stepper Motor Control Logic.  In my case, to drive a motor, I need to set the address, the direction (CDIR) to specify clockwise, or anti-clockwise rotation, and then provide a clock pulse CCLK to run the motors.   The timing of this clock relates to motor speed.

I noticed it would be impossible to half-step the stepper motor using this arrangement because we have no further control of the stepper control logic.

But, there is another dimension to this...   The output bits X1, X2 can be used to bypass the on-board stepper motor control logic.  In which case, it's possible to remove ICs 1, 2 and 3 which are redundant in each motor drive section.  This means, the motor drive control will then be exactly the same as production models.  So, I really get the best of both worlds...  More on this later...

So, what does all this mean for the software?   Naturally, the signals required to control the Armdroid using the stepper motor control logic (prototype) is completely different to that of direct control (production models).  But, this difference could be abstracted in the software drivers, meaning Applications could work regardless of the model used - admittedly, there would be some restrictions, but gives greater flexibility.

Anyway, back to the interface... finally, when the port is operating in the inverse input mode, the configuration is as follows:

D8    MS6
D7    MS5
D6    MS4
D5    MS3
D4    MS2
D3    MS1
D2    U1
D1    IN (HIGH)

Input Bits
MS1 - MS3 micro switch inputs
U1 user defined (not used)
IN indicates data to travel to microprocessor (logic high)

I don't think there is any difference here to production models.

There isn't a great deal of information about sensor wiring, I'll re-arrange mine to have MSx relate to corresponding stepper motor channels 1 - 6  if they are not already like this!

One last thing I couldn't figure earlier this week - how the production models could possibly use a manual controller?   I think the answer is...  they don't !

I'll be opening up my base another day, will remove the jumble of wires and extract both circuit boards.  I want to identify by ohming the circuit what that broken track is.  I also want to identify if D1 is the right-most contact, or left-most when looking directly towards the edge connector.  This orientation will really make life a lot easier when I come interfacing...

You may have seen elsewhere on the Blog the new Resources section - I'm going to keep this updated with circuit diagrams, data sheets, and information to help you get your Armdroid up 'n running.  If you have anything to contribute, please do send me a message....


Tomorrow, I have been invited to meet Liz and Eben Upton, founder and trustees of the Raspberry Pi Foundation at Bletchley Park, Buckinghamshire, which I'm pretty excited about!   I'll be taking my camera along and will update the Blog later over the Bank Holiday weekend...