Last night turned into a fairly intensive evening of tracing the entire interface circuitry.... I did this not once, but twice!
I started by tracing the pinouts of the interface cable, confirming these match the literature, and what has been document elsewhere on the internet.
One problem I've found with the original documentation, it's not very clear illustrating these pin assignments, so I've put together the following table which might help:
PIN
|
ARMDROID
FUNCTION
|
INPUT
BITS
|
OUTPUT
BITS
|
1
|
+5
V
|
||
2
|
GND
|
||
3
|
D2
|
N/C
|
A1
|
4
|
D1
(STROBE)
|
HIGH
|
LOW
|
5
|
D4
|
MS2
|
A3
|
6
|
D3
|
MS1
|
A2
|
7
|
D6
|
MS4
|
D2
|
8
|
D5
|
MS3
|
D1
|
9
|
D8
|
MS6
|
D4
|
10
|
D7
|
MS5
|
D3
|
The physical wiring is very different to prototype models.
At this point, I wanted to double check the address decoding of motor selections.
This has been the subject of great confusion, not only to myself, but other readers too. My prototype variant turned out to have A1 as the most significant address bit, not A3 as expected. It seemed odd why this was the case, and without finding any examples of source code on the internet, it turned into one of those little mysteries of life.
Tracing this part of the circuit however resulted in a bit of a discovery....
Address bits A3 and A1 have been swapped, which means the address decoding for this generation of interface board is completely different to prototype variants.
My tracing determined:
D2 (exiting pin 8 from IC2C) feeds into Pin 1 (A) of the Demultiplexer (74LS138 / IC6)
D3 (exiting pin 6 from IC2B) feeds into Pin 2 (B) "
D4 (exiting pin 3 from IC2A) feeds into Pin 3 (C) "
Hopefully, any reader who previously read my post "Motor Addressing Solved" will understand that only applies to the address decoding of prototype variants only. I would imagine, all later generations follow the above form of addressing logic.
I wonder if Colne made a mistake in the PCB routing of early prototype models, and subsequently corrected things?
To complicate matters, some of the schematics contain minor mistakes. In time, I will redraw these for both generations of circuit boards, and make them available on this site.
I've previously spoken about my intention to develop a software library, and of course, this will need to support both addressing modes. From a higher level view, any software consuming this library need not actually be concerned with these implementation details, we just need to config it correctly, and the library will do all the hard work.
Anyway, with the pinouts confirmed, I am now wiring up my Arduino with a higher degree of confidence something might actually work:
Output pins 2 - 9 have been wired to correspond to bits D1 - D8, and the switching is all done in hardware. This keeps things logically consistent with my existing Raspberry Pi interface, and that means program code should port relatively easily between the two devices.
Pins 0 (RX) and 1 (TX) have purposely been left unconnected, this is necessary when using serial communication. My test program will be responding to commands sent via USB/Serial, this is why I have chosen to use the above pin assignments.
The +5 V line is not used, and common grounds have been connected together. The Arduino Leonardo is a native 5V device, therefore no voltage conversion is necessary.
I'm currently making final edits to my program code, and then we're ready for the ultimate test this weekend....
No comments:
Post a Comment