Introduction

Nikon A-format absolute encoder receiver implementation on the TI PRU-ICSS interfaces with the Nikon A-format encoders either via point-to-point communication or up to 8 Nikon A-format encoders connected on a bus. Nikon A-format encoders use a proprietary asynchronous serial bi-directional half-duplex communication protocol compliant with RS-485. The encoder can generate either single- or multi-turn absolute position data and can operate at a baud rate of up to 16 MHz. Besides position data, the encoder can also send status and diagnostic information as well. Reliability is ensured by using a 3-bit CRC by the receiver and an 8-bit CRC by the encoder. Another interesting feature of the Nikon-A encoders is the optional battery backup circuit, which can be used in case of power failure. Nikon A-format encoders are widely used in industrial machinery, including industrial robots in automobile production lines and machine tools, and are highly valued as the next-generation standard for sensors that can detect the absolute rotational displacement values of robot arms.

Note: This implementation using Peripheral input/output mode of PRU-ICSS. Refer Peripheral IF mode for more details.

Features Supported

Support for Nikon version 2.1 and Nikon version 3.0
Support for point-to-point and bus communication (up to 8 encoders).
Support for baud rates from 2.5 MHz, 4 MHz, 6.67 MHz, 8 MHz, and 16 MHz.

Support for oversampling ratio with different baud rates.

Clock Source	Interface Speed
Clock Source	2.5 MHz	4 MHz	6.67 MHz	8 MHz	16 MHz
PRU UART Clock (192 MHz)	Not tested	8x	Not tested	8x	8x with fractional div
PRU Core Clock (200 MHz)	8x	Not tested	6x	Not tested	Not tested
PRU Core Clock (300 MHz)	8x	Not tested	6x with fractional div	Not tested	Not tested

Support for concurrent multi-channel support on a single PRU (up to 3 channels with identical number of encoders of the same frequency connected to all configured channels).
- In this mode, data transmission and reception must happen simultaneously on all channels.
- The encoder configuration and cable length should be the same on all channels.
- If encoders across channels don't respond at the same time, this mode will not work. Load share configuration should be used instead.
Support for multi-channel with different communication modes and different numbers of encoders connected across channels under load share mode (Refer Load Share Mode for more details).
- In this mode, data transmission and reception can happen independently on all channels.
- After a command is sent, all channels wait for a response and process the response independently. However, all channels must finish processing before the next command can be triggered.

Features Not Supported

In general, peripherals or features not mentioned as part of the "Features Supported" section are not supported in this release, including the following:

Independent clocks on multi channel mode.

Known Limitations

Limitation with BP-AM2BLDCSERVO boosterpack with TI LaunchPad
- Hardware Limitation with BP-AM2BLDCSERVO
  - Only up to 7 encoders in bus connection have been tested with BP-AM2BLDCSERVO
  - This limitation is due to insufficient voltage when attempting to power 8 encoders
  - Attempting to connect 8 encoders may result in unreliable operation
- Software Support
  - The example code and PRU firmware are designed to handle 8 encoders
PRU Firmware gets stuck if encoder does not respond with the number of bytes expected by the driver as per PINDSW-9179 in Release Notes 11.00.00
- Example cases when firmware gets stuck
  1. Any command is sent with encoder address not matching that of the encoder connected with the device
  2. In bus mode, if encoders with addresses 0, 1, 2 are connected and MT command is sent with encoder address 3 or more
  3. Command 20 is sent with ID not matching the encoder connected with the device

SysConfig Features

Note: It is strongly recommend to use SysConfig where it is available instead of using direct SW API calls. This will help simplify the SW application and also catch common mistakes early in the development cycle.

SysConfig can be used to configure the following:

Selecting the ICSSG instance. (Tested on ICSSG0)
Selecting the ICSSG0PRUx instance. (Tested on ICSSG0-PRU1)
Configuring PINMUX.
Frequency selection.
Channel selection.
Selecting Multi Channel with encoders connected in Different Configurations (bus or one-to-one) using load share mode.
Enabling SA Mux mode.
Selecting source clock.
Selecting Nikon protocol version (2.1 or 3.0)

Note: Nikon firmware supports operation with ICSS Core Clock running at 200 MHz/300 MHz frequency or ICSS UART Clock running at 192 MHz only. ICSS Core Clock at 225/250/333 MHz is not supported due to clock divider requirements.

ICSS PRU Resource Usage

Configuration	PRU Core	Memory Usage	IEP Usage	Other Peripheral Usage	Description
Single channel	PRUx	DMEM: 549 Bytes (0x0 to 0x225) IMEM: ~ 1.4 kB	IEP0: CMP0 and CMP3	INTC event/input number 18 (pr[0/1]_pru_mst_intr[2]_intr_req) is used to trigger interrupt to Arm® Cortex®-R5F	IEP, CMP events and INTC signal are used only in periodic continuous mode.
Multi-channel with single PRU core	PRUx	DMEM: 549 Bytes (0x0 to 0x225) IMEM: 1700 Bytes	IEP0: CMP0 and CMP3	INTC event/input number 18 (pr[0/1]_pru_mst_intr[2]_intr_req) is used to trigger interrupt to R5F	IEP, CMP events and INTC signal are used only in periodic continuous mode.
Multi-channel with load share across 3 PRU cores	PRUx	DMEM: 549 Bytes (0x0 to 0x225) IMEM: 1604 Bytes	IEP0: CMP0, CMP3, CMP5 and CMP6	INTC events/inputs number 18, 19 and 20 (pr[0/1]_pru_mst_intr[2/3/4]_intr_req) are used to trigger interrupts to R5F	IEP, CMP events and INTC signals are used only in periodic continuous mode.
	RTU_PRUx
	TX_PRUx

Note: For pin usage, see Pin Multiplexing page.

NIKON Design

Nikon Protocol Design explains the design in detail.

Example

NIKON Diagnostic

API

APIs for Nikon A-Format Encoder

Note: Arm is a registered trademark of Arm Limited (or its subsidiaries or affiliates) in the US and/or elsewhere.

Table of Contents