|
|
Host Communication
PMD provides various communication schemes for talking to the PMD motion
control chips. A host processor is required for sending instructions to
the PMD chips. The host platforms range from personal computers to Single
Board Computers to embedded microcontrollers. Once the developer has chosen
the host hardware, the communication scheme must also be chosen. As can
be seen in Figure 3.1 the various communication schemes include: ISA/PC104
Bus, PCI Bus, Serial, CAN, Digital IO, Generic I/O bus, and Memory bus.
Note that the selection of a microcontroller as a host allows for a broader
range of communication schemes.
The use of a Personal Computer as a host assumes that the PC processor
can read and write to a PCI or ISA slot on its motherboard, or a COM port
in the case of serial communication. Note the use of a CAN interface is
limited to the Magellan product. Use of a CAN interface on a PC assumes
the PC has a CAN controller installed.
The developer will need to generate an executable to run on the host
processor that will send instructions to the PMD chip. It is not a requirement
but it is recommended that the developer utilize the C-Motion library
when generating the host executable. The previous chapter gives the reader
an initial look at the C-Motion library. This chapter will demonstrate
use of C-Motion with
specific communication schemes.
As mentioned before many of the communication examples that C-Motion
provides are based on communication to a PMD Development Kit board. The
DK board is typically used in a PC running a Windows OS where the PC processor
acts as the host. In some cases it may be desirable to have a host running
on a Windows platform in which case the C-Motion communication examples
would demonstrate the necessary functionality and would need little modification.
Again the nature of the modifications that need to be made to C-Motion
depend greatly on the host processor hardware and Operating System.
The scope of this document is intended to cover reference designs for
the use of PMD’s Pilot, Navigator, and Magellan Motion Processor
products. In many cases there will be only a reference design for the
Magellan chip shown and none shown for the Navigator, and sometimes the
opposite will be true. With noted exceptions, these designs can be easily
modified for use
with the other PMD controller not shown. Noting that the Pilot, Navigator,
and Magellan all come in different chip level packages means that attention
must be paid to the pin labeling when using a specific design with a different
PMD controller. Also note the Magellan is a 3.3V device that is not 5V
tolerant, while the Navigator and Pilot are 5V devices.
The intentions of the reference designs are to depict specific interfaces
to PMD’s processors. It is recommended that all designs use some
form of power supply regulation. The chosen power supply scheme will not
be affected by the selection of the communication interface and vice versa.
The power regulation stage is important but is omitted for clarity on
the reference designs contained here. Please reference the bulk capacitor
schematics used for power regulation in Appendix A.
Further attention should be paid to details that will be impacted by
circuit board layout. Layout requirements are very design dependent and
the scope of this document will only touch on a few items that are impacted
by layout. One item, which may or may not be shown in the subsequent schematics,
is a recommendation to place low ohm resistors on all clock traces, which
will
minimize the effects of trace capacitance on the clock signals.
The Pilot and single axis Magellan products are single chip packages
and the creation of a parallel interface is handled differently than for
the Navigator and 2-IC Magellan processors. PMD supplies program files
and design files for a programmable ACTEL® device. This part will
allow the developer to use the same parallel host interface on a Pilot
or single axis Magellan that is seen in use with the Navigator and muli-axis
Magellan processors. This interface is detailed in Section 3.3.
3.1 PCI Communication
The PCI bus has become a standard on all PCs. Likewise the use of the
PCI bus in embedded applications is also becoming more common. While
the PCI bus is one of the fastest and most robust, it may require a
higher skilled developer in addition to acquiring a PCI bus development
kit. Shown below are reference schematics for interfacing the PMD chipset
to a PCI bus. These designs utilize a PLX® PCI9030 PCI bus interface
device. If the developer is planning to use the same device, it may
or may not be necessary to acquire the PLX software development kit.
Section 3.1.3 explains the conditions that would require the developer
to obtain the PLX development kit.
3.1.1 PCI Magellan Schematic
Shown in Figure 3.2 Sheet 1 is a PCI edge connector and the subsequent
connections to a PCI9030 PCI bus interface chip. The PCI9030 is a
3.3V device. This schematic is intended to represent the interface
to the PMD Magellan device which is also 3.3V. PLX has specific recommendations
for handling various used and unused pins on the PCI9030 device which
are shown in Appendix B.
This electrical schematic and all subsequent electrical schematics
can be downloaded as an ORCAD project from the PMD Application Notes
Web Page.
Click to Enlarge
Click to Enlarge
3.1.2 PCI Navigator Schematic
Shown in Figure 3.3 is a PCI interface to a Navigator. This schematic
is very similar to Figure 3.2. The biggest difference is that the
Navigator processor is a 5V device. For this reason voltage level
shifters were inserted in the buses that run between the PCI9030 and
the IO. In addition to different supply voltages, the Magellan and
Navigator devices have differences in the physical package which include
pin count and pitch.
Click to Enlarge
Click to Enlarge
3.1.3 PLX PCI Chip Information
The PCI interface schematics depict an EEPROM (U22 in Figure 3.2
and U19 in Figure 3.3) that provides a boot-up configuration for
the PLX device. The PLX development kit will provide a software
application called PLXMON that is necessary for programming the
EEPROM. Figure 3.4 is a screen shot of the EEPROM configuration
window in the PLXMON application, which shows the configuration
for a PMD device. 
If the intention of the developer is to use the PLX drivers that
come with C-Motion then the developer will need to use the PLXMON
application to store the configuration values shown in Figure 3.4
to the serial EEPROM. During the programming of the EEPROM, the
EEPROM is physically tied to the PLX9030 as shown in the schematic.
For further information refer to the PLX documentation available
from http://www.plxtech.com/.
The use of external RAM on the CP local bus will not be covered
in this document. However, the PCI interface design referenced here
is derived from PMD’s PCI DK board that does utilize a dual
port RAM. The configuration shown above is the same configuration
utilized in the PCI DK board, which allows for DPRAM. The PMD motion
processor has been mapped to an IO space and the DPRAM has been
mapped to memory space. At this point in time, if the developer
wishes to utilize DPRAM, the schematics for the PCI DK manual should
be referenced which are available on the PMD Application Notes Web
Page.
The PCI interface scheme that comes with C-Motion utilizes drivers
that were created via the PLX development kit. PMD is not licensed
to distribute the PLX source code and therefore only the object
code has been provided in the C-Motion library. If the host will
be running on a Windows OS and the above PLX configuration is being
adhered to, the PCI drivers (defined as PMD_PCI_INTERFACE) that
come with C-Motion will be sufficient. If the developer wishes to
use a non-Windows OS on the host or if the configuration shown above
is not adhered to then the PCI drivers that come with C-Motion will
not suffice and the developer will need to create PCI drivers using
the PLX software development kit.
It is also possible to access the PCI bus using parallel communication
drivers (defined as PMD_PARALLEL_INTERFACE in C-Motion). However,
this cannot be accomplished when using Windows 2000/NT/XP because
the PMD_PARALLEL_INTERFACE driver will not work. This method allows
the host to interface to the PMD device as an ISA address. If the
OS has this functionality it will assign IO spaces to the PLX device.
When using the, this IO space replaces what is referred to as an
ISA address argument in C-Motion function calls.
3.1.4 Altera® PLD Information for PCI Bus Design
The existence of an Altera PLD in this design is mentioned above
and is shown in Figure 3.2 and 3.3. The function of the PLD is to
handle the timing of the hand shaking signals. The hand shaking
signals local to the PMD chip set that are tied to the PLD include:
~HOSTSLCT, ~HOSTWRITE, and HOSTCMD. The signal referred to as ~HOSTREAD
bypasses the PLD and is tied to the PLX device. Other signals that
are used for handshaking between the IO chip and the CP chip are
also tied to the PLD so that the PLD knows when the chip set is
busy talking to a peripheral device. These signals include: CPR/~W,
~CPSTROBE, and ~CPPERIPHSLCT. In addition the PLD in the Navigator
design uses CPR/~W for this purpose while the PLD in the Magellan
design uses ~RE and ~WE for this purpose.
The PLD implemented in Figure 3.2 is an ALTERA EPM3064ATC100-10
and in Figure 3.3 an ALTERA EPM7064STC100-10 is used. The program
files and logic design for these devices are available from the
PMD Application Notes Web Page. Note the existence of the J8 connector
in Figure 3.2 and the J7 connector shown in Figure 3.3 that are
used for incircuit
programming of the respective Altera devices. The interface between
the PLD and the PMD IO device is shown on Sheet 2 of the respective
figures. The interface between the PMD IO device and the PMD CP
device is
also shown. The interface in Figure 3.2 is the same for all multi-chip
Magellan devices regardless of the communication scheme or number
of axes being used. The same can be said for the interface shown
in Figure 3.3 in the context of the Navigator designs, in that the
interface between the PMD IO device and the PMD CP does not change
when using
different communication schemes or number of axes.
3.1.5 PCI Software
A PCI communication example exists in the C-Motion library. As
mentioned before this example utilizes the drivers created from
the PLX software development kit. This example is shown below with
some modifications to remove calls to DPRAM.
// PCIIO.CPP (modified)
#define PMD_PCI_INTERFACE
#include "C-Motion.h"
#include "PMDutil.h"
#include "PMDpci.h"
#include <stdlib.h>
#include <stdio.h>
// the axis handle object
PMDAxisHandle hAxis1,hAxis2;
int main(int argc, char* argv[])
{
PMDuint8 ui8major, ui8minor;
PMDuint16 generation, motorType, numberAxes, special, custom,
major, minor;
if (PMD_NOERROR != PMDSetupAxisInterface_PCI( &hAxis1, PMDAxis1,
0))
{
printf("Board initialization failed\n");
return 1;
}
// use the same transport for Axis#2 because it resides on the
same chip
// so must use the same interface
PMDCopyAxisInterface( &hAxis2, &hAxis1, PMDAxis2 );
if ( !PMDChipsetReset( &hAxis1 ) )
{
free( hAxis1.transport_data );
printf("Reset failed\n");
return 1;
}
PMDGetCMotionVersion( &ui8major, &ui8minor );
printf("C-Motion Version %d.%d \n", ui8major, ui8minor);
// just do some easy gets to make sure comms are working
PMDGetVersion(&hAxis1, &generation, &motorType, &numberAxes,
&special,&custom, &major, &minor);
printf("MC%d%d%d%d Version %d.%d\n\n", generation, motorType,
numberAxes, custom, major, minor);
// free any axis handle memory that was allocated
PMDCloseAxisInterface(&hAxis1);
return 0;
}
The #define PMD_PCI_INTERACE causes a link to the
PMDPCI.OBJ file which contains the calls to the PCI driver. Note
that the PMDPCI.OBJ file as well as the PLXAPI.LIB file must be
manually linked into the project. Also note that the PCI driver
distributed with C-Motion is Windows specific. Section 2.1 introduced
the concept of an “axis handle”. This example initializes
an axis handle with a call to PMDSetupAxisInterface_PCI.
The EEPROM for the PLX9030 contains a PLX specific vendor/device
ID, as well as a PMD specific sub device ID. During the execution
the PMDSetupAxisInterface_PCI function, the PLX
Windows driver will search the PC’s PCI bus space for devices
that match the device and sub device IDs. The final argument of
this function determines which device, from the list of devices
that match these IDs, will be assigned that Axis Handle. If the
value of the argument is 0 or 1 then the first matching PCI device
will get assigned the specified Axis Handle. If the value of the
argument is 2 then the second matching PCI device will be assigned
the Axis Handle. The argument can also take on larger values if
necessary.
The manner and order in which the detected PCI devices are
identified may vary across different platforms. The user should take
care that the correct PCI device is being accessed.
Once one axis handle has been initialized the PMDCopyAxisInterface
function can be used to initialize any other axes that are present
on the same device. The PMDCopyAxisInterface function is valid for
any communication scheme, not just PCI. Once the axis handles are
initialized, communication to the PMD device is ready. All future
C-Motion function calls will contain the axis handle as the first
argument.
Also shown in this example is a Reset function call (PMDChipsetReset)
which is a software reset instruction processed by the PMD processor.
There also exists a hardware level reset function, which is not shown,
called PMDHardReset. When the PCI interface is defined this function
will trigger the RESET hardware signal on the PCI bus.
3.2 ISA/PC104 Communication
The use of the ISA bus in a PC has been diminishing recently, however,
the process of reading to and writing from an ISA bus is simpler than
for a PCI bus. Both the hardware and software are less complicated to
implement. For this reason the ISA bus may be preferred over the PCI
bus when the developer is using an embedded host processor.
The PC104 bus is almost exactly the same as the ISA bus. The difference
is that the PC104 bus has extra ground pins and the pin layout has different
geometry. To detail the interface design to both the ISA bus and the
PC104 bus would be redundant, therefore the PC104 interface will not
be explicitly detailed. If a PC104 bus is desired then the following
ISA bus design will provide an excellent reference.
3.2.1 ISA Hardware
When confronted with the task of developing hardware to talk to
the PMD chipset via an ISA or PC104 bus, the developer has two reference
designs to select from. The designs differ in that one combines much
of the hand shaking signals into an Altera PLD, while the other depicts
the hand shaking signals being handled by low level logic devices.
The reference design utilizing a PLD is an interface to a Navigator
chipset. The non-PLD design interfaces a Magellan chipset. The interface
logic used in the two designs is identical, only the implementation
is different.
Figure 3.5 shows the more basic handling of the hand shaking signals.
The ISA bus (and PC104 bus) is driven with TTL levels as a standard.
Level shifters are used in between the ISA bus and the Magellan IO
for translation of data bus and ~HOSTREAD and ~HOSTWRITE. This interface
assumes a base address is assigned in the address space of A9-A0 (300-400
hex). These addresses are generally available for prototyping and
other system-specific uses without interfering with system assignments.
This interface occupies 16 addresses from XX0 to XXF hex though it
does not use all the addresses. Four select lines are provided allowing
the base address to be set from 300 to 3F0 hex for the select lines
SW1-SW4 equal to 0- F respectively. The address assignments used are
as follows. (For this example a BADR of 340 hex was chosen):
| Address |
Use |
340h
|
read-write data |
342h
|
write command -read status |
344h
|
write command -read status |
348h
|
write reset [Data = don't care] |
The base address (BADR) is decoded in the74LS688. It is combined
with SA1, SA2, and SA3, (BADR+0,2,4) to form HSELN to select the I/O
chip and the 164245’s. SA1 and SA2 (BADR+2,4) also create the
HCMD signal after being OR’d . Two addresses are used to be
compatible with the first generation products, which used BADR+2 to
write command and BADR+4 to read status.
B+8 and IOW* generate a reset pulse, -RS, for the CP chip. The reset
instruction is OR'd with RESET on the bus to initialize the PMD chip
set when the ISA bus is reset. Additional devices (MAX6326) have been
added to guarantee reset is held for the minimum required length of
time after power on. Furthermore, U24 is used to guarantee synchronization
between the release of the RESET signal and the 20MHz clock, regardless
of the source of the RESET. The ~HREAD and ~HWRITE signals come directly
from the ISA bus after being shifted down to 3.3V. Note that this
schematic shows the 16/16 communication mode.
When using this design with a Navigator, the level shifting devices
should be removed. The 164245’s can be replaced with 245 buffers.
The RESET synchronization is not required on a Navigator and so U24
can be eliminated. Any other 3.3V devices (for instance the clock)
should be replaced with 5V devices.
Click to Enlarge
Figure 3.6 demonstrates how the low level logic devices can be replaced
by an Altera EPF6016TC144-3 PLD (U17). The program for this PLD is
stored on an Altera serial EPROM EPC1441PC shown as device U18. Logic
schematics and design files for this Altera PLD are available from
the PMD Application Notes Web Page.
A PLD ISA interface to a Magellan can still be accomplished using
these designs as a starting point. The timing and functions of the
handshaking signals on the bus remain identical. In the case of the
Magellan the HostData bus and associated hand shaking signal must
be driven with 3.3V logic. This can be accomplished with a 3.3V compatible
PLD.
The design that uses the PLD has some additional functionality that
allows selection of the interrupt line on the ISA bus. As noted on
the schematic, SW[5-7] encodes the interrupt line being selected.
The HOSTINT- signal from the PMD CP will be sent to one of the ISA
interrupt lines. Which interrupt line the signal will be sent to depends
on the switch selection.
The PLD code supplied by PMD also uses the PLD to handle other signals
associated with home switches, limit switches and motor interface
signals. HOSTMODE0 and HOSTMODE1 have been tied to ground which means
16/16 communication mode.
Click to Enlarge
3.2.2 ISA Software
The C-Motion library contains two examples specific to communication
with an ISA bus. Like the PCI example, the ISA examples utilize drivers
specific to the Windows OS. In particular one driver will only work
on more recent Windows platforms while the other driver will only
work on earlier Windows platforms.
3.2.2.1 Using an ISA bus with a Windows Host
The DriverIO.cpp example utilizes ISA communication drivers intended
for use on PC running Windows 9x, Windows NT, Windows 2000, or Windows
XP. The driver was created from a third-party Windows driver development
package. The ISA address that is used by the driver is stored in
the system registry. This address is set and stored to the registry
by using the PMDBoardSetup.exe application that is included with
C-Motion. When this application is launched the following screen
will appear:
From this application you can select the ISA address that the driver
will use to access the PMD device. This driver should not be used
on a DOS platform.
// DriverIO.cpp (modifidied)
#define PMD_DRIVER_INTERFACE
#include "C-Motion.h"
#include "PMDutil.h"
#include <stdlib.h>
#include <stdio.h>
// the axis handle object
PMDAxisHandle hAxis1,hAxis2;
int main(int argc, char* argv[])
{
PMDuint8 ui8major, ui8minor;
PMDuint16 generation, motorType, numberAxes, special, custom,
major, minor;
PMDSetupAxisInterface_Driver( &hAxis1, PMDAxis1 );
// use the same transport for Axis#2 because it resides on the
same chip
PMDCopyAxisInterface( &hAxis2, &hAxis1, PMDAxis2 );
if ( !PMDChipsetReset( &hAxis1 ) )
{
printf("Reset failed\n");
return 1;
}
PMDGetCMotionVersion( &ui8major, &ui8minor );
printf("C-Motion Version %d.%d \n", ui8major, ui8minor);
// just do some easy gets to make sure comms are working
PMDGetVersion(&hAxis1, &generation, &motorType, &numberAxes,
&special, &custom, &major, &minor);
printf("Navigator MC%d%d%d0 Version %d.%d\n\n", generation,
motorType, numberAxes, major, minor);
// free any axis handle memory that was allocated
PMDCloseAxisInterface(&hAxis1);
return 0;
}
Note the use of #define PMD_DRIVER_INTERFACE causes
a link to the PMDdrv.c file. Further investigation into the PMDdrv.c
module will reveal that PMDdrv utilizes other drivers based on whether
the OS is Windows 9x or Windows NT. The virtual axis handle is now
initialized with a call to PMDSetupAxisInterface_Driver.
From this point the example uses the same command syntax as the
PCI example.
3.2.2.2 Using an ISA Bus with a Generic Host
The other C-Motion example specific to communication with an ISA
bus is intended for a host running on Windows 9x and DOS. However,
this example is also important to those developers who wish to use
a microcontroller running a non-Window OS. This is because the lower
level communication functions can be easily modified to work on
many processors and microcontrollers that utilize a port-mapped
communication scheme. The example shown below is a modification
of the ParIO.c example:
// ParIO.c (modified)
#define PMD_PARALLEL_INTERFACE
#include "C-Motion.h"
#include "PMDutil.h"
#include <stdlib.h>
#include <stdio.h>|
// the axis handle object
PMDAxisHandle hAxis1,hAxis2;
int main(int argc, char* argv[])
{
PMDuint8 ui8major, ui8minor;
PMDuint16 generation, motorType, numberAxes, special, custom,
major, minor;
// The third parameter represents the ISA port address (0=default
0x340)
PMDSetupAxisInterface_Parallel( &hAxis1, PMDAxis1, 0 );
// use the same transport for Axis#2 because it resides on the
same chip
// so must use the same interface, that is, the IO address
PMDCopyAxisInterface( &hAxis2, &hAxis1, PMDAxis2 );
if ( !PMDChipsetReset( &hAxis1 ) )
{
printf("Reset failed\n");
return 1;
}
PMDGetCMotionVersion( &ui8major, &ui8minor );
printf("C-Motion Version %d.%d \n", ui8major, ui8minor);
// just do some easy gets to make sure comms are working
PMDGetVersion(&hAxis1, &generation, &motorType,
&numberAxes,
&special, &custom, &major, &minor);
printf("Navigator MC%d%d%d0 Version %d.%d\n\n", generation,
motorType, numberAxes, major, minor);
// free any axis handle memory that was allocated
PMDCloseAxisInterface(&hAxis1);
return 0;
}
Note the use of #define PMD_PARALLEL_INTERFACE that causes a link
to the PMDpar.c file. Investigation into the PMDpar.c module will
reveal the utilization of the inpw and outpw function calls which
are defined in the conio.h file. The conio.h file is provided
by Windows and is only useful for accessing an ISA space when
the OS is Windows 9x or DOS based. This information is useful
for a non-Windows platform because the inpw and outpw functions
will be replaced with platform specific functions. Many microcontrollers
come with their own version of the inpw and outpw functions which
read and write 16-bit or 8-bit packets to a port mapped space.
Very often, on an 8-bit microcontroller, these functions are replaced
by “PortA=<8-bit data>” for writes or “<8-
bit data>=PortA” for reads.
In the case of this example the ISA address is defined by the
third argument of the function that initializes the virtual axis
handles, PMDSetupAxisInterface_Parallel. This example shows that
argument as zero (0), which is a default value that gets translated
to an ISA base address of 0x340. If 0x340 is not the desired base
address, then any hexadecimal value representing the valid base
address can be the third argument to the PMDSetupAxisInterface_Parallel
function call. The PMDpar.c file will automatically generate the
data port and command port address as +2 and +4 offsets from the
base address. These address offsets adhere to the values seen
in the table presented in Section 3.2.1 of this document.
3.3 Using Parallel Communication with Pilot
or single-axis Magellan
As mentioned before, the creation of a parallel interface to a Pilot
or 1-IC Magellan processor is handled differently. With the addition
of an external logic device, the Pilot and single-axis Magellan motion
processors can communicate with a host processor using a parallel data
stream. This offers a higher communication rate than a serial interface
and may be used in configurations where a serial connection is not available
or not convenient. PMD provides a reference design for an Actel
A42MX16 logic device. The Actel part can be used with any of the parallel
communication schemes presented here. The communication software that
runs on the host processor will be identical, but still specific to
the communication scheme being used.
Figure 3.7 demonstrates how the Actel part fits into the interface design
with a Magellan CP. The connections depicted allow for both 3.3V and
5V tolerant inputs. Therefore the same Actel configuration can be used
with a Pilot chip also.
The host bus interface was intentionally omitted from this schematic
to emphasize the fact that the use of the Actel part, in the context
of the parallel interface task, is not specific to a particular bus
type. When implementing the parallel interface with the Pilot or single-axis
Magellan, the ISA and PCI interface designs can be used by replacing
the I/O chip from the Navigator or 2-IC Magellan with this programmed
Actel part.
The reference design files for the parallel interface chip, in ORCAD/MAX+plusII
format, are available from the PMD Application Notes Web Page. There
are two versions of the design, one for interfacing with host processors
that have an 8-bit data bus and one for host processors that have a
16-bit data bus. The designs are called IOPIL8 and IOPIL16 respectively.
The interface to the CP chip is essentially identical in both. The CP
chip of a Pilot or single-axis Magellan utilizes a Parallel Enable pin
number 8 (pin 65 on the Pilot) that is not used on the Navigator and
2-IC Magellan.
Note this pin is tied to Vcc on the schematic.
Click to Enlarge
The function of the Actel chip is to provide a shared-memory style interface
between the host and CP chip, comprised of four 16-bit wide locations.
These are used for transferring commands and data between the host and
Magellan motion processor. The CP chip accesses the command/data registers
using its 16-bit external data bus while the host accesses the registers
via a parallel interface with chip select, read, write and command/data
signals. If necessary, the host side interface can be modified by the
designer to match specific requirements of the host processor.
For further details on how to implement this interface please reference
the Pilot Technical Specifications. This document can be downloaded
from the PMD website. The program file and reference design files for
the Actel part can be obtained from the PMD Applications Notes
Web Page.
The selection of host software used to communicate to a Pilot or single
axis Magellan when utilizing the design mentioned here is no different
than the software used to communicate to a Navigator or 2-IC Magellan.
This is due to the fact the Actel part shown in this design will handle
the same bus signals that PMD IO chip does. Hence the hand-shaking requirements
remain the same and the bus interface remains the same.
3.4 8-bit Parallel Host Bus
All previous parallel interface designs presented so far have utilized
PMD’s 16/16 mode. Use of 16/16 mode implies a 16-bit parallel
interface to the Host Data bus of PMD I/O chip. (In the previous section
the Host Data bus is on the Actel part). There exists another format
referred to as 8/16 mode, which is used with an 8-bit parallel interface
to the HostData bus of the PMD I/O chip. As would be expected, 8/16
mode implies sending or receiving 8-bit packets at time. Section 3.3
introduces the concept of 16-bit parallel communication to a Pilot or
single axis Magellan. There also exists an 8-bit design for the parallel
communication based on the same Actel part. The program file and reference
design files for the Actel part can be obtained from the PMD Applications
Notes Web Page.
3.4.1 8/16 Interface Hardware
Figure 3.8 demonstrates the use of an 8-bit parallel interface on
a Navigator controller. Figure 3.8 can also be used as a reference
for an 8-bit parallel interface to a 2-IC Magellan processor. There
are two pins present on the PMD CP chip labeled HostMode0 and HostMode1.
These pins are also present on a Magellan CP but will have different
pin numbers. The configuration of these pins informs the PMD CP which
parallel format is being used. As in the previous schematic, the bus
interface has not been shown. In the context of the PLD ISA bus interface
the only difference is that now only the 8 LSB of the HostData bus
are connected to the PLD. In the context of the non- PLD ISA design
(Figure 3.5), one octal buffer can be omitted and an additional 8-bits
on the ISA data bus are left unconnected.
Click to Enlarge
3.4.2 8/16 Interface Software
The C-Motion API does provide an option that allows the user to
choose 8/16 mode for communication. This does not affect the high-level
functions in C-Motion. The difference occurs at a low level in that
reads and writes to the ISA bus from the host are now done in 8-bit
packets. As mentioned in Section 3.2.2.2, C-Motion utilizes the inpw
and outpw functions to write and read 16- bit packets to the host
side ISA bus. In 8/16 mode, C-motion will use OutP8Bit and InP8Bit
to write and read 8-bit packets to the host ISA bus. Once again these
are Windows specific ISA drivers defined in conio.h. When utilizing
a non-Windows host, these 8-bit functions should be replaced with
equivalent 8-bit I/O commands specific to the interface type or platform
being used.
The amount of data contained within an 8-bit packet is only half of
the data contained in a 16-bit packet. As a result, the number of
writes and reads required to transfer an equal amount of data will
double when using 8/16 mode. For instance, a command write is done
by sending the upper 8 bits of a 16-bit command packet first, followed
by the lower 8 bits. In order to send the lower 8 bits, only the ~HOSTWRITE
signal needs to be strobed and the remainder of the hand shaking signals
can remain in the same sate used to send the upper 8-bits.
3.5 Serial Communication
Serial communication on the PMD chipset is also an option to be
considered by the developer. Even though serial communication is slower
than parallel communication it is very often adequate. When communication
speed is not an issue then serial communication should be considered
to reduce design complexity and the number of peripheral components
such as PLDs and octal buffers. As mentioned before the HostMode0
and HostMode1 pins on the PMD IO chip define the communication mode
on a Navigator and 2-IC Magellan. When both of these pins are connected
to Vcc, the CP is in “Serial Only” ( “Parallel Disabled”)
mode. This implies that any attempts at parallel communication to
the chip set will be ignored. On a Pilot or single axis Magellan design
this would be equivalent to tying CP pin 65 (Parallel Enable) to ground.
When the HostMode0 and HostMode1 pins on the PMD IO are in some other
configuration, then both serial and parallel communication is permitted.
The behavior of the Magellan and Navigator differ slightly in this
condition. On the Navigator the serial port is considered a “diagnostic”
port and the number of commands that can be used over the serial port
is reduced. The number of commands supported by the serial port can
be expanded to the full range of the command set by sending a command
through the parallel interface. This command will be further detailed
in the Section 3.5.6. There is no such thing as a “diagnostic
port” on the Magellan and the full range of commands are supported
through the serial port regardless of the state of HOSTMODE0 and HOSTMODE1.
On a Pilot or 1-IC axis Magellan design, both serial and parallel
communication is permitted as long as the ParallelEnable pin of the
CP is tied to Vcc. In this situation the serial port is not considered
a “diagnostic” port and the full command set is supported
over the serial port by default.
Before examples of RS232/422/485 are introduced it is worth mentioning
that TTL (or LVTTL) level serial communication between the host and
the PMD CP can also be used. This eliminates the need for a RS232/422/485
transceiver and results in a direct connection to the SRLRCV and SRLXMT
pins on the PMD CP. To ensure signal integrity this should only be
attempted when the host processor and PMD CP coexist on the same circuit
board. When implementing a serial scheme at the TTL level bear in
mind that the Navigator will use 5V TTL and the Magellan will use
3.3V LVTTL.
PMD recommends a connector that accesses the serial pins on
the CP be present on board designs even if there is no intention of
using serial communication. The serial connection can be used during
development and production to debug the parallel interface.
3.5.1 Serial Configuration
After reset, the chipset reads a 16-bit value from its peripheral
bus (location 200h) that is used to set the default configuration
of the serial port. If the serial port is to be used, then external
hardware should be used to decode this address and provide a suitable
configuration word as described in the User’s Guide for the
product you are using. Also reference the User’s Guide for details
on peripheral bus I/O and for a description of the parameters that
compose a serial configuration. Figure 3.9 demonstrates the use of
pull up resistors and dipswitches for writing the 16-bit serial configuration
to the data bus. The user is responsible for selecting appropriate
resistor values based on layout and
board design.
Alternatively, if adding external-decoding hardware is not desirable
then the CP’s external data bus may be pulled up using high
value resisters (for example 4.7 Kohm). This will cause the chipset
to read FFFFh from address 200h. When this value is read the chipset
will set up the serial port in the default configuration of 9600 baud,
no parity, one stop bit, point-to-point mode.
3.5.2 RS232
Note: The information presented in Sections 3.5.2, 3.5.3, and
3.5.4 is also applicable to a PMD MC73110 motion
processor.
Figure 3.9 demonstrates the use of an RS232 transceiver. This device
is used to shift the voltage from RS232 levels to LVTTL levels. When
the serial data is at the TTL (or LVTTL) voltage level it can be sent
directly to the PMD CP. The schematic shows that the other side of
the transceiver is connected to a female DB9 serial port connector.
This connector would be suitable for the serial port on a PC. Note
that the SRLENABLE pin on the CP is left unconnected because it is
not used in point-to-point serial mode.
The RS232 interface and serial configuration for the Navigator and
Pilot is very similar to what is shown in Figure 3.9. The primary
difference is that Vcc for the Navigator and Pilot CP’s is 5V.
However the transceiver shown (ADM3202) is 5V tolerant and may be
used in a Navigator or Pilot serial interface. The voltage supply
to the transceiver should still be 3.3V when used with a Navigator
or Pilot.
Click to Enlarge
3.5.3 RS422
Figure 3.10 demonstrates the use of an RS422/485 transceiver. The
wiring to the host side DB9 connector is specific to RS422. RS422
is a point-to-point protocol that utilizes differential signal lines
to reduce noise. This is an RS422 advantage that allows for longer
physical connections. The SRLENABLE line is not shown and can be left
unconnected. (Whenever Point-to-Point communication is used, SRLENABLE
remains active regardless of the communication state.) When this transceiver
is supplied with 3.3V all slave side signals are 3.3V LVTTL compatible,
and when supplied with 5V all slave side signals are 5V TTL compatible.
Therefore VCC becomes 3.3V when used with a Magellan and 5V when used
with a Navigator or Pilot.
Click to Enlarge
3.5.4 RS485
The RS485 protocol allows the use of MultiDrop addressing. This
allows the host to send a command through the serial port that is
only intended for one PMD device although many PMD devices may be
present on the line. This can be done because each PMD device, when
properly configured, will have its own unique MultiDrop address. The
address of the intended recipient is embedded in the command sent
by the host. Hence each PMD device on the line will ignore the command
unless the address matches their own. The introduction of RS485 is
the first time a Half- Duplex scheme has been mentioned in this document.
Figure 3.11 shows an RS485 MultiDrop connection to two PMD devices.
One device is address 1 and the other is address 2. Whichever device
is considered the “last” in the daisy chain should have
a terminating resistor as shown in the schematic. If a Non-PMD device
is to be used alongside a PMD device in the same Multidrop network,
the device must expect the address byte to the first byte in a command
packet if idle-line mode is to be employed. See section 3.5.7 for
more information on idle-line mode.
The transceiver shown in Figure 3.11 is the same transceiver as shown
in Figure 3.10. Note that now the SRLENABLE signal is being used because
it is assumed that RS485 will be used with Multi-Drop mode activated.
When Multi-drop mode is specified, the SRLENABLE line is low by default
and only goes high when the PMD device is transmitting. Note the different
supply voltage for the transceiver based on whether a Magellan, Navigator
or Pilot is being interfaced.
Click to Enlarge
3.5.5 CAN (Controller Area Network)
The PMD Magellan product can integrate into a CAN 2.0B network and
will coexist with (but not communicate with) CANOpen nodes on that
network. The Magellan will only support 11-bit identifiers. Magellan
uses CAN to receive commands, send responses, and optionally send
asynchronous event notification. Each message can carry a data payload
of up to 8 bytes. The CAN interface layer automatically corrects transmission
errors, so a checksum is not a part of the motion IC’s CAN interface
protocol as it is with serial or parallel communication. The CAN protocol
will automatically handle bus contention issues as well.
The parameters used for CAN communication are configured in the same
manner as the serial configuration except using a different value
on the address bus. After reset, the chipset reads a 16-bit value
from its peripheral bus (location 400h) that is used to set the default
configuration of the CAN port. If CAN is to be used, then external
hardware should be used to decode this address and provide a suitable
configuration word as described in the Magellan Electrical Specifications.
Also reference the User’s Guide for details on peripheral bus
I/O and for a description of the parameters that compose a CAN configuration.
Figure 3.9 can be used as a reference for using pull up resistors
and dipswitches for defining the CAN configuration with the exception
that ADDR10 will be used for decoding.
Every CAN message begins with an identifier (address). The Magellan
Motion Processor User’s Guide should be referenced for a description
and format of the identifier. The remainder of the message contains
the data payload. The Magellan Programmer’s Command Reference
details the command packet that will populate the data payload. The
use of a standard CAN transceiver (SN65HVD232Q) and subsequent connections
are shown in Figure 3.12.
Click to Enlarge
3.5.6 Point-to-Point
The various connections for serial communication have been shown
in the above sections. RS232 and RS422 are most commonly used in Full
Duplex and therefore is associated with point-to-point protocol. The
C-Motion API contains an example of point-to-point communication called
SerialIO.c which is shown below.
//SerialIO.c (modified)
#define PMD_W32SERIAL_INTERFACE
#include "C-Motion.h"
#include "PMDutil.h"
#include <stdlib.h>
#include <stdio.h>
// the axis handle object
PMDAxisHandle hAxis1,hAxis2;
int main(int argc, char* argv[])
{
PMDuint8 ui8major, ui8minor;
PMDuint16 generation, motorType, numberAxes, special, custom, major,
minor;
// by default the serial interface will be set to COM1, 57600
and
// the point-to-point protocol
// The third parameter represents the COM port number (0=default
of COM1)
if (PMD_NOERROR != PMDSetupAxisInterface_Serial( &hAxis1, PMDAxis1,
0 ))
{
printf("Board initialization failed\n");
return 1;
}
// use the same transport for Axis#2 because it resides on the
same chip
// so must use the same interface, that is, the same serial port
PMDCopyAxisInterface( &hAxis2, &hAxis1, PMDAxis2 );
PMDGetCMotionVersion( &ui8major, &ui8minor );
printf("C-Motion Version %d.%d \n", ui8major, ui8minor);
// just do some easy gets to make sure comms are working
result = PMDGetVersion(&hAxis1, &generation, &motorType,
&numberAxes,
&special, &custom, &major, &minor);
printf("Navigator MC%d%d%d0 Version %d.%d\n\n", generation,
motorType,
numberAxes, major, minor);
PMDCloseAxisInterface(&hAxis1);
return 0;
}
The use of #define PMD_W32SERIAL_INTERFACE causes a link to the PMDW32Ser.c
module. The PMDW32Ser.c file contains functions that utilize Windows32
serial port utilities like SetComState, WriteFile and ReadFile. Access
to these utilizes is realized by including Windows.h in the module.
Once again AxisHandles have been created. This time, however, the
PMDSetupAxisInterface_Serial function is used to initialize the interface.
The third argument to this function call represents the COM port number
associated with that Axis Handle. Any number of axis handles can share
the same COM port. The PMDSetupAxisInterface_Serial function will
call the PMDSerial_InitData function, defined in PMDW32Ser.c, which
will initialize serial configuration parameters such are baud rate,
parity, and number of stop bits. After the Axis Handles have been
initialized the PMDSerial_SetConfig function can be used to change
the configuration parameters from their default values. The function
will only change the serial parameters currently being used by the
host (Windows). (Reference PMDSetSerialPortMode for changing serial
parameters on the PMD device.)
As mentioned at the beginning of Section 3.5, a Navigator may be configured
to treat its serial port as a diagnostic port, which means that not
all commands are supported. In this situation, if it is desirable
for the serial port to support the full set of commands then the PMDSetDiagnosticPortMode
C-Motion function can be used to enable processing of all
commands over the serial port. The command is not supported in the
Magellan or Pilot.
3.5.7 MultiDrop
The electrical connections used in RS485 are most commonly Half
Duplex. This allows for a daisy chain of PMD devices that need to
be addressed. The MultiDrop protocol embeds a device address in the
communication packets so that the PMD devices know which device the
communication was intended for. Support for this scheme is provided
in C-Motion which can be seen in the C-Motion example called SerialMultiDropIO.cpp.
This example can be used with the MultiDrop scheme shown in Figure
3.12. Below is a section a code pulled from that example.
// SerialMultiDropIO.cpp (modified)
if (PMD_NOERROR != PMDSetupAxisInterface_Serial
( &hAxis1Address1, PMDAxis1, 0 ))
{
PMDprintf("Board initialization failed\n");
return 1;
}
// for reliable RS-485 communications baud needs to be 9600 or lower
// because the PMD chip responds immediately after a command and the
// communications line may not be disengaged in time from the last
send.
// set baud to 9600 and no parity.
PMDW32Serial_SetConfig(hAxis1Address1.transport_data, 9600, 0);
// set the mutli-drop protocol.
//(Protocol_PointToPoint,Protocol_ModeAddressBit,Protocol_IdleLine)
PMDW32Serial_SetProtocol(hAxis1Address1.transport_data, Protocol_IdleLine);
// set the address to 1 (the default is 0)
PMDW32Serial_SetMultiDropAddress(hAxis1Address1.transport_data, 1);
// use the same axis handle for address #2 because where using the
same COM
//port but set the multi-drop address to 2.
PMDCreateMultiDropHandle( &hAxis1Address2, &hAxis1Address1,
PMDAxis1, 2 );
As in the previous serial example, PMDSetupAxisInterface_Serial
is used to initialize the axis handle. However this function will
not use the correct configuration parameters for MultiDrop and subsequent
functions must be used to obtain the correct configuration parameters.
As mentioned in the source code comments, a maximum baud rate of 9600
bps is recommended during intial attempts at RS485. The user is free
to experiment with faster baud rates but the user should bear in mind
that the CP responds immediately to a serial command and the host
side serial controller may not release the serial line in time which
will cause problems. The Magellan will wait for one byte time (baud
rate
dependant) before responding to the host. The Navigator or Pilot may
respond much faster (1 bit time). PMD recommends starting off with
9600 bps because slower baud rates tend to alleviate this problem.
IdleLine vs. AddressBitMode
When using MultiDrop mode a decision must be made as to whether to
use the IdleLine protocol or the AddressBitMode protocol. The User’s
Guide goes into detail about the difference between these two protocols.
In short, the IdleLine protocol recognizes an address byte as the
beginning of a new data packet when the address byte is received after
a specified amount of “idle time” has passed. Once an
address byte is received that matches the address of the PMD device,
the device will wait for the rest of the command packet without potential
of a time-out occurring. This places tight timing requirements on
the communication. When using AddressBitMode protocol each byte of
data contains an extra bit. When this bit is set, the PMD device interprets
this as an address byte and therefore the beginning of a new data
packet. The above example uses the PMDW32Serial_SetProtocol
function to specify the IdleLine protocol. The argument to this function
can be changed if the AddressBitMode protocol is desired.
The PMDW32Serial_SetMultiDropAddress function is
used to set the MultiDrop address specific to that Axis Handle. If
the user wants to initialize an Axis Handle for a multi-axis PMD device
that already has an existing axis handle (same MultiDrop address)
then the PMDCopyAxisInterface function can be used.
More often than not the user will need to initialize an Axis Handle
for a PMD device that does not have any axis handles pointing to it.
The first Axis Handle initialization (hAxis1Address1) uses the PMDSetupAxisInterface_Serial
function and specifies COM1. If the user attempts to use the same
function with a second Axis Handle (hAxis1Address2) and still specifies
COM1, then an error will be returned because COM1 is already open.
For this reason the user must use the PMDCreateMultiDropHandle
function to initialize the second axis handle using COM1. The final
argument of this function is the address of the new axis handle. The
second argument is the first Axis Handle that was already created
with the standard PMDSetupAxisInterface_Serial function.
The second Axis Handle will have the same serial configuration parameters
as the first Axis Handle with the exception of the MultiDrop address
that is specified in the final argument. The PMDCreateMultiDropHandle
function should not be used until the first Axis Handle contains properly
configured serial parameters.
3.6 Host Communication Troubleshooting
The aforementioned reference schematics and software examples will
provide a stable communication scheme to any PMD device. However, due
to a wide range of hardware or software issues, communication problems
may still arise. For this reason, some procedures for troubleshooting
communication problems will be discussed.
Before delving into communication errors, some basic items can be checked
first to ensure that the PMD chip is “alive”. The following
Hardware requirements must be met before the chip will come to life
and respond to commands:
- Check pin level connections:
- Ensure all Vcc lines, Ground lines, and the CLK signal are connected
to the CP (and IO if applicable)
- Ensure all required connections between the CP chip and IO chip
are present. (Only applicable to multi chip products like Navigator
and 2-IC Magellan)
- In the case of a 2-IC Magellan or Navigator design verify the clock
signal on the IO pin labeled
“CPCLOCK”.
- In the case of a Magellan design verify the clock signal on the
CP pin labeled “CLOCKOUT”.
- Ensure CPRESET is being held and released according to the timing
diagram in the Technical Specifications. The user should wait 20.0
milliseconds after the reset release before attempting to send an
instruction (including a status read). 2-IC Magellan devices introduce
another timing requirement related to CPRESET. The CPRESET signal
must be synchronized to the 20MHz clock output from the Magellan IO
in that it must be released no more than 6ns after a rising edge of
the 20MHz clock.
- The state of the AXISOUT1 pin can be checked. If the above conditions
have been met then the chip (or chipset) should be alive and the AXISOUT1
pin should be at 5V (3.3V on the Magellan). If this is not the case
or if the AXISOUT1 pin does not remain active then all attempts at
communication will be futile.
3.6.1 Troubleshooting Parallel Communication
- When attempting parallel communication the HOSTRDY signal must be
active before any communication will occur. The state of this signal
can be determined by checking the HostRdy pin on the CP or by checking
the HOSTRDY bit in the status read. (A status read operation can be
performed regardless of the state of the HOSTRDY signal).
- A status read after the required wait time after reset should return
0xA in the upper byte. Bit 15
represents the HOSTRDY signal. Bit 13 is a Host I/O Error that is
active because a reset has
occurred.
- A GetHostIOError command will clear bit 13 of the status read. Subsequent
status reads should
return 0x8 in the upper byte.
- The NoOp command can be sent to verify communication and checksums.
- Performing a data read after communication has completed will always
return the checksum from the last command sent to the CP. Reading
of the checksum is not required but is strongly recommended for verification
of communication integrity.
- A special test procedure can be performed that requires the CP
RESET line be held active. Depending on whether 8-bit or 16-bit parallel
communication is being used, the host can write an 8-bit or 16-bit
word to the PMD chip. A subsequent read operation should return the
same word that was just written. This should be done many times using
different words so that all bits are tested. The CP RESET line must
be held active at all times during this test.
3.6.2 Troubleshooting Serial communication
- The Serial communication configuration is established when the
PMD chip does a peripheral read after reset is released. On a Navigator
or Pilot this occurs approximately 150us after reset release while
on a Magellan this occurs approximately 1.08ms after reset release.
- If no response at all is received from the PMD device, an oscilloscope
should be used to probe the SRLRCV lines on the CP device to verify
there is activity when the host attempts to send a command. If there
is activity on the SRLRCV line the next step is to probe the SRLXMT
line for activity.
- If a half-duplex system is to be used, the hardware is responsible
for disabling the transceiver’s receive buffer on the device
transmitting the data. This must be done so that the data is not echoed
back into the transmitting device, otherwise software must ignore
the echo. Figure 3.11 is an example of a device with this functionality.
There is no provision in C-Motion or ProMotion for handling an echo.
- In Point-to-Point Mode:
It is highly recommended to send one ZERO byte at a time to the PMD
chip. Continue sending one ZERO byte at a time until a valid response
(two ZERO bytes) is returned by the PMD chip. The PMD chip will recognize
four ZERO bytes as a NoOp command and respond with two ZERO bytes.
Sending one byte at a time until a valid respond is received ensures
serial synchronization by flushing the PMD chip’s receive buffer
of any garbage.
- In MultiDrop Mode:
- The above synchronization procedure does not work in MultiDrop
mode. In this case special attention must be paid to the point
in time when the PMD chip responds. If the PMD chip is responding
before the entire command is sent by the host then it can be assumed
that garbage was present in the receive buffer of the PMD chip.
When MultiDrop mode protocol is being used the only time its possible
for garbage to accumulate in the PMD receive buffer will be after
a valid address byte has been received.
- Most RS485 transceivers will leave the outputs on the network
side at high impedance when in the idle state. This results in
floating signal lines that need to be pulled up or down.
- Improper termination is a common cause of RS485 problems. Sometimes
termination will cause more problems than it solves. Use an ohmmeter
to determine which nodes are terminated.1
1 Mike Fahrion, B&B Electronics, Vance VanDoren, “Troubleshooting
RS-485 Networks”, Control
Engineering, March 2005
|
|
