External/motor-control-sdk
8
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

am64x/am243x/am263x : add documentation

Browse Source 
add documentation

Fixes: PINDSW-6434

Signed-off-by: Naresh A <nareshk@ti.com>
This commit is contained in:
Naresh A 2023-07-27 16:59:28 +05:30
parent 66708329b5
commit 596d48c7d7
118 changed files with 7277 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

55
docs_src/docs/api_guide/components/motor_control/endat.md Normal file
View File

@ -0,0 +1,55 @@
# EnDat {#ENDAT}
[TOC]
## Introduction
EnDat is a bidirectional interface for position encoders. During EnDat operation the EnDat receiver receives position information from the EnDat position encoder.
## Features Supported
- EnDat 2.2 command set
- EnDat 2.1 command set
- Interrupted and continuous clock mode
- Cable length up to 100m @8MHz
- Propagation delay compensation (capable of handling different propagation delay of different
propagation delay of different channels in concurrent multi
channel configuration)
- Automatic estimation of propagation delay
- Receive on-the-fly CRC verification of position, parameters and additional information
- Two modes of operation - host trigger and periodic trigger
- Channel select
- Concurrent multi channel support (up-to 3 encoders with identical part number @ 8MHz maximum)
- "Multi Channel with Encoders of Different Make" using load share mode (Each of PRU, RTU-PRU, and TX-PRU from one PRU-ICSSG slice handles one channel)
- Safety Readiness: Recovery time
## Features Not Supported
In general, peripherals or features not mentioned as part of "Features Supported" section are not
supported in this release, including the below
- Safety
- Clock configuration up to 16MHz
- Independent clocks on multi channel mode.
## SysConfig Features
@VAR_SYSCFG_USAGE_NOTE
SysConfig can be used to configure things mentioned below:
- Selecting the ICSSG instance. (Tested on ICSSG0)
- Selecting the ICSSG0PRUx instance.(Tested on ICSSG0-PRU1)
- Configuring PINMUX.
- Channel selection.
- Selecting Multi Channel with Encoders of Different Make" using load share mode.
## ENDAT Design
\subpage ENDAT_DESIGN explains the design in detail.
## Example
\ref EXAMPLE_MOTORCONTROL_ENDAT
## API
\ref ENDAT_API_MODULE

352
docs_src/docs/api_guide/components/motor_control/endat_design.md Normal file
View File

@ -0,0 +1,352 @@
# EnDat Protocol Design {#ENDAT_DESIGN}
[TOC]
## Introduction
This design implements EnDat Receiver (a.k.a subsequent electronics) on TI Sitara™ AM64x/AM243x EVM.
EnDat is a digital bidirectional serial interface for position encoders, also suited fo safety related applications.
Only four signal lines are required, differential pair each for clock and data.
Clock is provided by receiver and data is bidirectional. Data is transmitted in synchronism with clock.
Transfer between receiver and encoder at the physical layer is in accordance with RS485, with transceiver at both ends.
## System Overview
Position feedback system consists of a position encoder attached to a motor, up to 100 meter of cable which provides power and serial communication and the receiver interface for position encoder.
In case of Sitara™ AM64x/AM243x processor the receiver interface for position encoder is just one function of a connected drive controller.
The AM64x/AM243x provides in addition to the resources for Industrial Ethernet and motor control application including on-chip ADCs, Delta Sigma demodulator for current measurement.
EnDat Receiver on Sitara™AM64x/AM243x processor uses one ICSSGx Slice.
Clock, data transmit, data receive and receive enable signals from PRU1 of ICSS_G is available in AM64x/AM243x EVM.
## Implementation
The EnDat receiver function is implemented on TI Sitara™ Devices.
Encoder is connected to IDK via universal Digital Interface TIDA-00179(https://www.ti.com/tool/TIDA-00179), TIDEP-01015(3-axis board) and 3 Axis Interface card.
Design is split into three parts – EnDat hardware support in PRU, firmware running in PRU and driver running in ARM.
Application is supposed to use the EnDat driver APIs to leverage EnDat functionality.
SDK examples used the EnDat hardware capability in Slice 1 (either 1 core or 3 cores based ont the confiuration) of PRU-ICSSG0.
Remaining PRUs in the AM64x/AM243x EVM are available for Industrial Ethernet communication and/or motor control interfaces.
### Specifications
<table>
<tr>
<th>Parameter
<th>Value
<th>Details
</tr>
<tr>
<td>Maximum Cable Length
<td>100m
<td>Supports up-to 8MHz with delay compensation
</tr>
<tr>
<td>Maximum Frequency
<td>16 MHz
<td>Supports up-to 20m cable
</tr>
<tr>
<td>Startup/Initialization Frequency
<td>200 KHz
<td>After power on or reset
</tr>
<tr>
<td>Frequencies supported
<td>Upto 8 MHz
<td>Changeable at run-time
</tr>
<tr>
<td>CRC
<td>6 bits
<td>Position/data verification
</tr>
<tr>
<td>Receive oversample ratio
<td>8
<td>
</tr>
</table>
### EnDat PRU hardware
Refer TRM for details
### EnDat Firmware Implementation
Following section describes the firmware implementation of EnDat receiver on PRU-ICSS.
Deterministic behavior of the 32 bit RISC core running upto 333MHz provides resolution on sampling external signals and generating external signals.
It makes uses of EnDat hardware support in PRU for data transmission.
There are three different variations of PRU-ICSS firmware.
1. Single Channel
2. Multi Channel with Encoders of Same Make
3. Multi Channel with Encoders of Different Make
#### Implementation for Single Channel and Multi Channel with Encoders of Same Make
Single core of PRU-ICSSG slice used in this configuration.
\image html endat_module_integration.png "ARM, PRU, EnDat module Integration for for "Single Channel" or "Multi Channel with Encoders of Same Make" configuration"
#### Implementation for Multi Channel with Encoders of Different Make
Each of PRU, TX-PRU and RTU-PRU handle one channel in this configuration
Enbale load share mode in case of multi make encoders.
\image html Endat_load_share_mode.png "PRU, EnDat module Integration for "Multi Channel with Encoders of Different Make" configuration"
#### Firmware Architecture
\image html endat_overall_block_diagram.png "Overall Block Diagram"
Firmware first does initialization of PRU-ICSSG's EnDat hardware interface and EnDat encoder.
Then it waits for the user to provide command (user after setting up the command, sets command trigger bit), upon detecting trigger, first it checks whether the command requested is a continuous mode or a normal command.
If it is a normal command, reads command, it’s attribute like transmit bits, receive bits etc., then it transmits the data and collected the data sent by the encoder stored onto a buffer with one byte representing a bit (since oversample ration of 8 is used).
Next it checks whether there is 2.2 command supplement to be transmitted based on attributes, if so it transmits it.
The received data is now downsampled to extract bit from oversampled 8 bits and the result written to the defined PRU RAM locations.
If command requested is continuous mode, 2.1 position command will be transmitted. During receive, it is different from the normal mode that downsampling is done on-the-fly, i.e. downsampling is done as soon as each bit is received. This is done due to the timing constraints with continuous mode, as data is continuously being received.
At the end of transaction as requested by the user, trigger bit that is set by the user is unset.
User can wait on this bit to know that the command has been completed.
EnDat driver provides API to achieve this.
##### Initialization
###### Initialization for "Single Channel" and "Multi Channel with Encoders of Same Make" configurations
\image html endat_initialization.png "Initilization for Single PRU mode"
###### Initialization for "Single Channel" and "Multi Channel with Encoders of Different Make" configuration
\image html endat_load_share_mode_initialization.png "Initilization for Load share mode"
Before executing the firmware, the ARM (R5) core needs to enable EnDat mode in PRU-ICSSG first, then configure the clock to 200KHz, with oversample ratio of 8 (hence receive clock would be 200 * 8 KHz).
The entire EnDat configuration MMRs are cleared. Through the defined interface (PRU RAM location), user requested channel is determined in Single pru configuration.
Then power-on-init as per specification is implemented, after which encoder is reset by sending reset command.
Firmware setups the command and it’s attribute for all the commands that are sent during initialization. Alarms, errors and warning are cleared.
Firmware then determines number of clock pulses for position and whether encoder supports EnDat 2.2. Propagation delay is then estimated.
If user has required for clock to be configured, it is obeyed, else it defaults to 8MHz. At the end of the initialization status is updated.
###### Synchronization among PRU cores for "Multi Channel with Encoders of Different Make" configuration
If using "Multi Channel with Encoders of Different Make" configuration where load share mode is enabled, one of the cores among enabled cores will be set as the primary core for performing global configurations of PRU-ICSSG's EnDat interface. These global configurations include clock frequency configuration and TX global re-initialization.
There needs to be a synchronization between PRUs before changing any global configuration. For this purpose, each active PRU core sets synchronization bit before any operation needing synchronization and clears the synchronization bit when it is ready. The assigned primary core will wait for all active channel's synchronization bits to be cleared and then perform the global configuration.
##### Send and Receive
\image html endat_send_receive.png "Send And Receive"
If requested command attribute indicates 2.2 command supplement, clock is configured to free run stop low mode, else to free run stop high.
Command is written to the transmit fifo and send routine followed by receive is invoked.
###### Send
\image html endat_send.png "Send"
Transmit and receive frame sizes are configured in PRU EnDat hardware.
With long cables, it may be required to configure receive frame size lesser than receive bits so that extra clocks are not sent to the encoder.
If transmit was going on, it will till it has finished and then transmit GO bit is set, which would start the new transmission.
###### Receive
\image html endat_receive.png "Receive"
Receive bits obtained via command attribute is stored as header (initial 2 bytes) in the receive buffer.
Then wait’s till receive valid flag has been set, once set, 1 byte corresponding 1 bit (because of oversampling of 8) is read and stored in receive buffer and the flags are cleared.
Receive buffer pointer is incremented & receive bit count decremented. This continues till count is zero, once zero, it extracts receive data one more time to take care of SB (receive count excludes SB).
If 2.2 command supplement is not present, transmit re-init is done.
If using "Multi Channel with Encoders of Different Make" configuration where load share mode is enabled, the primary core waits for synchronization bits for active channels to be cleared before performing TX Global Init.
\image html Endat_Load_share_receive.png "Receive In load share mode"
###### EnDat 2.2 Command Supplement Send
\image html endat_2_2_supplement_send.png "EnDAT 2.2 command supplement send"
Clock mode is configured to stop low after transmit. 2.2 command supplement to transmitted is written to fifo preceded by 7 dummy bits & SB.
Transmission is configure to transmit till end of the fifo. Transmission is started after making sure that transmit module is not busy.
###### Receive Downsample
\image html endat_receive_downsampling.png "Downsampling"
This is the most complex portion of the firmware. Received data is exposed through PRU interface in four bytes.
First two words (word = 4 bytes) holds the position data, third holds additional information 2 (if only second additional info is present or both present) or 1 (if only first additional info is present) & the last additional information 1 (if both present).
The order is as mentioned in EnDat 2.2 specification. Splitting the received data on word boundaries when additional info’s are present causes the complexity here.
If command is neither 2.2 nor position request or if no additional info is present, handling is easy – just copy the received data into initial 2 words in the order it is received.
If command is 2.2 position command and depending on the number of additional info’s, markers (used in the downsampling loop) are set to write additional info’s to next word boundaries.
If only one addinfo is present, marker “rx pos bits” stores clocks required to receive position (inclusive of CRC, F1 & F2).
If both addinfo’s are present another marker is set to 2 words (first 2 words holds the position) plus 30 bit to account for addinfo.
If markers are not required, then their values are set so that it never matches the counting receive bits, hence the value “0xff”.
After updating the marker, number of received bits is retrieved from the receive buffer header. SB is skipped for downsampling and the result registers are cleared.
Next, each byte (8 bit, oversample of 8) is read from the receive buffer, 4th bit of each decide the actual received bit. This is continued till the end of receive buffer.
If during the loop, receive bit count matches any of the marker, bit count is updated appropriately. This helps is naturally bringing the received data as per the word format specified by the interface.
In the loop, as the number of bits reaches word boundary, it will start saving received data to next word. At the end of the loop, the last word is copied to the result register.
###### Continuous mode
\image html endat_continuous_mode.png "Continuous Mode"
2.1 position command as well as it’s attribute that been setup by the user is read first. Clock is configured for free run mode. Position command is written fifo and send routine is invoked.
Then receive is done along with on-the-fly downsampling, this is required as time between receipt of successive position data is less than the time that dowsampling routine (mentioned earlier) takes.
Once data is read and dowsampled on-the-fly, command trigger interface is read to see if user wants to stop continuous mode, if so, do transmit re-init, disable receive and wait till the end of re-init.
###### Receive and On-The-Fly Downsample
\image html endat_on_fly_downsampling.png "Endat on the fly Downsampling"
Two registers (a word each) that hold the result are cleared initially. Upon receiving the first receive valid, it discards it and proceeds to wait for the next one as the first one is SB.
Thereafter for every valid flag set, 4th bit in the received byte is checked to find the actual received bit and it stored, word crossing is also taken care.
After all the bits for a position command is received, receive is disabled and is activated only after 2T clock cycles – this is to prevent falsely detecting SB immediately (upon calling this routine back-to-back as mentioned in previous section) after encoder has finished sending data as it can pull data line high for 2T more clock cycles.
#### Recovery Time Measurement
Recovery Time is measured only for Type 2.2 commands.
The factory default settings for the Recovery Time is programmed to 10us <= RT <= 30us. It can only be changed to 1.25us <= RT <=3.75us for type 2.2 mode commands. For clock pulse frequence <= 1MHz, RT must be set to 10us <= RT <= 30us.
The User can set the function parameters in word 3 at "0xB9" memory area for RT range. If bit 0th is unset and 1st bit is set of word3 then RT will belong to large range(10us-30us) and if 0th bit is set and 1st bit is unset of word3 then RT will belong to short range(1.25us to 3.75us).
##### Method for measuring the recovery time for position command
\image html Endat_Recovery_Time_For_Position.png "Endat Recovery time for Endat 2.2 position command "
\image html Endat_RT_FlowChart_for_position.png "Endat Recovery time flow-chart for Endat 2.2 position command"
1. After the CRC bits are received, there is a wait for rising clock edge.
2. Start the measurement of Recovery Time using PRU cycle counter (The cycle counter is set to zero).
3. Wait for falling edge of the data from encoder (RX).
4. Read the PRU cycle counter which gives the value of Recovery Time in PRU Clock Cycle units and store it to DMEM.
##### Method for measuring the recovery time for supplement command
\image html Endat_Recovery_Time_For_Supplement.PNG "Endat Recovery time for Endat 2.2 supplement command "
\image html Endat_RT_FlowChart_for_supplement.png "Endat Recovery time flow-chart for Endat 2.2 supplement command"
1. After TX_GO bit is set which starts the TX, wait for TX FIFO level to reach 0
2. In case of Single Channel or Multi Channel with Encoders of Different Make mode, wait for RX enable. But In case of Multi Channel with Encoders of Same Make mode, wait for TX complete.
3. After the CRC bits are received, there is a wait for rising clock edge.
4. Start the measurement of Recovery Time using PRU cycle counter (The cycle counter is set to zero).
5. Wait for falling edge of the data from encoder (RX).
6. Read the PRU cycle counter which gives the value of Recovery Time in PRU Clock Cycle units and store it to DMEM.
##### NOTE for Multi-channel Single PRU Mode
We can not measure the recovery time as accurately as single channel or multi channel load share, because same PRU has to poll for 3 channels. So we are doing a sequential polling for each channel.
1. Wait for rising edge in clock for all connected channels
2. Start the measurement of Recovery Time using PRU cycle counter (The cycle counter is set to zero).
3. Wait for RX completion on all connected channels. We start checking completion for all connected channels one by one. Whenever completion is detected for a channel, we save the PRU cycle counter value and continue the wait for remaining channels.
### EnDat Hardware interface
The physical data transmission in EnDat is done using RS-485 standard. The data is transmitted as differential signals using the RS485 between the EnDat Receiver and the Encoder.
The Receiver sends the clock to the EnDat encoder, data transmission in either direction (one at a time) occurs in synchronism with the clock. The design uses two differential signals for each of the lines (clock and data).
EnDat Receiver and the encoder is connected using the RS-485 transceiver. Data is transmitted differentially over RS-485. It has the advantages of high noise immunity and long distance transmission capabilities.
#### AM64x/AM243x EVM Pin-Multiplexing
<table>
<tr>
<th>Pin name
<th>Signal name
<th>Function
</tr>
<tr>
<td>PRG0_PRU1_GPO0
<td>pru1_endat0_clk
<td>Channel 0 clock
</tr>
<tr>
<td>PRG0_PRU1_GPO1
<td>pru1_endat0_out
<td>Channel 0 transmit
</tr>
<tr>
<td>PRG0_PRU1_GPO2
<td>pru1_endat0_outen
<td>Channel 0 transmit enable
</tr>
<tr>
<td>PRG0_PRU1_GPI13
<td>pru1_endat0_in
<td>Channel 0 receive
</tr>
<tr>
<td>PRG0_PRU1_GPO3
<td>pru1_endat1_clk
<td>Channel 1 clock
</tr>
<tr>
<td>PRG0_PRU1_GPO4
<td>pru1_endat1_out
<td>Channel 1 transmit
</tr>
<tr>
<td>PRG0_PRU1_GPO5
<td>pru1_endat1_outen
<td>Channel 1 transmit enable
</tr>
<tr>
<td>PRG0_PRU1_GPI14
<td>pru1_endat1_in
<td>Channel 1 receive
</tr>
<tr>
<td>PRG0_PRU1_GPO6
<td>pru1_endat2_clk
<td>Channel 2 clock
</tr>
<tr>
<td>PRG0_PRU1_GPO12
<td>pru1_endat2_out
<td>Channel 2 transmit
</tr>
<tr>
<td>PRG0_PRU1_GPO8
<td>pru1_endat2_outen
<td>Channel 2 transmit enable
</tr>
<tr>
<td>PRG0_PRU1_GPI11
<td>pru1_endat2_in
<td>Channel 2 receive
</tr>
<tr>
<td>GPIO42
<td>endat_en
<td>Onboard RS485 receive enable
</tr>
</table>
\cond SOC_AM243X
##### AM243x-LP Booster Pack Pin-Multiplexing
<table>
<tr>
<th>Pin name
<th>Signal name
<th>Function
</tr>
<tr>
<td>PRG0_PRU1_GPO0
<td>pru1_endat0_clk
<td>Channel 0 clock
</tr>
<tr>
<td>PRG0_PRU1_GPO1
<td>pru1_endat0_out
<td>Channel 0 transmit
</tr>
<tr>
<td>PRG0_PRU1_GPO2
<td>pru1_endat0_outen
<td>Channel 0 transmit enable
</tr>
<tr>
<td>PRG0_PRU1_GPI13
<td>pru1_endat0_in
<td>Channel 0 receive
</tr>
<tr>
<td>GPIO Pin(GPIO1_78)
<td>ENC1_EN
<td>Enbale endat mode in Axis 1 of BP (C16 GPIO pin)
</tr>
</table>
\endcond

50
docs_src/docs/api_guide/components/motor_control/hdsl.md Normal file
View File

@ -0,0 +1,50 @@
# HDSL {#HDSL}
[TOC]
## Introduction
The HDSL firmware running on ICSS-PRU provides a defined well interface to execute the HDSL protocol.
## Features Supported
- External pulse synchronization
- Safe position
- Supports upto 100m cable
- Communication status
- Register interface to be compatible with SICK HDSL FPGA IP Core.
(except registers that have different functionality for read and
write)
- Fast position, speed
- Parameter channel communication
short message write
Short message read
Long message read
Long message write
## Features Not Supported
In general, peripherals or features not mentioned as part of "Features Supported" section are not
supported, including the below
- Pipeline channel
- Safety
## SysConfig Features
@VAR_SYSCFG_USAGE_NOTE
SysConfig can be used to configure things mentioned below:
- Selecting the ICSSG0PRUx instance.(Tested on ICSSG0-PRU1)
- Configuring PINMUX.
## HDSL Design
\subpage HDSL_DESIGN explains the design in detail.
## Example
- \ref EXAMPLE_MOTORCONTROL_HDSL
- \ref EXAMPLE_MOTORCONTROL_HDSL_TRACE
## API
\ref HDSL_API_MODULE

91
docs_src/docs/api_guide/components/motor_control/hdsl_design.md Normal file
View File

@ -0,0 +1,91 @@
# HDSL Protocol Design {#HDSL_DESIGN}
[TOC]
## Introduction
This document presents the firmware implementation details of the Hiperface DSL protocol (SICK STEGMANN, 2010) for the PRU0 in ICSS0 on the AM64x/AM243x EVM.
## System Overview
### Sitara™ AM64x/AM243x Processor
Refer TRM for details
#### PRU-ICSS
Refer PRU-ICSS chapter of AM64x/AM243x Technical Reference Manual
## Software Architecture
The firmware consists of two layers .On the one hand, there is the datalink layer, which is responsible for establishing a communication link to the encoder, monitoring the connection quality and preparing the data.
On the other hand, there is the transport layer that processes the data and determines what information is sent over the parameter channel. Figure "Layer Model" illustrates the relationship between the two layers.
The datalink layer assembles the information from the different channels and puts the data symbol by symbol to the channel buffers. The channel buffers are large enough to carry the data of a whole V-Frame for each channel. .
The transport layer controls the data sent over the parameter channel by setting the symbol to send for the next H-Frame in the parameter channel buffer. This buffer can carry only one symbol.
Both layers have direct access to the register interface that is provided to the higher layers.
\image html hdsl_layer_model.png "Layer Model "
Hiperface DSL specifies a state machine for the Receiver. This implementation features an additional state for loading new firmware to the PRU. Figure "State Machine" depicts the modified state machine.
Furthermore, this implementation exhibits three code sections in the firmware. The first one is for initializing the state machine up to the LOADFW state.
\image html hdsl_state_machine.png "State Machine"
The second section contains datalink functionalities that are needed for the startup phase as well as for the normal workflow. The transport layer functionalities reside in the third section.
### Datalink Layer
The datalink layer is responsible for handling the communication link to the encoder. This includes the sampling, cable delay compensation, DC line balancing, encoding and decoding of data and the monitoring of the connection quality.
#### Sampling
During the reception of the salve answer, the SCU oversamples the data by factor 8. This allows the firmware to compensate signal deficits, such as delay. During the LEARN state the receiver calculates the sample edge based on the first received bit.
Assuming the oversampled data is exactly aligned with one bit, the best position for the sample edge would be either bit 3 or bit 4. An unalignment of the oversampled data with the actual bit results in a shift of the sample edge. The unalignment can be measured by counting the number of ‘1’ in the data, whereas a count of 4 equals the worst alignment and a count of 0 or 8 equals perfect alignment. The number of ’1’ (n) in the oversampled data is determined using a LUT and the following calculation provides the position for the sample edge (E):
E=(4+n)%8
\image html hdsl_sampling.png "Sampling"
#### Delay Measurement and Compensation
During the LEARN state the encoder sends a test pattern to the receiver. This is used to determine the cable delay. While the test pattern is sent, the receiver records all incoming bits and searches for the beginning of the test pattern. The offset, where the test pattern starts, is the cable delay in units of bits.
\image html hdsl_test_pattern.png "Test Pattern"
After the cable delay is measured, the receiver uses this knowledge to compensate the cable delay in subsequent states. This is performed by waiting for the calculated amount of bits as soon as the encoder answer window starts. The next bit on the line is the first bit of the actual encoder answer.
#### Data Encoding and Decoding
The datalink layer has the responsibility to decode and encode the data according to an 8b/10b scheme (Franaszek, 1983). The 8b/10b encoding/decoding is split into two parts, 3b/4b and 5b/6b encoding/decoding. Each of the encoding and decoding processes is performed by using a LUT. Hiperface DSL assumes a transmission with LSB first. Therefore, in the encoding procedure, the index of the LUT is in MSB first order, while the LUT entries are in LSB first order (and vice versa when decoding data). This way, the firmware does not need to handle the reversing of the bit order. When encoding the data, the firmware handles the sending of the correct polarity of the sub-blocks using the measured line disparity.
During receive, the firmware detects byte errors and special characters by checking the received encoded data according to the paper (Franaszek, 1983)
#### Received Signal Strength Indication (RSSI)
The RSSI is calculated by determining the number of samples between two edges during a bit period. The samples that form the longest sequence between two edges represent the stable bit period, which is used to calculate the RSSI. Instead of calculating the stable period in the firmware, a pre-calculated LUT is utilized to speed up the process. First, the edges in a bit period are determined, which is performed by a XOR operation (Figure: hdsl_rssi)]. The searched RSSI value is looked-up in the table by using the result of the XOR operation as the index.
\image html hdsl_rssi.png "Test Pattern"
#### Cyclic Redundancy Check Algorithm
A 16bit CRC verification of the data is used on multiple occasions. It is used for the vertical channel, secondary channel and messages. In order to distribute the computation load equally over all H-Frames, the firmware calculates a running CRC for those data (except for short messages). The algorithm uses a LUT with 256 entries and 2 bytes per entry, whereas each entry is the 16bit CRC for the corresponding LUT index. The basic approach for the calculation of the 16bit CRC is shown as C code in the following:
uint16_t calc_crc(uint8_t *data, uint32_t size) { uint16_t crc = 0; uint32_t i; for(i = 0; i < size; ++i) { crc = ((*data) << 8) ^ crc; crc = lut[crc>>8] ^ (crc << 8); } return (crc ^ 0xff); }
### Transport Layer
The transport layer processes the channel information which was prepared by the datalink layer. This includes the calculation of the fast position as well as the handling of messages.
#### ∆∆Position Estimation
During normal workflow, it can occur that the received ∆∆Position data cannot be used for calculations. This is the case on either a transmission error or an internal encoder error. In order to check for a transmission error, the transport layer checks if the datalink layer detected a byte error and verifies the CRC in the acceleration channel. If no transmission error occurred, the transport layer searches for the occurrence of two K29.7 to recognize an internal encoder error. In case one of the verification of the data fails, the estimation algorithm shown in Figure
\image html hdsl_delta_pos.png "Estimation Algorithm for ∆∆Position"
## Messages
The transport layer handles the messaging. Since it is possible that the higher layers send a long and a short message at the same time, the transport layer has to decide which message to send first. In this implementation short messages are always favored over long messages.
### Short Message
Remote (DSL motor feedback system) registers that indicate interface information are mirrored in the DSL Receiver under register addresses 40h to 7Fh. These remote registers are addressed in the same way as DSL Receiver registers. As the values of remote registers are transmitted via the Parameters Channel and hence via the DSL cables, the delay between polling and answer for "short message" transactions depends on the connection cables of the systems in question. There is no delay, as this information is stored directly in the IP-Core S_PC_DATA.. The Parameters Channel can only transmit one "short message" at a time. Several remote registers can only be polled in sequence, i.e. after the previous answer has been received.
Note: It should be noted that a "short message" can be triggered during a running "long message" transaction.

22
docs_src/docs/api_guide/components/motor_control/motor_control.md Normal file
View File

@ -0,0 +1,22 @@
# Motor Control {#ENCODERS_DOC}
[TOC]
## Introduction
\cond SOC_AM64X || SOC_AM243X
The Motor Control-Encoder Toolkit enables real-time communications with encoders for TI processors/MCUs. Communication is typically handled by the Programmable Real-Time Unit Industrial Communication Subsystem (PRU-ICSS). The PRU-ICSS is a co-processor subsystem containing Programmable Real-Time (PRU) cores which implement the low level firmware. The upper application layer are implemented in software running on Arm cores.
PRU cores are primarily used for communication with encoder, and can also be used for other applications such as motor control and custom interfaces. The PRU-ICSS frees up the main Arm cores in the device for other functions, such as control and data processing.
Applications and PRU-ICSS firmware to communicate with following are provided in the SDK:
- \subpage ENDAT
- \subpage HDSL
- \subpage TAMAGAWA
- \subpage SDFM
\endcond
\cond SOC_AM263X
The Motor Control-Encoder Toolkit enables real-time communications with encoders for TI processors/MCUs.
- \subpage TAMAGAWA_OVER_UART
\endcond

3
docs_src/docs/api_guide/components/motor_control/motor_control_am263x.cfg Normal file
View File

@ -0,0 +1,3 @@
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/components/motor_control/tamagawa_uart.md
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/components/motor_control/motor_control.md
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/source/position_sense/tamagawa_over_soc_uart/include/tamagawa_soc_uart_interface.h

16
docs_src/docs/api_guide/components/motor_control/motor_control_am64x_am243x.cfg Normal file
View File

@ -0,0 +1,16 @@
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/components/motor_control/motor_control.md
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/components/motor_control/endat.md
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/components/motor_control/endat_design.md
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/components/motor_control/hdsl.md
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/components/motor_control/hdsl_design.md
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/components/motor_control/tamagawa.md
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/components/motor_control/tamagawa_design.md
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/components/motor_control/sdfm.md
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/components/motor_control/sdfm_design.md
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/source/position_sense/endat/include/endat_api.h
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/source/position_sense/endat/include/endat_drv.h
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/source/position_sense/hdsl/include/hdsl_drv.h
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/source/position_sense/tamagawa/include/tamagawa_drv.h
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/source/current_sense/sdfm/include/sddf_api.h
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/source/current_sense/sdfm/include/sdfm_drv.h

27
docs_src/docs/api_guide/components/motor_control/sdfm.md Normal file
View File

@ -0,0 +1,27 @@
# SDFM {#SDFM}
[TOC]
## Introduction
ICSS SDFM is a sigma delta interface for phase current measurement in high performance motor and servo drives. During Sigma delta decimation filtering (SDDF) the PRU hardware provides hardware integrators that do the accumulation part of Sinc filtering, while the ICSS SDFM firmware does differentiation part.
## Features Supported
- 3 SDFM channels on single PRU core
- Overcurrent (OC) for comparator: free running SINC3 filter with OSR 32-256
- Normal current (NC) for data read: free running SINC3 filter with OSR 32-256, always multiple of OC OSR (NC OSR = K*OC OSR :: K ∈ Z)
- Event generation(ARM interrupt for data read from DMEM, GPIO toggle for high and low thresholds)
- High and Low threshold comparator
## Features Not Supported
- Zero cross comparator
- Below 32 OSR
## ICSS SDFM Design
\subpage SDFM_DESIGN explains the design in detail.
## Example
\ref EXAMPLE_MOTORCONTROL_SDFM
## API
\ref SDFM_API_MODULE

156
docs_src/docs/api_guide/components/motor_control/sdfm_design.md Normal file
View File

@ -0,0 +1,156 @@
# SDFM Interface Design {#SDFM_DESIGN}
[TOC]
## Introduction
This design implements Sigma delta interface on TI Sitara™ AM64x/AM243x.
ICSS SDFM is a Sigma delta filter for phase current measurement.
Only two lines are required for each channel, differential pair each for SDFM clock & SDFM data.
Clock is provided by external device or internal device and data comes from sigma delta modulator in form of digital bit stream.
## System Overview
## Implementation
The Sigma delta filter is implemented on TI Sitara™ Devices.
Design is split into three parts – Sigma delta hardware support in PRU, firmware running in PRU and driver running in ARM.
Application is supposed to use the ICSS SDFM driver APIs to leverage SDFM functionality.
SDK example uses the SDFM hardware capability in Slice 1 of PRU-ICSSG0.
### Specifications
<table>
<tr>
<th>Parameter
<th>Value
<th>Details
</tr>
<tr>
<td>Normal current OSR
<td>32
<td>Tested with 32, 64, 128 & 256
</tr>
<tr>
<td>Over current OSR
<td>64
<td>Tested with 32, 64, 128 & 256
</tr>
<tr>
<td>Sigma Delta Modulator Clock
<td>20 MHz
<td>
</tr>
<tr>
<td>Simulated EPWM frequency
<td>8 KHz
<td>Tested up to 20KHz
</tr>
<tr>
<td>IEP frequency
<td>300MHz
<td>
</tr>
</table>
### ICSS SDFM PRU hardware
Refer TRM for details
### ICSS SDFM Firmware Implementation
Following section describes the firmware implementation of Sigma delta decimation filter on PRU-ICSS.
#### Firmware Architecture
\image html SDFM_FIRMWARE_FLOWCHART.png "Overall Block Diagram"
Firmware first clear PRU registers & Task manager.
Then it waits for the R5 to set SDFM enable bit. After the enable set then it acknowledge to R5.
After above these initial steps firmware does initialization of PRU-ICSSG's SDFM hardware interface, task manager & IEP0 then it comes in infinite waiting loop.
When the COMP4 event hits the task manager assign OC loop to PC and Firmware starts execution of OC loop
In OC loop firmware read sample data from accumulator and it checks for NC sample if the current OC sample belongs to NC sample then it does sampling for NC.
During the NC sampling if current NC sample is closest to sample read time then it trigger R5 interrupt.
at the end of OC loop firmware exit task manager and again firmware execution flow comes into infinite waiting loop.
##### Threshold Comparator
This section describe threshold comparator implementation. When the sample value crosses the high or low thresholds, the corresponding GPIO pin goes high.
\image html Threshold_comparator_flow.png "Threshold Comparator"
##### Sample data read jitter
Firmware trigger R5 interrupt for the NC sample closest to the sample read time in every PWM cycle.
NOTE: There is some jitter in sample read timing, Sample data can be sampled before or after the maximum half nc sample time.
#### AM64x/AM243x EVM Pin-Multiplexing
<table>
<tr>
<th>Pin name
<th>Signal name
<th>Function
</tr>
<tr>
<td>GPIO_HIGH_TH_CH0
<td>MCU_SPI0_D1/B6
<td>Ch0 High threshold output
</tr>
<tr>
<td>GPIO_LOW_TH_CH0
<td>MCU_SPI1_D0/C7
<td>Ch0 low threshold output
</tr>
<tr>
<td>GPIO_HIGH_TH_CH1
<td>MCU_SPI1_CS0/A7
<td>Ch1 High threshold output
</tr>
<tr>
<td>GPIO_LOW_TH_CH1
<td>MCU_SPI1_CLK/D7
<td>Ch1 low threshold output
</tr>
<tr>
<td>GPIO_HIGH_TH_CH2
<td>MCU_SPI1_D1/C8
<td>Ch2 High threshold output
</tr>
<tr>
<td>GPIO_LOW_TH_CH2
<td>MCU_SPI0_CLK/E6
<td>Ch2 Low threshold output
</tr>
<tr>
<td>SD0_D
<td>PIN_PRG0_PRU0_GPO1
<td>Channel0 data input
</tr>
<tr>
<td>SD1_D
<td>PIN_PRG0_PRU0_GPO3
<td>Channel1 data input
</tr>
<tr>
<td>SD2_D
<td>PIN_PRG0_PRU0_GPO5
<td>Channel2 data input
</tr>
<tr>
<td>PRG0_ECAP0_IN_APWM_OUT
<td>PIN_PRG0_PRU1_GPO15
<td>
</tr>
<tr>
<td>GPIO_MTR_1_PWM_EN
<td>GPMC0_AD15/Y20
<td>
</tr>
<tr>
<td>SD8_CLK
<td>PIN_PRG0_PRU0_GPO16
<td>SDFM clock input pin
</tr>
</table>

41
docs_src/docs/api_guide/components/motor_control/tamagawa.md Normal file
View File

@ -0,0 +1,41 @@
# Tamagawa {#TAMAGAWA}
[TOC]
## Introduction
The Tamagawa receiver firmware running on PRU-ICSS provides a defined well interface to execute the Tamagawa protocol. The Tamagawa diagnostic application interacts with the Tamagawa receiver firmware interface.
\note
Starting with MCU+ SDK version 08.05.00, the Tamagawa firmware and examples are based on EnDAT hardware interface from PRU-ICSSG.
## Features Supported
- Supports full-absolute SmartAbs & SmartInc encoders compatible with Smartceiver AU5561N1
- Channel selection
- Baud rate selection
- 2.5 Mbps and 5 Mbps encoder support
- Supports all Data Readout, Reset and EEPROM commands
## Features Not Supported
In general, peripherals or features not mentioned as part of "Features Supported" section are not supported, including the below
- Other baud rates.
## SysConfig Features
@VAR_SYSCFG_USAGE_NOTE
SysConfig can be used to configure things mentioned below:
- Selecting the ICSSG instance
- Selecting the PRUx slice (Tested on ICSSG0-PRU1)
- Configuring PINMUX, GPIO and ICSS clock to 200MHz
- Channel selection
- Baud rate selection
## Tamagawa Design
\subpage TAMAGAWA_DESIGN explains the design in detail.
## Example
- \ref EXAMPLE_MOTORCONTROL_TAMAGAWA

68
docs_src/docs/api_guide/components/motor_control/tamagawa_design.md Normal file
View File

@ -0,0 +1,68 @@
# Tamagawa Protocol Design {#TAMAGAWA_DESIGN}
[TOC]
## Introduction
This document presents the firmware implementation details of the Tamagawa receiver protocol.
## Tamagawa encoder receiver
It is an encoder technology used for obtaining high-precision position information in machine tools, robotics, and so forth. Tamagawa rotary encoders consist broadly of two types: incremental or absolute. Incremental encoders provide a train of pulses, while the absolute-type provides digital values. The absolute encoder group contains the single-turn types that provide outputs which can be open collector or emitter follower. The absolute encoder types include the pure digital encoder types, which provide a digital word output through a line driver such as an RS485, or a semi-absolute encoder, which provides both digital word and pulse train outputs. Of the RS485 line-driver output absolute encoders that provide only digital output, another classification is the full absolute encoder. A full absolute encoder provides multi-turn digital data, which is known as SmartAbs, and is compatible with the Tamagawa Smartceiver AU5561N1. Another type of encoders, known as SmartInc, provide single-turn information in digital format with an RS485 line driver output. The AM64x/AM243x Tamagawa receiver implementation is equivalent to the Smartceiver AU5561N1, which can communicate with Tamagawa SmartAbs as well as SmartInc encoders.
The AM64x/AM243x Tamagawa receiver communicates with Tamagawa SmartAbs and SmartInc encoders and provides drive control with digital information to and from the encoder. Tamagawa communication is broadly classified into three types: data readout, reset, and EEPROM transactions. Four data readout transactions occur: absolute data in one revolution, multi-turn data, encoder ID, and a combination of all of these along with the encoder error status. The reset transaction always returns the absolute data in one revolution while performing different types of resets. Three types of reset are available: reset of absolute data in one revolution, reset of multi-turn data, and error reset. The EEPROM transaction allows the system to read and write to the EEPROM in the encoder. Each transaction has a unique data ID and consists of different fields, namely control, status, data, cyclic redundancy check (CRC), EEPROM address, and EEPROM data depending on the type of transaction, that is, data ID.
Each field is 10-bits long, beginning with a start bit and ending with a delimiter. The 8 bits between these start bits and delimiters depends on the field type. The control field contains the data ID information. Data, status, and CRC fields similarly contain data, status, and CRC in those 8 bits. The receiver initially sends the control field to start the communication. This action indicates the type of transaction to the encoder and the encoder returns this information based on the data ID, as the previous paragraph explains. The encoder always returns the control field back to the receiver. In the case of data readout and reset transactions, the encoder returns the control field followed by the status, data, and ending with the CRC field at the end. In the case of an EEPROM read or write, the receiver, in addition to the control field, sends the EEPROM address field (and EEPROM data field for write) followed by the CRC. The encoder returns the control field, followed by the EEPROM address, EEPROM data, and CRC fields. The physical layer communication is RS422/RS485 based.
## System Overview
### Sitara™ AM64x/AM243x Processor
Refer TRM for details
#### PRU-ICSS
Refer PRU-ICSS chapter of AM64x/AM243x Technical Reference Manual
## Software Description
At start-up, the application running on the ARM Cortex-R5 initializes the module clocks and configures the pinmux. The PRU is initialized and the PRU firmware is loaded on PRU slice of choice for a chosen ICSS instance (tested on PRU1 on ICSSG0). After the PRU1 starts executing, the Tamagawa interface is operational and the application can use it to communicate with an encoder. Use the Tamagawa diagnostic example to learn more about initialization and communication with the Tamagawa interface. This Tamagawa diagnostic example (available at the path "examples/motor_control/tamagawa_diagnostic" in the directory where MCU PLUS SDK is installed), also provides an easy way to validate the Tamagawa transactions. The diagnostic example provides menu options on the host PC in a serial terminal application, where the user can select the data ID code to be sent. Based on the data ID code, the application updates the Tamagwa interface with the data ID code and trigger transaction. The application then waits until it receives an indication of complete transaction by the firmware through the interface before displaying the result.
### PRU Firmware Design
The firmware first initializes the PRU hardware, after which it waits until a command has been triggered through the interface. Upon triggering, the transmit data is set up based on the data ID code and the data is transmitted. The data ID code then waits until receiving all the data that depends on the data ID. The parsing over the received data then commences, which is again based on the data ID, and the interface is updated with the result. The CRC verification occurs next and the interface indicates command completion. The firmware then waits for the next command trigger from the interface.
\image html Tamagawa_flowchart.JPG "Overview Flow Chart"
### Initialization
PRU is set to EnDat mode first. The entire EnDat configuration MMR’s are cleared(CFG registers). Tx global reinit bit in R31 is set to put all channels in default mode. The clock source is selected (ICSSG clock is selected with 200MHZ frequency). In Tx mode, the output data is read from the Tx FIFO at this 1x clock rate. In Rx mode, the input data is sampled at the Oversampling (OS) clock rate. Hence, Tx clock(1x clock) and Rx clock(Oversampling (OS) clock) are setup by selecting oversampling factor(x8). At the end of the initialization status is updated and wait until trigger from user occurs for tamagawa commands.
\image html Tamagawa_initialization_flow_chart.JPG "Initialization Flow Chart"
### Setup Transmit Data
The transmit and receive sizes are determined based on the data ID in the interface.
\image html Tamagawa_setup_tx_data.png "Setup Transmit Data Flow Chart"
### Transmit and Receive
In the current implementation, the Transmit data is loaded into the Tx FIFO byte wise. For data readout and reset commands, the requirement is to send 1 frame of 10 bits. So, 2 bytes of data is first loaded into the Tx FIFO and Tx frame size is set to 10 bits to send right data to Encoder. Similarly, for EEPROM Read command, the requirement is to send 3 frames of 10 bits each, so 30 bits in total. For this, 4 byes of data is first loaded into the Tx FIFO and then Tx frame size is set to 30 bits to send right data to Encoder. This is done by using the Tx - Single Shot mode.
\image html Tamagawa_tx_flow_chart.png "Transmit Flow Chart for data readout, reset and EEPROM Read commands"
In case of EEPROM Write command, the requirement is to send 4 frames of 10 bits each - 40 bits in total. For this, 4 bytes of data is first loaded into the Tx FIFO and then transmission is started in Tx - Continuous FIFO loading mode. FIFO byte level is constantly monitored and the FIFO is reloaded with the last byte when the FIFO level reaches 3 bytes.
\image html Tamagawa_eeprom_write_flow_chart.png "Transmit Flow Chart for EEPROM Write command"
Once the Transmission is complete, the encoder starts sending the data and the firmware copies the receive FIFO contents onto the receive buffer, individually, until all the data has been received.
\image html Tamagawa_rx_flow_chart.png "Receive Flow Chart"
### Receive Data Parse
Depending on the data ID used for initiating the transfer, the firmware parses the received data and copies it onto relevant fields in the interface, accordingly.
\image html Tamagawa_parse_data.png "Receive Data Parse Flow Chart"
### Verify CRC
The CRC is the last byte of the received data. The firmware then calculates the CRC of the received data excluding the last byte, compares it with the received CRC value, and updates the CRC status in the interface.
\image html Tamagawa_verify_crc.png "Verify CRC Flow Chart"

33
docs_src/docs/api_guide/components/motor_control/tamagawa_uart.md Normal file
View File

@ -0,0 +1,33 @@
# TAMAGAWA OVER UART {#TAMAGAWA_OVER_UART}
[TOC]
## Introduction
The Tamagawa over UART module provides a support for SoC UART instance to execute the Tamagawa protocol.
## Features Supported
- Single channel
- Baud rate selection
- 2.5 Mbps and 5 Mbps encoder support
- Supports all Data Readout, Reset and EEPROM commands
## Features Not Supported
- Other baud rates
- Long cable length
## SysConfig Features
@VAR_SYSCFG_USAGE_NOTE
SysConfig can be used to configure things mentioned below:
- Baud rate selection(2461538 bps for 2.5 Mbps encoder, 4923076 bps for 5Mbps encoder)
- Communication mode selection (Tested on polling mode)
- Configuring GPIO62 signal with J2 pin (RTSn pin for software based flow control)
- UART instance selection
## Example
- \ref EXAMPLE_MOTORCONTROL_TAMAGAWA_OVER_UART

8
docs_src/docs/api_guide/device/am64x/examples.cfg Normal file
View File

@ -0,0 +1,8 @@
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/examples/examples.md
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/examples/motorcontrol/motorcontrol.md
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/examples/motorcontrol/hdsl_example.md
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/examples/motorcontrol/hdsl_example_trace.md
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/examples/motorcontrol/endat_example.md
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/examples/motorcontrol/tamagawa_example.md
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/examples/motorcontrol/benchmarkdemo_example_am64x.md
INPUT+= $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/examples/motorcontrol/sdfm_example.md

24
docs_src/docs/api_guide/device/am64x/includes.cfg Normal file
View File

@ -0,0 +1,24 @@
# The PROJECT_NAME tag is a single word (or a sequence of words surrounded by
# double-quotes, unless you are using Doxywizard) that should identify the
# project for which the documentation is generated. This name is used in the
# title of most generated pages and in a few other places.
# The default value is: My Project.
PROJECT_NAME = "AM64x MOTOR CONTROL SDK"
INPUT += $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/main_page/main_page.md
@INCLUDE = $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/device/am64x/examples.cfg
@INCLUDE = $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/components/motor_control/motor_control_am64x_am243x.cfg
# Used to selectively pick DEVICE specific sections within .md files
ENABLED_SECTIONS = SOC_AM64X
# SOC specific aliases
ALIASES+=VAR_SOC_NAME="AM64X"
ALIASES+=VAR_SOC_NAME_LOWER="am64x"
ALIASES+=VAR_BOARD_NAME="AM64X-EVM"
ALIASES+=VAR_BOARD_NAME_LOWER="am64x-evm"
ALIASES+=VAR_SK_BOARD_NAME="AM64X-SK"
ALIASES+=VAR_SK_BOARD_NAME_LOWER="am64x-sk"
ALIASES+=VAR_SOC_MANIFEST="motor_control_sdk_am64x_manifest.html"

0
docs_src/docs/api_guide/doxy_warnings_am243x.txt Normal file
View File

0
docs_src/docs/api_guide/doxy_warnings_am263x.txt Normal file
View File

35
docs_src/docs/api_guide/doxy_warnings_am64x.txt Normal file
View File

@ -0,0 +1,35 @@
C:/ti/motor_control_sdk/docs_src/docs/api_guide/examples/motorcontrol/hdsl_example.md:76: warning: unable to resolve reference to `EVM_SETUP_PAGE' for \ref command
C:/ti/motor_control_sdk/docs_src/docs/api_guide/examples/motorcontrol/hdsl_example.md:188: warning: unable to resolve reference to `CCS_PROJECTS_PAGE' for \ref command
C:/ti/motor_control_sdk/docs_src/docs/api_guide/examples/motorcontrol/hdsl_example.md:190: warning: unable to resolve reference to `MAKEFILE_BUILD_PAGE' for \ref command
C:/ti/motor_control_sdk/docs_src/docs/api_guide/examples/motorcontrol/hdsl_example.md:191: warning: unable to resolve reference to `CCS_LAUNCH_PAGE' for \ref command
C:/ti/motor_control_sdk/docs_src/docs/api_guide/examples/motorcontrol/hdsl_example_trace.md:60: warning: unable to resolve reference to `EVM_SETUP_PAGE' for \ref command
C:/ti/motor_control_sdk/docs_src/docs/api_guide/examples/motorcontrol/hdsl_example_trace.md:89: warning: unable to resolve reference to `CCS_PROJECTS_PAGE' for \ref command
C:/ti/motor_control_sdk/docs_src/docs/api_guide/examples/motorcontrol/hdsl_example_trace.md:91: warning: unable to resolve reference to `MAKEFILE_BUILD_PAGE' for \ref command
C:/ti/motor_control_sdk/docs_src/docs/api_guide/examples/motorcontrol/hdsl_example_trace.md:92: warning: unable to resolve reference to `CCS_LAUNCH_PAGE' for \ref command
C:/ti/motor_control_sdk/docs_src/docs/api_guide/examples/motorcontrol/endat_example.md:113: warning: unable to resolve reference to `EVM_SETUP_PAGE' for \ref command
C:/ti/motor_control_sdk/docs_src/docs/api_guide/examples/motorcontrol/endat_example.md:210: warning: unable to resolve reference to `CCS_PROJECTS_PAGE' for \ref command
C:/ti/motor_control_sdk/docs_src/docs/api_guide/examples/motorcontrol/endat_example.md:212: warning: unable to resolve reference to `MAKEFILE_BUILD_PAGE' for \ref command
C:/ti/motor_control_sdk/docs_src/docs/api_guide/examples/motorcontrol/endat_example.md:213: warning: unable to resolve reference to `CCS_LAUNCH_PAGE' for \ref command
C:/ti/motor_control_sdk/docs_src/docs/api_guide/examples/motorcontrol/tamagawa_example.md:87: warning: unable to resolve reference to `EVM_SETUP_PAGE' for \ref command
C:/ti/motor_control_sdk/docs_src/docs/api_guide/examples/motorcontrol/tamagawa_example.md:196: warning: unable to resolve reference to `CCS_PROJECTS_PAGE' for \ref command
C:/ti/motor_control_sdk/docs_src/docs/api_guide/examples/motorcontrol/tamagawa_example.md:198: warning: unable to resolve reference to `MAKEFILE_BUILD_PAGE' for \ref command
C:/ti/motor_control_sdk/docs_src/docs/api_guide/examples/motorcontrol/tamagawa_example.md:199: warning: unable to resolve reference to `CCS_LAUNCH_PAGE' for \ref command
C:/ti/motor_control_sdk/docs_src/docs/api_guide/examples/motorcontrol/benchmarkdemo_example_am64x.md:68: warning: unable to resolve reference to `EVM_SETUP_PAGE' for \ref command
C:/ti/motor_control_sdk/docs_src/docs/api_guide/examples/motorcontrol/benchmarkdemo_example_am64x.md:84: warning: unable to resolve reference to `CCS_PROJECTS_PAGE' for \ref command
C:/ti/motor_control_sdk/docs_src/docs/api_guide/examples/motorcontrol/benchmarkdemo_example_am64x.md:86: warning: unable to resolve reference to `MAKEFILE_BUILD_PAGE' for \ref command
C:/ti/motor_control_sdk/docs_src/docs/api_guide/examples/motorcontrol/benchmarkdemo_example_am64x.md:119: warning: image file boot_pins_sd_mode_oob.png is not found in IMAGE_PATH: assuming external image.
C:/ti/motor_control_sdk/docs_src/docs/api_guide/examples/motorcontrol/benchmarkdemo_example_am64x.md:125: warning: unable to resolve reference to `CCS_UART_TERMINAL' for \ref command
C:/ti/motor_control_sdk/docs_src/docs/api_guide/examples/motorcontrol/sdfm_example.md:82: warning: unable to resolve reference to `EVM_SETUP_PAGE' for \ref command
C:/ti/motor_control_sdk/docs_src/docs/api_guide/examples/motorcontrol/sdfm_example.md:94: warning: unable to resolve reference to `CCS_PROJECTS_PAGE' for \ref command
C:/ti/motor_control_sdk/docs_src/docs/api_guide/examples/motorcontrol/sdfm_example.md:96: warning: unable to resolve reference to `MAKEFILE_BUILD_PAGE' for \ref command
C:/ti/motor_control_sdk/docs_src/docs/api_guide/examples/motorcontrol/sdfm_example.md:97: warning: unable to resolve reference to `CCS_LAUNCH_PAGE' for \ref command
C:/ti/motor_control_sdk/source/position_sense/hdsl/include/hdsl_drv.h:256: warning: explicit link request to 'PRUICSS_Handle' could not be resolved
C:/ti/motor_control_sdk/source/position_sense/hdsl/include/hdsl_drv.h:391: warning: explicit link request to 'SystemP_SUCCESS' could not be resolved
C:/ti/motor_control_sdk/source/position_sense/hdsl/include/hdsl_drv.h:391: warning: explicit link request to 'SystemP_TIMEOUT' could not be resolved
C:/ti/motor_control_sdk/source/position_sense/hdsl/include/hdsl_drv.h:404: warning: explicit link request to 'SystemP_SUCCESS' could not be resolved
C:/ti/motor_control_sdk/source/position_sense/hdsl/include/hdsl_drv.h:404: warning: explicit link request to 'SystemP_TIMEOUT' could not be resolved
C:/ti/motor_control_sdk/source/position_sense/hdsl/include/hdsl_drv.h:226: warning: explicit link request to 'PRUICSS_PRU0' could not be resolved
C:/ti/motor_control_sdk/docs_src/docs/api_guide/main_page/main_page.md:13: warning: unable to resolve reference to `GETTING_STARTED' for \ref command
C:/ti/motor_control_sdk/docs_src/docs/api_guide/main_page/main_page.md:16: warning: found subsection command outside of section context!
C:/ti/motor_control_sdk/docs_src/docs/api_guide/main_page/main_page.md:17: warning: unable to resolve reference to `MIGRATION_GUIDES' for \ref command
C:/ti/motor_control_sdk/docs_src/docs/api_guide/main_page/main_page.md:24: warning: image file am64x/block_diagram.png is not found in IMAGE_PATH: assuming external image.

2301
docs_src/docs/api_guide/doxygen.cfg Normal file
View File

File diff suppressed because it is too large Load Diff

8
docs_src/docs/api_guide/examples/examples.md Normal file
View File

@ -0,0 +1,8 @@
# Examples and Demos {#EXAMPLES}
This page lists all the examples and demos supported in this SDK.
\cond SOC_AM64X || SOC_AM243X
-# \subpage EXAMPLES_MOTORCONTROL
\endcond
\cond SOC_AM263X
-# \subpage EXAMPLES_MOTORCONTROL
\endcond

148
docs_src/docs/api_guide/examples/motorcontrol/benchmarkdemo_example_am243x.md Normal file
View File

@ -0,0 +1,148 @@
# Benchmark Demo with GUI Composer {#EXAMPLE_MOTORCONTROL_BENCHMARKDEMO}
[TOC]
## Introduction
The Benchmark Demo showcases the capabilities of the 4 R5F cores on AM243x. Each R5F core runs a particular benchmark test and displays the results on a Cloud-based GUI.
The @VAR_BOARD_NAME version of the demo also has power monitoring functionality and displays voltage, current, and total power consumption.
The mapping of R5F core to the benchmark that is run is shown below
<table>
<tr>
<th>R5 Core
<th>Benchmark
<th>Default Option
<th>Description
</tr>
<tr>
<td>R5F Core 0 (rf5ss0-0)</td>
<td>Stream memory benchmark</td>
<td>1 hz execution loop</td>
<td>Memory bandwidth benchmark for R5. For more details on the STREAM benchmark, see http://www.cs.virginia.edu/stream/ref.html
</td>
</tr>
<tr>
<td>R5F Core 1 (rf5ss0-1)</td>
<td>CFFT benchmark</td>
<td>1Khz execution loop, 128 point CFFT</td>
<td>CMSIS CFFT benchmark for R5F</td>
</tr>
<tr>
<td>R5F Core 2 (rf5ss1-0)</td>
<td>FIR filtering benchmark</td>
<td>1 Khz execution loop, 320 point, 29-tap</td>
<td>CMSIS FIR filtering benchmark for R5F </td>
</tr>
<tr>
<td>R5F Core 3 (rf5ss1-1)</td>
<td>Field Oriented Control (FOC) benchmark </td>
<td>32 Khz execution loop</td>
<td>CMSIS FOC benchmark for R5F</td>
</tr>
</table>
# Steps to Run the Example {#STEPS}
## EVM Setup
- To run the demo from GUI composer, firstly you need to make sure the EVM is setup as mentioned here, \ref EVM_SETUP_PAGE
- Specifically,
- Make sure you have connected the power, USB UART and USB JTAG cables as mentioned here, \ref EVM_CABLES
- Make sure you have identified the UART port that is used for the print logs as mentioned here, \ref CCS_UART_TERMINAL
- Check if the SOC initialization binary is already flashed. If flashed, you will see something like below in the UART terminal,
\code
Starting NULL Bootloader ...
DMSC Firmware Version 21.1.1--v2021.01a (Terrific Lla
DMSC Firmware revision 0x15
DMSC ABI revision 3.1
INFO: Bootloader_runCpu:147: CPU r5f1-0 is initialized to 800000000 Hz !!!
INFO: Bootloader_runCpu:147: CPU r5f1-1 is initialized to 800000000 Hz !!!
INFO: Bootloader_runCpu:147: CPU m4f0-0 is initialized to 400000000 Hz !!!
INFO: Bootloader_loadSelfCpu:199: CPU r5f0-0 is initialized to 800000000 Hz !!!
INFO: Bootloader_loadSelfCpu:199: CPU r5f0-1 is initialized to 800000000 Hz !!!
INFO: Bootloader_runSelfCpu:209: All done, reseting self ...
\endcode
- If you see this in the UART terminal, you are all set to launch the demo, else you will
need to flash the SOC initialization binary as mentioned here, \ref EVM_FLASH_SOC_INIT
- Now you can launch the demo via GUI composer as mentioned next
## Launch the demo
- Close all open UART terminals and JTAG connections. GUI composer via the browser will need access
to the UART port and JTAG port.
- Power on the EVM with the USB UART and USB JTAG cables connected.
- In a web browser, Firefox, Chrome or Edge, click on the below link
- For @VAR_LP_BOARD_NAME, https://dev.ti.com/gallery/view/SitaraMCU/AM243x_LaunchPad_OOB_Experience
- For @VAR_BOARD_NAME, https://dev.ti.com/gallery/view/SitaraMCU/AM243x_EVM_OOB_Experience
- Click on benchmark demo
\imageStyle{am243x_benchmark_demo_00.png,width:20%}
\image html am243x_benchmark_demo_00.png
- Select the UART port noted during EVM setup and set the UART baud rate as shown below,
\imageStyle{am243x_benchmark_demo_01.png,width:20%}
\image html am243x_benchmark_demo_01.png
\imageStyle{am243x_benchmark_demo_02.png,width:30%}
\image html am243x_benchmark_demo_02.png
- Click on `LAUNCH` to launch the demo
\imageStyle{am243x_benchmark_demo_03.png,width:50%}
\image html am243x_benchmark_demo_03.png
- You will see some setup happening in the bottom of the browser window, let this continue. First time this make take a minute or so to complete.
\imageStyle{am243x_benchmark_demo_04.png,width:90%}
\image html am243x_benchmark_demo_04.png
- After all the setup and download is done, you will see the benchmark demo results updating in the GUI as shown below
\imageStyle{am243x_benchmark_demo_05.png,width:90%}
\image html am243x_benchmark_demo_05.png
- You can interact with the GUI options to change the settings and see the updated results.
# Supported Combinations
\cond SOC_AM64X || SOC_AM243X
Parameter | Value
---------------|-----------
CPU + OS | r5fss0-0 nortos
^ | r5fss0-1 nortos
^ | r5fss1-0 nortos
^ | r5fss1-1 nortos
Toolchain | ti-arm-clang
Boards | @VAR_BOARD_NAME_LOWER, @VAR_LP_BOARD_NAME_LOWER
Example folder | examples/motor_control/benchmark_demo/
\endcond
# Build and run the demo without GUI composer
\note The GUI composer loads a pre-built binary from a server to run the demo. This prebuilt binary cannot be changed by end users.
\note This section is a reference for users to understand and build the underlying source code of the demo. However
they will not be able to see the results of the updated binary on the GUI composer.
\note This is a `system` or multi-core project, so refer to system project build instructions for CCS project or makefiles when building the example.
- **When using CCS projects to build**, import the system CCS project
and build it using the CCS project menu (see \ref CCS_PROJECTS_PAGE). This will build all the dependant CPU projects as well
- **When using makefiles to build**, build the system makefile using
make command (see \ref MAKEFILE_BUILD_PAGE). This will build all the dependant CPU makefiles as well.
- Launch a CCS debug session and run the executables, see \ref CCS_LAUNCH_PAGE
- This is a multi-core example. Hence the executables should be loaded and run for all the above mentioned cores
- When you run the demo it will output some text on UART console continuously. When running
with GUI composer this text is used as input to render the contents of the GUI.

177
docs_src/docs/api_guide/examples/motorcontrol/benchmarkdemo_example_am64x.md Normal file
View File

@ -0,0 +1,177 @@
# Benchmark Demo with Linux on A53 {#EXAMPLE_MOTORCONTROL_BENCHMARKDEMO}
[TOC]
## Introduction
The benchmark demo showcases the capabilities of the four R5F cores as well as
the A53 core. This demo is run by default when **Processor SDK Linux** is flashed to SD card.
Different R5F benchmarks will run on each of the four R5F cores. There are four options available for each
benchmark. Users can switch the options using the drop-down menu in the GUI to view
performance of R5F with each option.
The mapping of R5F core to the benchmark that is run is shown below
<table>
<tr>
<th>R5 Core
<th>Benchmark
<th>Default Option
<th>Description
</tr>
<tr>
<td>R5F Core 0 (rf5ss0-0)</td>
<td>ADC and PWM benchmark</td>
<td>8 Khz execution loop</td>
<td>ADC/PWM benchmark for R5F, here we read 5 ADC samples and do 1 PWM write. **NOTE: This is not enabled in current release**.
</td>
</tr>
<tr>
<td>R5F Core 1 (rf5ss0-1)</td>
<td>CFFT benchmark</td>
<td>1Khz execution loop, 128 point CFFT</td>
<td>CMSIS CFFT benchmark for R5F</td>
</tr>
<tr>
<td>R5F Core 2 (rf5ss1-0)</td>
<td>FIR filtering benchmark</td>
<td>1 Khz execution loop, 320 point, 29-tap</td>
<td>CMSIS FIR filtering benchmark for R5F </td>
</tr>
<tr>
<td>R5F Core 3 (rf5ss1-1)</td>
<td>Field Oriented Control (FOC) benchmark </td>
<td>16 Khz execution loop</td>
<td>CMSIS FOC benchmark for R5F</td>
</tr>
</table>
# Supported Combinations
\cond SOC_AM64X || SOC_AM243X
Parameter | Value
---------------|-----------
CPU + OS | r5fss0-0 nortos
^ | r5fss0-1 nortos
^ | r5fss1-0 nortos
^ | r5fss1-1 nortos
Toolchain | ti-arm-clang
Board | @VAR_BOARD_NAME_LOWER
Example folder | examples/motor_control/benchmark_demo/
\endcond
# Steps to Run the Example {#STEPS}
## Hardware Prerequisites
Other than the basic EVM setup mentioned in \ref EVM_SETUP_PAGE, below additional HW is required to run this demo
- PC with a web browser and wired ethernet connectivity (Windows or Linux)
- Ethernet cables
- Ethernet switch or ethernet router with DHCP service
- SD card (minimum 2GB)
## Build the R5F side projects
\note The default **Processor SDK Linux** has prebuilt applications already, so this step can be skipped unless you have modified the
demo application on R5F.
\note This is a `system` or multi-core project, so refer to system project build instructions for CCS project or makefiles when building the example.
- **When using CCS projects to build**, import the system CCS project
and build it using the CCS project menu (see \ref CCS_PROJECTS_PAGE). This will build all the dependant CPU projects as well
- **When using makefiles to build**, build the system makefile using
make command (see \ref MAKEFILE_BUILD_PAGE). This will build all the dependant CPU makefiles as well.
- After the build is complete the copy the below files to the SD card containing Linux filesystem in folder `/lib/firmware`.
\code
{system project output folder}/am64-main-r5f0_0-fw
{system project output folder}/am64-main-r5f0_1-fw
{system project output folder}/am64-main-r5f1_0-fw
{system project output folder}/am64-main-r5f1_1-fw
When using makefiles to build, "system project output folder", is
${SDK_INSTALL_PATH}/examples/motor_control/benchmark_demo/{board}/system_nortos
When using CCS projects to build, "system project output folder", is
${CCS_WORKSPACE_PATH}/benchmark_demo_{board}_system_nortos/{Debug or Release}
\endcode
- **NOTE**, the copy step can only be done using a Linux machine since the Linux filesystem on the SD card cannot be seen on a Windows machine.
## Run the demo
- To run this demo, Linux needs to run on the Cortex A-core.
- This typically involves flashing a prebuilt Linux filesystem (`.wic` file) to the SD card
- Refer to **Processor SDK Linux** user guide to setup Linux on Cortex-A core.
- Keep the EVM in **POWER-OFF** state.
- Insert the SD card with Linux filesystem onto the EVM
- Set the EVM boot mode to "SD boot mode"
\imageStyle{boot_pins_sd_mode_oob.png,width:50%}
\image html boot_pins_sd_mode_oob.png "SD BOOT MODE"
- Connect an ethernet cable from your ethernet switch or router to the EVM
- Connect your PC to the same ethernet switch or router
- Identify and setup a UART terminal console as mentioned in \ref CCS_UART_TERMINAL
- **POWER-ON** the EVM.
- After the Linux boot completes, login as "root", then type in "ifconfig" in Linux prompt to find out the IP address for the EVM
\imageStyle{OOB_Linux_ifconfig.png,width:40%}
\image html OOB_Linux_ifconfig.png
- On the PC, open a Internet Browser and enter in below in the address bar,
\code
http://{IP address of the EVM}:8081
Example,
http://192.168.86.198:8081
\endcode
- The following web page will show in the browser,
\imageStyle{OOB_GUI_root.png,width:50%}
\image html OOB_GUI_root.png
- Click on the "Benchmark Demo",
\imageStyle{OOB_GUI_stats.png,width:70%}
\image html OOB_GUI_stats.png
- The R5F application for each core is fixed. User can change the `Options` for each core, then click `LOAD` to refresh the statistics
# Sample Output
Shown below is a sample output when the application is run.
\imageStyle{OOB_GUI_stats.png,width:70%}
\image html OOB_GUI_stats.png
# Benchmark Results
\cond SOC_AM64X
CORE | CMSIS Application | CPU Usage(Avg) | Interrupt Latency (ns)(Avg) | Cycle Counter per loop(Avg)
---------------|-------------------|----------------|-----------------------------|----------------------------
R5FSS0_1 | CFFT(128pt) | 0 | 358 | 7878
^ | CFFT(256pt) | 2 | 393 | 18374
^ | CFFT(512pt) | 4 | 850 | 34633
^ | CFFT(1024pt) | 13 | 1027 | 105388
R5FSS1_0 | FIR(1KHz) | 3 | 160 | 26942
^ | FIR(2KHz) | 6 | 204 | 26981
^ | FIR(4KHz) | 13 | 166 | 26965
^ | FIR(8KHz) | 26 | 202 | 26994
R5FSS1_1 | FOC(16KHz) | 0 | 202 | 316
^ | FOC(32KHz) | 1 | 164 | 318
^ | FOC(100KHz) | 3 | 174 | 314
^ | FOC(250KHz) | 10 | 199 | 315
\endcond

610
docs_src/docs/api_guide/examples/motorcontrol/endat_example.md Normal file
View File

@ -0,0 +1,610 @@
# EnDAT Diagnostic {#EXAMPLE_MOTORCONTROL_ENDAT}
[TOC]
The EnDat diagnostic application, described here,
demonstrates the EnDat receiver operation.
The EnDat driver provides a well defined set of APIs to expose EnDat
receiver interface.
The diagnostic invokes these APIs to
- initialize EnDat,
- select one configuration among concurrent multi channel with Encoders of Same make, multi channel with Encoders of Different Make and single channel configuration based on SysConfig.
- select the channel (channels in the case of concurrent multi channel with encoders of same make or multi channel with Encoders of Different Make),
- configure the host trigger mode,
- and run the firmware.
- If using "Multi Channel with Encoders of Different Make" configuration is selected" :
- enable load share mode.
- select primary core for global configuration.
- configuration of synchronization bits.
Once these steps are executed,
- the driver waits for the EnDat to be initialized.
- It then sets clock frequency to 200KHz (as propagation delay is not yet compensated)
- and obtains the encoder details including serial number, position resolution etc, and displays on the console/UART.
- Based on the whether encoder is 2.2 or 2.1 type, it sets clock to either 8MHz or 1MHz respectively.
- While configuring clock, propagation delay is taken care using the automatically estimated propagation delay (user can override it too).
- In the case of concurrent Multi Channel with Encoders of Same Make or Multi Channel with Encoders of Different Make, if propagation delay between various channels are different, that too is automatically taken care.
Once initial setup is over,
- the diagnostic provides the user with a self explanatory menu.
- Two types of menu options are presented. One type (1-14) will send an EnDat command as per EnDat 2.2 specification.
- The other type (100-108) allows the user to configure clock frequency, various timing parameters, simulate motor control loop using 2.1 command as well as 2.2 command with safety (redundant position information), switch to continuous clock mode and monitor raw data.
- Concurrent multi channel with Encoder of Same Make configuration can work simultaneously for up-to three encoders with identical part number, all variants of 2.2 position commands as well as the 2.1 position command is supported and an additional option (109) to configure wire delay (useful when propagation delay in each channel is different) is available.
- Single PRU core handles enabled channels in single channel and Multi Channel with Encoders of Same Make configuration.
- Application by default, handles wire delay as required, the menu option provides a way to override it.
After the user selects an EnDat command,
- the diagnostic asks for more details to frame the command and performs a basic sanity check on the user entered values.
- Then the EnDat APIs are invoked to process the command set, set the host trigger bit and waiting until the host trigger bit cleared, If multi-channel with Encoders of Different make is used, these operations are done for each channel".
- The received EnDat is processed & validated using the defined APIs. The result is then presented to the user.
### Channel Selection In Sysconfig
\image html EnDat_channel_selection_In_sysconfig.PNG "Channel Selection In Sysconfig"
\image html Endat_channel_selection_configuration.png "EnDAT configuration seletion between Single/Multi channel "
### Endat Example Implementation
Following section describes the Example implementation of EnDat on ARM(R5F).
\image html Endat_Example_Implementation.png "Endat Example"
## Important files and directory structure
<table>
<tr>
<th>Folder/Files
<th>Description
</tr>
<tr><td colspan="2" bgcolor=#F0F0F0> ${SDK_INSTALL_PATH}/examples/motor_control/endat_diagnostic</td></tr>
<tr>
<td>endat_diagnostic.c</td>
<td>EnDAT diagnostic application</td>
</tr>
<tr><td colspan="2" bgcolor=#F0F0F0> ${SDK_INSTALL_PATH}/source/position_sense/endat</td></tr>
<tr>
<td>firmware/</td>
<td>Folder containing EnDAT firmware sources.</td>
</tr>
<tr>
<td>driver/</td>
<td>EnDAT diagnostic driver.</td>
</tr>
</table>
# Supported Combinations {#EXAMPLES_MOTORCONTROL_ENDAT_COMBOS}
\cond SOC_AM64X
Parameter | Value
---------------|-----------
CPU + OS | r5fss0-0 freertos
ICSSG | ICSSG0
PRU | PRU1
Toolchain | ti-arm-clang
Board | @VAR_BOARD_NAME_LOWER
Example folder | examples/motorcontrol/endat_example
\endcond
\cond SOC_AM243X
Parameter | Value
---------------|-----------
CPU + OS | r5fss0-0 freertos
ICSSG | ICSSG0
PRU | PRU1
Toolchain | ti-arm-clang
Board | @VAR_BOARD_NAME_LOWER, @VAR_LP_BOARD_NAME_LOWER
Example folder | examples/motorcontrol/endat_example
\endcond
# Steps to Run the Example
## Hardware Prerequisites
Other than the basic EVM setup mentioned in \ref EVM_SETUP_PAGE, below additional HW is required to run this demo
- EnDAT encoder
- TIDA-00179 Universal Digital Interface to Absolute Position Encoders, http://www.ti.com/tool/TIDA-00179
- TIDEP-01015 3 Axis board
- Interface card connecting EVM and TIDEP-01015 3 Axis board
\cond SOC_AM243X
### Hardware Prerequisities for Booster Pack
- EnDat encoder
- AM243x-LP board
- BP-AM2BLDCSERVO
\endcond
## Hardware Setup
\imageStyle{EnDAT_Connections.png,width:40%}
\image html EnDAT_Connections.png "Hardware Setup"
\cond SOC_AM243X
## Hardware Setup(Using Booster Pack & AM243x-LP)
\imageStyle{EnDat_Booster_Pack.png,width:40%}
\image html EnDat_Booster_Pack.png "Hardware Setup of Booster Pack + LP for EnDat"
#### Booster Pack Jumper Configuration
<table>
<tr>
<th>Designator</th>
<th>ON/OFF</th>
<th>Description</th>
</tr>
<tr>
<td>J11</td>
<td>OFF</td>
<td>VSENSE/ISENSE select</td>
</tr>
<tr>
<td>J13</td>
<td>OFF</td>
<td>VSENSE/ISENSE select</td>
</tr>
<tr>
<td>J17</td>
<td>Pin 1-2 Connected</td>
<td>SDFM Clock Feedback Select</td>
</tr>
<tr>
<td>J18/J19</td>
<td>J18 OFF & J19 ON</td>
<td>Axis 1: Encoder/Resolver Voltage Select</td>
</tr>
<tr>
<td>J20/J21</td>
<td>J20 ON & J21 OFF</td>
<td>Axis 2: Encoder/Resolver Voltage Select</td>
</tr>
<tr>
<td>J22</td>
<td>OFF</td>
<td>Axis 1: Manchester Encoding Select</td>
</tr>
<tr>
<td>J23</td>
<td>OFF</td>
<td>Axis 2: Manchester Encoding Select</td>
</tr>
<tr>
<td>J24</td>
<td>OFF</td>
<td>Axis 1: RS485/DSL MUX</td>
</tr>
<tr>
<td>J25</td>
<td>OFF</td>
<td>Axis 2: RS485/DSL MUX</td>
</tr>
<tr>
<td>J26</td>
<td>OFF</td>
<td>VSENSE/ISENSE Select</td>
</tr>
<tr>
<td>J27</td>
<td>ON</td>
<td>3WIRE/SDFM MUX</td>
</tr>
<tr>
<td>J28</td>
<td>OFF</td>
<td>3WIRE MUX</td>
</tr>
</table>
\endcond
## Build, load and run
- **When using CCS projects to build**, import the CCS project and build it using the CCS project menu (see \ref CCS_PROJECTS_PAGE).
- **When using makefiles to build**, note the required combination and build using
make command (see \ref MAKEFILE_BUILD_PAGE)
- Launch a CCS debug session and run the executable, see \ref CCS_LAUNCH_PAGE
- Refer to UART terminal for user interface menu options.
### Sample Output
Shown below is a sample output when the application is run:
\imageStyle{EnDAT_Initialization_UART_PRINT.png,width:60%}
\image html EnDAT_Initialization_UART_PRINT.png "EnDAT Usage"
### Test Case Description
<table>
<tr>
<th>Test detail
<th>Steps
<th>Pass/fail crieteria
</tr>
<tr>
<td>To check position value</td>
<td>1. Enter 1 to select "Encoder send position values"</td>
<td>Crc success </td>
</tr>
<tr>
<td>To receive encoder's operating parameters(error messege)</td>
<td>1. Enter 2 to select "Selection of memory area"</td>
<td></td>
</tr>
<tr>
<td></td>
<td>2. Enter "B9" in MRS code to select "Operating parameters"</td>
<td>Crc success </td>
</tr>
<tr>
<td></td>
<td>3. Enter 4 to select "Encoder to send parameter"</td>
<td></td>
</tr>
<tr>
<td></td>
<td>4. Enter 0 in "parameter address" for selecting "Error message"</td>
<td>Crc success </td>
</tr>
<tr>
<td>To receive encoder's manufacture parameters for Endat 2.2</td>
<td>1. Enter 2 to select "Selection of memory area"</td>
<td></td>
</tr>
<tr>
<td></td>
<td>2. Enter "BD" in MRS code to select "Parameters of encoder manufacturer for Endat 2.2"</td>
<td>Crc success </td>
</tr>
<tr>
<td></td>
<td>3. Enter 4 to select "Encoder to send parameter"</td>
<td>Crc success </td>
</tr>
<tr>
<td></td>
<td>4. Enter 0 in "parameter address" for selecting "Status of additional info"</td>
<td>Crc success </td>
</tr>
<tr>
<td>To set values to encoder's operating parameters (error message)</td>
<td>1. Enter 2 to select "Selection of memory area"</td>
<td> </td>
</tr>
<tr>
<td></td>
<td>2. Enter "B9" in MRS code to select "Operating parameters"</td>
<td>Crc success </td>
</tr>
<tr>
<td></td>
<td>3. Enter 3 to select "Encoder to receive parameter"</td>
<td> </td>
</tr>
<tr>
<td></td>
<td>4. Enter 0 in "parameter address" for selecting "Error message"</td>
<td></td>
</tr>
<tr>
<td></td>
<td>5. Enter 0 in "parameter value" for seting value in " Error message"</td>
<td>Crc success </td>
</tr>
<tr>
<td>To set values to encoder's manufacturing parameters for Endat 2.2(Status of additional info)</td>
<td>1. Enter 2 to select "Selection of memory area"</td>
<td></td>
</tr>
<tr>
<td></td>
<td>2. Enter "BD" in MRS code to select "Parameters of encoder manufacturer for Endat 2.2"</td>
<td>Crc success </td>
</tr>
<tr>
<td></td>
<td>3. Enter 3 to select "Encoder to receive parameter"</td>
<td></td>
</tr>
<tr>
<td></td>
<td>4. Enter 0 in "parameter address" for selecting "Status of additional info"</td>
<td></td>
</tr>
<tr>
<td></td>
<td>5. Enter 0 in "parameter value" for seting value in " Status of additional info"</td>
<td>Crc success </td>
</tr>
<tr>
<td>To reset encoder</td>
<td>1. Enter 5 to select "Encoder receive reset"</td>
<td>Crc success </td>
</tr>
<tr>
<td>To receive test values from encoder with port address "0"</td>
<td>1. Enter 7 to select "Encoder receive test command"</td>
<td> </td>
</tr>
<tr>
<td></td>
<td>2. Enter 0 in "enter port address" </td>
<td> </td>
</tr>
<tr>
<td></td>
<td>3. Enter 6 to select "Encoder send test values"</td>
<td>Crc success </td>
</tr>
<tr>
<td>To receive test values from encoder with port address "E" </td>
<td>1. Enter 7 to select "Encoder receive test command"</td>
<td> </td>
</tr>
<tr>
<td></td>
<td>2. Enter "E" in "enter port address" </td>
<td> </td>
</tr>
<tr>
<td></td>
<td>3. Enter 6 to select "Encoder send test values"</td>
<td>Crc success </td>
</tr>
<tr>
<td>To check position value with aditional info.</td>
<td>1. Enter 8 to select "Encoder send position values + AI(s)"</td>
<td>Crc success </td>
</tr>
<tr>
<td>To receive encoder's operating parameters(error messege)
+receive position value with additional info
</td>
<td>1. Enter 9 to select "Encoder send position values + AI(s) and Selection of memory area"</td>
<td> </td>
</tr>
<tr>
<td></td>
<td>2. Enter "B9" in MRS code to select "Operating parameters"</td>
<td>Crc success </td>
</tr>
<tr>
<td></td>
<td>3. Enter 11 to select "Encoder send position values + AI(s) and send parameter"</td>
<td> </td>
</tr>
<tr>
<td></td>
<td>4. Enter 0 in "parameter address" for selecting "Error message"</td>
<td>Crc success</td>
</tr>
<tr>
<td>To receive encoder's manufacture parameters
for Endat 2.2 +receive position value with additional info
<td>1. Enter 9 to select "Encoder send position values + AI(s) and Selection of memory area"</td>
<td> </td>
</tr>
<tr>
<td></td>
<td>2. Enter "BD" in MRS code to select "Parameters of encoder manufacturer for Endat 2.2"</td>
<td>Crc success </td>
</tr>
<tr>
<td></td>
<td>3. Enter 11 to select "Encoder send position values + AI(s) and send parameter"</td>
<td> </td>
</tr>
<tr>
<td></td>
<td>4. Enter 0 in "parameter address" for selecting "Status of additional info"</td>
<td>Crc success</td>
</tr>
<tr>
<td>To set values to encoder's operating parameters (error message)
+receive position value with additional info
<td>1. Enter 9 to select "Encoder send position values + AI(s) and Selection of memory area"</td>
<td> </td>
</tr>
<tr>
<td></td>
<td>2. Enter "B9" in MRS code to select "Operating parameters"</td>
<td>Crc success </td>
</tr>
<tr>
<td></td>
<td>3. Enter 10 to select "Encoder send position values + AI(s) and receive parameter"</td>
<td> </td>
</tr>
<tr>
<td></td>
<td>4. Enter 0 in "parameter address" for selecting "Error message"</td>
<td> </td>
</tr>
<tr>
<td></td>
<td>5. Enter 0 in "parameter value" for seting value in " Error message"</td>
<td>Crc success</td>
</tr>
<tr>
<td>To set values to encoder's manufacturing parameters for Endat 2.2(Status of additional info)
+receive position value with additional info
</td>
<td>1. Enter 9 to select "Encoder send position values + AI(s) and Selection of memory area"</td>
<td> </td>
</tr>
<tr>
<td></td>
<td>2. Enter "BD" in MRS code to select "Parameters of encoder manufacturer for Endat 2.2"</td>
<td>Crc success </td>
</tr>
<tr>
<td></td>
<td>3. Enter 10 to select "Encoder send position values + AI(s) and receive parameter"</td>
<td> </td>
</tr>
<tr>
<td></td>
<td>4. Enter 0 in "parameter address" for selecting "Status of additional info"</td>
<td> </td>
</tr>
<tr>
<td></td>
<td>5. Enter 0 in "parameter value" for seting value in " Status of additional info"</td>
<td>Crc success</td>
</tr>
<tr>
<td>To reset encoder +receive position value with additional info</td>
<td>1. Enter 12 to select "Encoder send position values + AI(s) and receive error reset"</td>
<td>Crc success </td>
</tr>
<tr>
<td></td>
<td>1. Enter 14 to select "Encoder receive communication command"</td>
<td>Crc success </td>
</tr>
<tr>
<td></td>
<td>2. Enter ______in "enter encoder address" </td>
<td>Crc success </td>
</tr>
<tr>
<td></td>
<td>3. Enter _____ in "instruction hex value"</td>
<td>Crc success </td>
</tr>
<tr>
<td></td>
<td>1. Enter 14 to select "Encoder receive communication command"</td>
<td>Crc success </td>
</tr>
<tr>
<td></td>
<td>2. Enter ______in "enter encoder address" </td>
<td>Crc success </td>
</tr>
<tr>
<td></td>
<td>3. Enter _____ in "instruction hex value"</td>
<td>Crc success </td>
</tr>
<tr>
<td>Configure Clock </td>
<td>1. Enter 100 to select "configure clock"</td>
<td>Crc success(Tested up to 8MHz)</td>
</tr>
<tr>
<td></td>
<td>2. Enter ___ for clock frequency(in Hz)</td>
<td> </td>
</tr>
<tr>
<td>Simulate motor control 2.1 position loop</td>
<td>1. Enter 101 to select "Simulate motor control 2.1 position loop"</td>
<td> </td>
</tr>
<tr>
<td></td>
<td>2. Enter 10000 to select "clock frequency"</td>
<td> </td>
</tr>
<tr>
<td></td>
<td>3. Rotate the rotor of motor and see the changes in Position value on UART</td>
<td>Position Values are changing when rotor moves </td>
</tr>
<tr>
<td>Toggle raw data display</td>
<td>1. Enter 102 to select "Toggle raw data display"</td>
<td> </td>
</tr>
<tr>
<td></td>
<td>2. Enter 1 to select "Encoder send position value"</td>
<td>raw data can be displayed </td>
</tr>
<tr>
<td>Configure TST delay</td>
<td></td>
<td> </td>
</tr>
<tr>
<td>Start continous mode</td>
<td>1. Enter 104 to select "Start continous mode"</td>
<td> </td>
</tr>
<tr>
<td></td>
<td>2. Rotate the rotor of motor and see the changes in Position value on UART</td>
<td>Position Values are changing when rotor moves </td>
</tr>
<tr>
<td>Configure rx arm counter</td>
<td>1. Enter 105 to select "Configure rx arm counter" </td>
<td> </td>
</tr>
<tr>
<td></td>
<td>2. Enter 0 to select channel 0(only for multi channel configuration) </td>
<td> </td>
</tr>
<tr>
<td></td>
<td>3. Enter ___ to "select time in ns"</td>
<td> </td>
</tr>
<tr>
<td>configure rx clock disable time</td>
<td>1. Enter 106 to select "configure rx clock disable time"</td>
<td> </td>
</tr>
<tr>
<td></td>
<td>2. Enter 0 to select channel 0(only for multi channel configuration)</td>
<td> </td>
</tr>
<tr>
<td></td>
<td>3. Enter ___ to "select time in ns"</td>
<td> </td>
</tr>
<tr>
<td>Simulate motor control 2.2 position loop(safety)</td>
<td>1. Enter 107 to select "Simulate motor control 2.2 position loop"</td>
<td> </td>
</tr>
<tr>
<td></td>
<td>3. Enter 10000 to select "clock frequency"</td>
<td> </td>
</tr>
<tr>
<td></td>
<td>4. Rotate the rotor of motor and see the changes in Position value on UART</td>
<td>Position Values are changing when rotor moves </td>
</tr>
<tr>
<td>Configure propogation delay(td)</td>
<td>1. Enter 108 to select configure propagation delay </td>
<td> </td>
</tr>
<tr>
<td></td>
<td>2. Enter 0 to select channel 0(only for multi channel configuration)</td>
<td> </td>
</tr>
<tr>
<td>To read Recovery Time</td>
<td>1. Enter 8 to select "Encoder send position values + AI(s)" </td>
<td>Crc Success </td>
</tr>
<tr>
<td></td>
<td>2. Enter 110 for read recovery time from DMEM </td>
<td> Recovery Time is set to 1.25 us <= RT <= 3.75us or 10 us <= RT <= 30 us</td>
</tr>
</table>

258
docs_src/docs/api_guide/examples/motorcontrol/hdsl_example.md Normal file
View File

@ -0,0 +1,258 @@
# HDSL Diagnostic {#EXAMPLE_MOTORCONTROL_HDSL}
[TOC]
## Introduction
The HDSL diagnostic application described here interacts with the firmware interface.
HDSL diagnostic application does below,
- Configures pinmux, GPIO, ICSS clock to 225MHz,
- Initializes ICSS0-PRU1, ICSS0-IEP0 and IEP1(for SYNC mode support.Timesync router is used to latch the loopback.),
- Loads lookup table for encoding/decoding of Hiperface data
- Loads the initialization section of PRU firmware & executes it.
Firmware is split to three sections, initialization, datalink and transport.
At startup, the application displays details about encoder and status.
It then presents the user with menu options, based on the option selected, application communicates with HDSL interface and the result is presented to the user.
## Important files and directory structure
<table>
<tr>
<th>Folder/Files
<th>Description
</tr>
<tr><td colspan="2" bgcolor=#F0F0F0> ${SDK_INSTALL_PATH}/examples/motor_control/hdsl_diagnostic</td></tr>
<tr>
<td>hdsl_diagnostic.c
hdsl_diagnostic.h</td>
<td> Source and Header files </td>
</tr>
<tr><td colspan="2" bgcolor=#F0F0F0> ${SDK_INSTALL_PATH}/source/position_sense/hdsl</td></tr>
<tr>
<td>driver/</td>
<td>Folder containing HDSL PRU driver sources.</td>
</tr>
<tr>
<td>include/</td>
<td>Folder containing HDSL PRU header sources.</td>
</tr>
<tr>
<td>firmware/</td>
<td>Folder containing HDSL PRU firmware sources.</td>
</tr>
</table>
\cond SOC_AM64X
Parameter | Value
---------------|-----------
CPU + OS | r5fss0-0 freertos
ICSSG | ICSSG0
PRU | PRU1
Toolchain | ti-arm-clang
Board | @VAR_BOARD_NAME_LOWER
Example folder | examples/motorcontrol/hdsl_example
\endcond
\cond SOC_AM243X
Parameter | Value
---------------|-----------
CPU + OS | r5fss0-0 freertos
ICSSG | ICSSG0
PRU | PRU1
Toolchain | ti-arm-clang
Board | @VAR_BOARD_NAME_LOWER, @VAR_LP_BOARD_NAME_LOWER
Example folder | examples/motorcontrol/hdsl_example
\endcond
# Steps to Run the Example
## Hardware Prerequisites
Other than the basic EVM setup mentioned in \ref EVM_SETUP_PAGE, below additional HW is required to run this demo
- HDSL encoder
- Below are two options to connect encoder to AM64x/AM243x EVM.
- **Option 1**
- TIDA-00179 Universal Digital Interface to Absolute Position Encoders, http://www.ti.com/tool/TIDA-00179
- TIDEP-01015 3 Axis board
- Interface card connecting EVM and TIDEP-01015 3 Axis board
- Connect the Hiperface DSL encoder to HDSL+/-(Pin number 6 and 7) signals available on header J7 or Sub-D15 connector of the "Universal Digital Interface to Absolute Position Encoders" board.
- **Option 2**
- HDSL AM64xE1 Transceiver. If application is using this card, define the macro HDSL_AM64xE1_TRANSCEIVER in the CCS project/make file.
- Connect the Hiperface DSL encoder to J10.
- HDSL AM64xE1 Transceiver supports two channels that can be used to support HDSL safety, multi axis servo drives.
- Schematics are shared in the MCU+SDK package. For more design details of the transceiver card, please contact TI via E2E/FAE.
- \htmllink{../am64x_am243x/HDSL_AM64xE1_Schematics.pdf, HDSL Transceiver Card Schematics} document.
\cond SOC_AM243X
### Hardware Prerequisities for Booster Pack
- HDSL encoder
- AM243x-LP board
- BP-AM2BLDCSERVO
\endcond
## Hardware Setup(Using TIDA-00179, TIDEP-01015 and Interface board)
\imageStyle{HDSL_Connections.png,width:40%}
\image html HDSL_Connections.png "Hardware Setup"
## Hardware Setup(Using HDSL AM64xE1 Transceiver)
\imageStyle{HDSL_AM64xE1.png,width:60%}
\image html HDSL_AM64xE1.png "Hardware Setup"
\cond SOC_AM243X
## Hardware Setup(Using Booster Pack & AM243x-LP)
\imageStyle{HDSL_Booster_Pack.png,width:40%}
\image html HDSL_Booster_Pack.png "Hardware Setup of Booster Pack + LP for HDSL"
#### Booster Pack Jumper Configuration
<table>
<tr>
<th>Designator</th>
<th>ON/OFF</th>
<th>Description</th>
</tr>
<tr>
<td>J11</td>
<td>OFF</td>
<td>VSENSE/ISENSE select</td>
</tr>
<tr>
<td>J13</td>
<td>OFF</td>
<td>VSENSE/ISENSE select</td>
</tr>
<tr>
<td>J17</td>
<td>Pin 1-2 Connected</td>
<td>SDFM Clock Feedback Select</td>
</tr>
<tr>
<td>J18/J19</td>
<td>J18 OFF & J19 ON</td>
<td>Axis 1: Encoder/Resolver Voltage Select</td>
</tr>
<tr>
<td>J20/J21</td>
<td>J20 ON & J21 OFF</td>
<td>Axis 2: Encoder/Resolver Voltage Select</td>
</tr>
<tr>
<td>J22</td>
<td>OFF</td>
<td>Axis 1: Manchester Encoding Select</td>
</tr>
<tr>
<td>J23</td>
<td>OFF</td>
<td>Axis 2: Manchester Encoding Select</td>
</tr>
<tr>
<td>J24</td>
<td>ON</td>
<td>Axis 1: RS485/DSL MUX</td>
</tr>
<tr>
<td>J25</td>
<td>OFF</td>
<td>Axis 2: RS485/DSL MUX</td>
</tr>
<tr>
<td>J26</td>
<td>OFF</td>
<td>VSENSE/ISENSE Select</td>
</tr>
<tr>
<td>J27</td>
<td>ON</td>
<td>3WIRE/SDFM MUX</td>
</tr>
<tr>
<td>J28</td>
<td>OFF</td>
<td>3WIRE MUX</td>
</tr>
</table>
\endcond
## Build, load and run
- **When using CCS projects to build**, import the CCS project and build it using the CCS project menu (see \ref CCS_PROJECTS_PAGE).
- **When using makefiles to build**, note the required combination and build using
make command (see \ref MAKEFILE_BUILD_PAGE)
- Launch a CCS debug session and run the executable, see \ref CCS_LAUNCH_PAGE
- Refer to UART terminal for user interface menu options.
# Sync Mode:
- Note
This is a test feature, in real application - PWM syncout will be connected to Latch input instead of IEP1 sync.
## Synchronization with external Pulse
According to the Hiperface DSL specification, the falling edge inside the EXTRA window should coincide with the external synchronization pulse.
At the beginning of the startup phase, the firmware measures the time interval of the external pulse and calculates the required number of bits for the H-Frame.
Based on this number the stuffing length and EXTRA window size is derived.
Afterwards, the PRU waits to match its timing with the timing of the external synchronization pulse and starts the transmission.
Since it is possible to use time intervals for the external pulse that are not multiples of the bit duration, the firmware needs to adjust the H-Frame size on the fly.
Furthermore, during the EXTRA window the PRU transmits the data (sample edge) with a granularity of 13.3ns to increase the synchronization accuracy. Figure "Synchronization of External Pulse with Sample Edge in EXTRA Window" and "Illustration of Synchronization Algorithm" depict the concept.
The EXTRA_TIME_WINDOW is a fixed value that is calculated at startup to match the external pulse frequency. The TIME_REST value gives the number of overclocked ‘1’ that needs to be sent during the last bit of the EXTRA window.
\imageStyle{hdsl_external_sync.png,width:40%}
\image html hdsl_external_sync.png "Synchronization of External Pulse with Sample Edge in EXTRA Window"
In other words, the TIME_REST value represents the sample edge in a fine granularity dimension (13.3ns). While the sample edge can be send with a finer granularity, the granularity of the size of the EXTRA window is still in whole bit durations (106.67ns).
Consequently, there is an overhead, if the external pulse period is not a multiple of the bit duration. This overhead is compensated in the next H-Frame by changing the size of the EXTRA window. As a result, the size of the H-Frame is varying over time.
It is possible that these calculations lead to the excess of the maximum or minimum EXTRA window size. Therefore, the number of bits for the stuffing and EXTRA window is readjusted on a violation.
\imageStyle{hdsl_sync_algo.png,width:40%}
\image html hdsl_sync_algo.png "Illustration of Synchronization Algorithm"
The algorithm is given as C code in the following:
/* EXTRA_SIZE equals the number of bits for the EXTRA window minus 1 */
if(EXTRA_EDGE == 0)
TIME_REST += 8;
short b = (EXTRA_SIZE << 3) + TIME_REST;
short overhead = (EXTRA_SIZE << 3) + 8 - TIME_EXTRA_WINDOW;
EXTRA_SIZE = (b - overhead) >> 3;
TIME_REST = (b - overhead) - (EXTRA_SIZE << 3);
if(EXTRA_SIZE < 3) {
EXTRA_SIZE += 6;
NUM_STUFFING -= 1;
TIME_EXTRA_WINDOW += (8*6);
}
if(EXTRA_SIZE > 8) {
EXTRA_SIZE -= 6;
NUM_STUFFING += 1;
TIME_EXTRA_WINDOW -= (8*6);
}
EXTRA_EDGE represents the TIME_REST value in a format that can be pushed to the TX FIFO for transmission. For instance, if TIME_REST is 4, EXTRA_EDGE is 0xf0. The edge would be in the middle of the bit duration. The value NUM_STUFFING gives the number of stuffing blocks (each block consist of 6 bits).
For further improvement of the synchronization, the time difference (∆t) between the external pulse and the sample edge we transmit is measured (Figure "Time difference between External Pulse and Sample Edge").
\imageStyle{hdsl_external_sync_sample_edge.png,width:40%}
\image html hdsl_external_sync_sample_edge.png "Time difference between External Pulse and Sample Edge"
# Sample Output
Shown below is a sample output when the application is run:
- Freerun mode:
\imageStyle{hdsl_default_uart_menu.PNG,width:60%}
\image html hdsl_default_uart_menu.PNG "HDSL DDR UART Default Menu"
- Sync Mode:
\imageStyle{HDSL_SYNC.png,width:60%}
\image html HDSL_SYNC.png "HDSL Diagnostic in SYNC mode"

108
docs_src/docs/api_guide/examples/motorcontrol/hdsl_example_trace.md Normal file
View File

@ -0,0 +1,108 @@
# HDSL Diagnostic with Traces {#EXAMPLE_MOTORCONTROL_HDSL_TRACE}
[TOC]
## Introduction
The HDSL diagnostic application described here interacts with the firmware interface.
HDSL diagnostic application does below,
Configures pinmux, GPIO, ICSS clock to 225MHz,
Initializes ICSS0-PRU1, ICSS0-IEP0 and IEP1(for SYNC mode support.Timesync router is used to latch the loopback.),
Loads lookup table for encoding/decoding of Hiperface data
Loads the initialization section of PRU firmware & executes it.
Firmware is split to three sections, initialization, datalink and transport. At startup, the application displays details about encoder and status. It then presents the user with menu options, based on the option selected, application communicates with HDSL interface and the result is presented to the user.
## Important files and directory structure
<table>
<tr>
<th>Folder/Files
<th>Description
</tr>
<tr><td colspan="2" bgcolor=#F0F0F0> ${SDK_INSTALL_PATH}/examples/motor_control/hdsl_diagnostic_with_traces</td></tr>
<tr>
<td>hdsl_diagnostic_ddr.c
hdsl_diagnostic_ddr.h</td>
</tr>
<tr><td colspan="2" bgcolor=#F0F0F0> ${SDK_INSTALL_PATH}/source/position_sense/hdsl</td></tr>
<tr>
<td>driver/</td>
<td>Folder containing HDSL PRU driver sources.</td>
</tr>
<tr>
<td>include/</td>
<td>Folder containing HDSL PRU header sources.</td>
</tr>
<tr>
<td>firmware/</td>
<td>Folder containing HDSL PRU firmware sources.</td>
</tr>
</table>
\cond SOC_AM64X || SOC_AM243X
Parameter | Value
---------------|-----------
CPU + OS | r5fss0-0 freertos
ICSSG | ICSSG0
PRU | PRU1
Toolchain | ti-arm-clang
Board | @VAR_BOARD_NAME_LOWER
Example folder | examples/motorcontrol/hdsl_example
\endcond
# Steps to Run the Example
## Hardware Prerequisites
Other than the basic EVM setup mentioned in \ref EVM_SETUP_PAGE, below additional HW is required to run this demo
- HDSL encoder
- Below are two options to connect encoder to AM64x/AM243x EVM.
- **Option 1**
- TIDA-00179 Universal Digital Interface to Absolute Position Encoders, http://www.ti.com/tool/TIDA-00179
- TIDEP-01015 3 Axis board
- Interface card connecting EVM and TIDEP-01015 3 Axis board
- Connect the Hiperface DSL encoder to HDSL+/-(Pin number 6 and 7) signals available on header J7 or Sub-D15 connector of the "Universal Digital Interface to Absolute Position Encoders" board.
- **Option 2**
- HDSL AM64xE1 Transceiver. If application is using this card, define the macro HDSL_AM64xE1_TRANSCEIVER in the CCS project/make file.
- Connect the Hiperface DSL encoder to J10.
- HDSL AM64xE1 Transceiver supports two channels that can be used to support HDSL safety, multi axis servo drives.
- Schematics are shared in the MCU+SDK package. For more design details of the transceiver card, please contact TI via E2E/FAE.
- \htmllink{../am64x_am243x/HDSL_AM64xE1_Schematics.pdf, HDSL Transceiver Card Schematics} document.
## Hardware Setup(Using TIDA-00179, TIDEP-01015 and Interface board)
\imageStyle{HDSL_Connections.png,width:40%}
\image html HDSL_Connections.png "Hardware Setup"
## Hardware Setup(Using HDSL AM64xE1 Transceiver)
\imageStyle{HDSL_AM64xE1.png,width:60%}
\image html HDSL_AM64xE1.png "Hardware Setup"
## Build, load and run
- **When using CCS projects to build**, import the CCS project and build it using the CCS project menu (see \ref CCS_PROJECTS_PAGE).
- **When using makefiles to build**, note the required combination and build using
make command (see \ref MAKEFILE_BUILD_PAGE)
- Launch a CCS debug session and run the executable, see \ref CCS_LAUNCH_PAGE
- Refer to UART terminal for user interface menu options.
\imageStyle{hdsl_ddr_trace.png,width:60%}
\image html hdsl_ddr_trace.png "HDSL DDR Traces Flow Chart"
###Note:
- If you are using load_dmsc.js file for initialization, Then Go to menu Scripts --> AM64 DDR Initialization -> AM64_DDR_Initialization_ECC_Disabled to initialize DDR.
- If you are using SBL NULL. DDR initialization will be taken care itself.
# Sample Output
Shown below is a sample output when the application is run:
- Freerun mode:
\imageStyle{hdsl_ddr_uart.png,width:60%}
\image html hdsl_ddr_uart.PNG "HDSL DDR UART Menu"

16
docs_src/docs/api_guide/examples/motorcontrol/motorcontrol.md Normal file
View File

@ -0,0 +1,16 @@
# Motor Control {#EXAMPLES_MOTORCONTROL}
This page lists all the examples related to motor control applications.
\cond SOC_AM64X || SOC_AM243X
-# \subpage EXAMPLE_MOTORCONTROL_BENCHMARKDEMO
-# \subpage EXAMPLE_MOTORCONTROL_ENDAT
-# \subpage EXAMPLE_MOTORCONTROL_HDSL
-# \subpage EXAMPLE_MOTORCONTROL_HDSL_TRACE
-# \subpage EXAMPLE_MOTORCONTROL_TAMAGAWA
-# \subpage EXAMPLE_MOTORCONTROL_SDFM
\endcond
\cond SOC_AM263X
-# \subpage EXAMPLE_MOTORCONTROL_TAMAGAWA_OVER_UART
\endcond

162
docs_src/docs/api_guide/examples/motorcontrol/sdfm_example.md Normal file
View File

@ -0,0 +1,162 @@
# SDFM {#EXAMPLE_MOTORCONTROL_SDFM}
[TOC]
The ICSS SDFM driver provides a well defined set of APIs to expose sigma delta interface.
The ICSS SDFM example invokes these APIs to
- Set SDFM channels
- Set ACC source, NC OSR, OC OSR, Clock source & Clock inversion
- Enable & disable threshold comparators
- Set high, low & zero cross threshold values
- configure sample trigger time (time for read sample)
- Inform firmware to enable SDFM mode
- Configure GPIO pins for high, low & zero cross thresholds
Once these steps are executed
- ICSS SDFM example waits for a interrupt (trigger by SDFM firmware) to read sample data
- when interrupt occurs, example reads sample data from DMEM and again comes back to waiting loop
### ICSS SDFM Example Implementation
Following section describes the Example implementation of ICSS SDFM on ARM(R5F).
\image html SDFM_EXAMPLE_FLOWCHART.png "ICSS SDFM Example"
## Important files and directory structure
<table>
<tr>
<th>Folder/Files
<th>Description
</tr>
<tr><td colspan="2" bgcolor=#F0F0F0> ${SDK_INSTALL_PATH}/examples/motor_control/icss_sdfm</td></tr>
<tr>
<td>app_sddf.c & sddf.c</td>
<td>ICSS SDFM application</td>
</tr>
<tr><td colspan="2" bgcolor=#F0F0F0> ${SDK_INSTALL_PATH}/source/current_sense/sdfm</td></tr>
<tr>
<td>firmware/</td>
<td>Folder containing SDFM firmware sources.</td>
</tr>
<tr>
<td>driver/</td>
<td>ICSS SDFM driver.</td>
</tr>
</table>
# Supported Combinations {#EXAMPLES_MOTORCONTROL_SDFM_COMBOS}
\cond SOC_AM64X
Parameter | Value
---------------|-----------
CPU + OS | r5fss0-0 freertos
ICSSG | ICSSG0
PRU | PRU0
Toolchain | ti-arm-clang
Board | @VAR_BOARD_NAME_LOWER
Example folder | examples/motorcontrol/sddf
\endcond
\cond SOC_AM243X
Parameter | Value
---------------|-----------
CPU + OS | r5fss0-0 freertos
ICSSG | ICSSG0
PRU | PRU0
Toolchain | ti-arm-clang
Board | @VAR_BOARD_NAME_LOWER
Example folder | examples/motorcontrol/sddf
\endcond
# Steps to Run the Example
## Hardware Prerequisites
Other than the basic EVM setup mentioned in \ref EVM_SETUP_PAGE, below additional HW is required to run this demo
- TIDEP-01015 3 Axis board
- Interface card connecting EVM and TIDEP-01015 3 Axis board
- Signal generator
## Hardware Setup
\image html SDFM_HwSetup_image.PNG "Hardware Setup SDFM"
## Build, load and run
- **When using CCS projects to build**, import the CCS project and build it using the CCS project menu (see \ref CCS_PROJECTS_PAGE).
- **When using makefiles to build**, note the required combination and build using
make command (see \ref MAKEFILE_BUILD_PAGE)
- Launch a CCS debug session and run the executable, see \ref CCS_LAUNCH_PAGE
- Refer to UART terminal for user interface menu options.
### Test Case Description
<table>
<tr>
<th>Test detail
<th>Steps
<th>Pass/fail crieteria
</tr>
<tr>
<td>To check raw data for 64 NC OSR</td>
<td>1. Set NC OSR to 64</td>
<td>Resolution of sampled data should be 13.9 bits </td>
</tr>
<tr>
<td></td>
<td>2. Set data read time half of epwm cycle</td>
<td></td>
</tr>
<tr>
<td></td>
<td>3. Set epwm output frequency 20Khz</td>
<td></td>
</tr>
<tr>
<td></td>
<td>4. Draw graph for Raw data</td>
<td>\image html SDFM_sample_output.PNG "NC sample data"</td>
</tr>
<tr>
<td>To check raw data for 32 NC OSR</td>
<td>1. Set NC OSR to 32</td>
<td>Resolution of sampled data should be 11.4 bits </td>
</tr>
<tr>
<td></td>
<td>2. Set data read time half of epwm cycle</td>
<td></td>
</tr>
<tr>
<td></td>
<td>3. Set epwm output frequency 20Khz</td>
<td></td>
</tr>
<tr>
<td>To check Threshold comparator</td>
<td>1. Set High Threshold to 3500 and low threshold to 2500</td>
<td>Logic analyzer capture for High & Low Thresholds </td>
</tr>
<tr>
<td></td>
<td>2. Set Over current OSR to 32</td>
<td>\image html SDFM_threshold_comparator_salea_capture.png "Logic analyzer Capture"</td>
</tr>
<tr>
<td></td>
<td>3. Probe Ch0 high, low threshold GPIO pins & input signal </td>
<td></td>
</tr>
<tr>
<td></td>
<td>4. Capture signal in Logic analyzer</td>
<td></td>
</tr>
</table>

299
docs_src/docs/api_guide/examples/motorcontrol/tamagawa_example.md Normal file
View File

@ -0,0 +1,299 @@
# Tamagawa Diagnostic {#EXAMPLE_MOTORCONTROL_TAMAGAWA}
[TOC]
\note
Starting with MCU+ SDK version 08.05.00, the Tamagawa firmware and examples are based on EnDAT hardware interface from PRU-ICSSG.
## Introduction
Tamagawa diagnostic application does below,
Configures pinmux, GPIO, UART, ICSS clock to 200MHz,
Initializes ICSS0-PRU1,
Loads the initialization section of PRU firmware & executes it.
This application is controlled with a terminal interface using a serial over USB connection between the PC host and the EVM.
Please connect a USB cable between the PC and the EVM/LP.
A serial terminal application (like teraterm/ hyperterminal/ minicom) is then run on the host.
To configure, select the serial port corresponding to the port emulated over USB by the EVM.
The host serial port should be configured to 115200 baud, no parity, 1 stop bit and no flow control.
Connect the Tamagawa encoders via TIDA-00179 cards on a 3 axis board (TIDEP-01015) to the EVM.
On AM243x LP, a Tamagawa encoder can be directly connected using a TIDA-00179 card.
\note
Only single channel configuration with Channel 0 is supported as of now on LP.
The connections between AM243x LP and TIDA-00179 for Channel 0 are:
TAMAGAWA_CHANNEL0_TX -> PRG0_PRU1_GPO1,
TAMAGAWA_CHANNEL0_TX_ENABLE -> PRG0_PRU1_GPO2,
TAMAGAWA_CHANNEL0_RX -> PRG0_PRU1_GPO13,
TAMAGAWA_CHANNEL0_CLK -> PRG0_PRU1_GPO0.
The Tamagawa receiver firmware running on ICSS0-PRU1 provides a defined interface. The Tamagawa diagnostic application interacts with the Tamagawa receiver firmware interface. It then presents the user with menu options to select Data ID code (as defined by Tamagawa) to be sent to the encoder. The application collects the data entered by the user and configures the relevant interface. Then via the Tamagawa receiver interface, the command is triggered. Once the command completion is indicated by the interface, the status of the transaction is checked. If the Status indicates success, the result is presented to the user.
## Important files and directory structure
<table>
<tr>
<th>Folder/Files
<th>Description
</tr>
<tr><td colspan="2" bgcolor=#F0F0F0> ${SDK_INSTALL_PATH}/examples/motor_control/tamagawa_diagnostic</td></tr>
<tr>
<td>tamagawa_diagnostic.c</td>
<td>Tamagawa diagnostic application</td>
</tr>
<tr><td colspan="2" bgcolor=#F0F0F0> ${SDK_INSTALL_PATH}/source/position_sense/tamagawa</td></tr>
<tr>
<td>firmware/</td>
<td>Folder containing TAMAGAWA PRU firmware sources.</td>
</tr>
<tr>
<td>driver/</td>
<td>Tamagawa diagnostic driver.</td>
</tr>
</table>
# Supported Combinations {#EXAMPLES_MOTORCONTROL_TAMAGAWA_COMBOS}
\cond SOC_AM64X
Parameter | Value
---------------|-----------
CPU + OS | r5fss0-0 freertos
ICSSG | ICSSG0
PRU | PRU1
Toolchain | ti-arm-clang
Board | @VAR_BOARD_NAME_LOWER
Example folder | examples/motor_control/tamagawa_diagnostic
\endcond
\cond SOC_AM243X
Parameter | Value
---------------|-----------
CPU + OS | r5fss0-0 freertos
ICSSG | ICSSG0
PRU | PRU1
Toolchain | ti-arm-clang
Board | @VAR_BOARD_NAME_LOWER, @VAR_LP_BOARD_NAME_LOWER (E3 Revision)
Example folder | examples/motor_control/tamagawa_diagnostic
\endcond
# Steps to Run the Example
## Hardware Prerequisites
Other than the basic EVM setup mentioned in \ref EVM_SETUP_PAGE, additional hardware required to run this demo is mentioned below
- Tamagawa Encoders
- TIDA-00179 Universal Digital Interface to Absolute Position Encoders, http://www.ti.com/tool/TIDA-00179
- TIDEP-01015 3 Axis board
- Interface card connecting EVM and TIDEP-01015 3 Axis board
\cond SOC_AM243X
### Hardware Prerequisities for Booster Pack
- Tamagawa encoder
- AM243x-LP board
- BP-AM2BLDCSERVO
\endcond
## Hardware Setup
\imageStyle{Tamagawa_setup.jpg,width:60%}
\image html Tamagawa_setup.jpg "Hardware Setup for 3 channels on EVM"
\imageStyle{Tamagawa_connections.JPG,width:60%}
\image html Tamagawa_connections.JPG "Tamagawa Encoder Hardware Setup for 3 channels"
\cond SOC_AM243X
\imageStyle{Tamagawa_Setup_am243x_lp.jpeg,width:60%}
\image html Tamagawa_Setup_am243x_lp.jpeg "Hardware Setup for 1 channel on AM243x Launchpad"
## Hardware Setup(Using Booster Pack & AM243x-LP)
\imageStyle{Tamagawa_Booster_Pack.png,width:40%}
\image html Tamagawa_Booster_Pack.png "Hardware Setup of Booster Pack + LP for Tamagawa"
#### Booster Pack Jumper Configuration
<table>
<tr>
<th>Designator</th>
<th>ON/OFF</th>
<th>Description</th>
</tr>
<tr>
<td>J11</td>
<td>OFF</td>
<td>VSENSE/ISENSE select</td>
</tr>
<tr>
<td>J13</td>
<td>OFF</td>
<td>VSENSE/ISENSE select</td>
</tr>
<tr>
<td>J17</td>
<td>Pin 1-2 Connected</td>
<td>SDFM Clock Feedback Select</td>
</tr>
<tr>
<td>J18/J19</td>
<td>J18 OFF & J19 ON</td>
<td>Axis 1: Encoder/Resolver Voltage Select</td>
</tr>
<tr>
<td>J20/J21</td>
<td>J20 ON & J21 OFF</td>
<td>Axis 2: Encoder/Resolver Voltage Select</td>
</tr>
<tr>
<td>J22</td>
<td>OFF</td>
<td>Axis 1: Manchester Encoding Select</td>
</tr>
<tr>
<td>J23</td>
<td>OFF</td>
<td>Axis 2: Manchester Encoding Select</td>
</tr>
<tr>
<td>J24</td>
<td>OFF</td>
<td>Axis 1: RS485/DSL MUX</td>
</tr>
<tr>
<td>J25</td>
<td>OFF</td>
<td>Axis 2: RS485/DSL MUX</td>
</tr>
<tr>
<td>J26</td>
<td>OFF</td>
<td>VSENSE/ISENSE Select</td>
</tr>
<tr>
<td>J27</td>
<td>ON</td>
<td>3WIRE/SDFM MUX</td>
</tr>
<tr>
<td>J28</td>
<td>OFF</td>
<td>3WIRE MUX</td>
</tr>
</table>
\endcond
## Build, load and run
- **When using CCS projects to build**, import the CCS project and build it using the CCS project menu (see \ref CCS_PROJECTS_PAGE).
- **When using makefiles to build**, note the required combination and build using
make command (see \ref MAKEFILE_BUILD_PAGE)
- Launch a CCS debug session and run the executable, see \ref CCS_LAUNCH_PAGE
- Refer to UART terminal for user interface menu options.
### Sample Output
Shown below is a sample output when the application is run:
\imageStyle{Tamagawa_SampleOutput.JPG,width:60%}
\image html Tamagawa_SampleOutput.JPG "Tamagawa Sample Output"
### Test Case Description
<table>
<tr>
<th>Data_ID
<th>Name
<th>Description
<th>Pass/fail Criteria
</tr>
<tr>
<td>Data ID 0</td>
<td>Data readout (absolute position data)</td>
<td>In this command we will receive:
Absolute rotor position value in field name ABS..
Errors and warnings in field name SF(status field)
</td>
<td>CRC success with ABS, SF, CF and CRC values printed in the terminal.</td>
</tr>
<tr>
<td>Data ID 1</td>
<td>Data readout (multi-turn data)</td>
<td>In this command we will receive data about:
No. of rotor turns in field name ABM.
Errors and warnings in field name SF(status field).
</td>
<td>CRC success with ABM, SF, CF and CRC values printed in the terminal.</td>
</tr>
<tr>
<td>Data ID 2</td>
<td>Endoder-ID</td>
<td>In this command we will receive data about :
Tamagawa encoder make-ID in ENID field .
Errors and warnings in field name SF(status field)
</td>
<td>CRC success with ENID, SF, CF and CRC values printed in the terminal.</td>
</tr>
<tr>
<td>Data ID 3</td>
<td>Data readout(absolute+multiturn+encoder-ID)</td>
<td>In this command we will receive :
Absolute rotor position value in field name ABS.
No. of rotor turns in field name ABM.
Tamagawa encoder make-ID in ENID field .
Errors and warnings in field name SF(status field)
Other warnings in field name ALMC
</td>
<td>CRC success with ABS, ENID, ABM, ALMC, SF, CF and CRC values printed in the terminal.</td>
</tr>
<tr>
<td>Data ID 6</td>
<td>Writing to EEPROM</td>
<td>In this command you provide :
Proper address of the EEPROM where you want to write
Proper data that you want to write.<br>
As a response you recieve:
Control Field for EEPROM Write command
EEPROM address that you want to write to
Data that you want to write to the EEPROM
CRC value
</td>
<td>CRC success with EDF, ADF, CF and CRC values printed in the terminal.</td>
</tr>
<tr>
<td>Data ID D</td>
<td>Readout from EEPROM</td>
<td>In this command you provide :
Proper address of the EEPROM that you want to read.<br>
As a response you recieve:
Control Field for EEPROM Write command
EEPROM address that you want to write to
Data that you want to write to the EEPROM
CRC value
</td>
<td>CRC success with EDF, ADF, CF and CRC values printed in the terminal.</td>
</tr>
<tr>
<td>Data ID 7</td>
<td>Reset-Error</td>
<td>This command used to reset errors. </td>
<td>CRC success with ABS, SF, CF and CRC values printed in the terminal.</td>
</tr>
<tr>
<td>Data ID 8</td>
<td>Reset- absolute</td>
<td>This command used to reset absolute position data(ABS) </td>
<td>CRC success with ABS, SF, CF and CRC values printed in the terminal.</td>
</tr> <tr>
<td>Data ID C</td>
<td>Reset- multiturn</td>
<td>This command used to reset multi-turn data(ABM) </td>
<td>CRC success with ABS, SF, CF and CRC values printed in the terminal.</td>
</tr>
</table>

191
docs_src/docs/api_guide/examples/motorcontrol/tamagawa_uart_example.md Normal file
View File

@ -0,0 +1,191 @@
# Tamagawa over Uart Example {#EXAMPLE_MOTORCONTROL_TAMAGAWA_OVER_UART}
[TOC]
## Introduction
Tamagawa over uart application does below,
- Configures pinmux, GPIO, UART (UART clock to 192MHz, Baud rate, etc.)
- Initializes UART0 for debug log & UART1 for communication
- Load and executes tamagawa example on R5_0
Connect the Tamagawa encoder via RS-485 Half-Duplex EVM to Am263x-LP.
The connections between AM263x LP and RS-485
UART RX Pin(UART1_RXD)->JMP1-R,
UART TX Pin(UART1_TXD)->JMP4-D,
GPIO Pin(GPIO62)->JM3-DE
The tamagawa over uart example runs on R5 and communicates with tamagawa encoder by UART1. It presents the user with menu options to select Data ID code (as defined by Tamagawa) to be sent to the encoder. The application collects the data entered by the user and configures the relevant command. Then via the UART1 write API, the command is passed to encoder. Once the command is sent, the encoder starts to respond, and UART1 read API starts to read this response. Response is stored in the tamagawa interface, the status of the transaction is check by CRC calculation. If the status indicates success, the result is presented to the user otherwise print CRC failure.
### Example Flow-Chart
\image html Tamagawa_uart_flow_chart.png "Tamagawa UART example flow-chart"
## Important files and directory structure
<table>
<tr>
<th>Folder/Files
<th>Description
</tr>
<tr><td colspan="2" bgcolor=#F0F0F0> ${SDK_INSTALL_PATH}/examples/motor_control/tamagawa_diagnostic_over_soc_uart/uart_tamagawa.c</td></tr>
<tr>
<td>uart_tamagawa.c</td>
<td>Tamagawa UART application</td>
</tr>
<tr><td colspan="2" bgcolor=#F0F0F0> ${SDK_INSTALL_PATH}/source/position_sense/tamagawa_over_soc_uart</td></tr>
<tr>
<td>include/</td>
<td>Folder containing tamagawa interface file.</td>
</tr>
<tr>
<td>driver/</td>
<td>Tamagawa Uart driver.</td>
</tr>
</table>
# Supported Combinations
\cond SOC_AM263X
Parameter | Value
---------------|-----------
CPU + OS | r5fss0-0 freertos
Toolchain | ti-arm-clang
Board | @VAR_LP_BOARD_NAME_LOWER
Example folder | examples/motor_control/tamagawa_diagnostic_over_soc_uart
\endcond
# Steps to Run the Example
## Hardware Prerequisites
- Tamagawa Encoders
- AM263x LP
- RS-485 Half Duplex EVM
- 5V and 3.3V power supplier
## Hardware Setup
\imageStyle{Tamagawa_Uart_Hw_Setup.PNG,width:60%}
\image html Tamagawa_Uart_Hw_Setup.PNG "Tamagawa Encoder Hardware Setup with AM263x"
\imageStyle{Tamagawa_Setup_image.jpg,width:60%}
\image html Tamagawa_Setup_image.jpg "Hardware Setup For AM263x-LP"
## Build, load and run
- **When using CCS projects to build**, import the CCS project and build it using the CCS project menu (see \ref CCS_PROJECTS_PAGE).
- **When using makefiles to build**, note the required combination and build using
make command (see \ref MAKEFILE_BUILD_PAGE)
- Launch a CCS debug session and run the executable, see \ref CCS_LAUNCH_PAGE
- Refer to UART terminal for user interface menu options.
### Sample Output
Shown below is a sample output when the application is run:
\imageStyle{Tamagawa_UART_output.PNG,width:60%}
\image html Tamagawa_UART_output.PNG "Tamagawa UART Sample Output"
### Test Case Description
<table>
<tr>
<th>Data_ID
<th>Name
<th>Description
<th>Pass/fail Criteria
</tr>
<tr>
<td>Data ID 0</td>
<td>Data readout (absolute position data)</td>
<td>In this command we will receive:
Absolute rotor position value in field name ABS.
Errors and warnings in field name SF(status field)
</td>
<td>CRC success with ABS, SF, CF and CRC values printed in the terminal.</td>
</tr>
<tr>
<td>Data ID 1</td>
<td>Data readout (multi-turn data)</td>
<td>In this command we will receive data about:
No. of rotor turns in field name ABM.
Errors and warnings in field name SF(status field).
</td>
<td>CRC success with ABM, SF, CF and CRC values printed in the terminal.</td>
</tr>
<tr>
<td>Data ID 2</td>
<td>Endoder-ID</td>
<td>In this command we will receive data about :
Tamagawa encoder make-ID in ENID field.
Errors and warnings in field name SF(status field)
</td>
<td>CRC success with ENID, SF, CF and CRC values printed in the terminal.</td>
</tr>
<tr>
<td>Data ID 3</td>
<td>Data readout(absolute+multiturn+encoder-ID)</td>
<td>In this command we will receive :
Absolute rotor position value in field name ABS.
No. of rotor turns in field name ABM.
Tamagawa encoder make-ID in ENID field.
Errors and warnings in field name SF(status field)
Other warnings in field name ALMC
</td>
<td>CRC success with ABS, ENID, ABM, ALMC, SF, CF and CRC values printed in the terminal.</td>
</tr>
<tr>
<td>Data ID 6</td>
<td>Writing to EEPROM</td>
<td>In this command you provide :
Proper address of the EEPROM where you want to write
Proper data that you want to write.<br>
As a response you recieve:
Control Field for EEPROM Write command
EEPROM address that you want to write to
Data that you want to write to the EEPROM
CRC value
</td>
<td>CRC success with EDF, ADF, CF and CRC values printed in the terminal.</td>
</tr>
<tr>
<td>Data ID D</td>
<td>Readout from EEPROM</td>
<td>In this command you provide :
Proper address of the EEPROM that you want to read.<br>
As a response you recieve:
Control Field for EEPROM Write command
EEPROM address that you want to write to
Data that you want to write to the EEPROM
CRC value
</td>
<td>CRC success with EDF, ADF, CF and CRC values printed in the terminal.</td>
</tr>
<tr>
<td>Data ID 7</td>
<td>Reset-Error</td>
<td>This command used to reset errors. </td>
<td>CRC success with ABS, SF, CF and CRC values printed in the terminal.</td>
</tr>
<tr>
<td>Data ID 8</td>
<td>Reset- absolute</td>
<td>This command used to reset absolute position data(ABS) </td>
<td>CRC success with ABS, SF, CF and CRC values printed in the terminal.</td>
</tr> <tr>
<td>Data ID C</td>
<td>Reset- multiturn</td>
<td>This command used to reset multi-turn data(ABM) </td>
<td>CRC success with ABS, SF, CF and CRC values printed in the terminal.</td>
</tr>
</table>

BIN
docs_src/docs/api_guide/images/block_diagram.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 69 KiB

BIN
docs_src/docs/api_guide/images/images.pptx Normal file
View File

Binary file not shown.

BIN
docs_src/docs/api_guide/images/motorcontrol/EnDAT_Connections.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 3.4 MiB

BIN
docs_src/docs/api_guide/images/motorcontrol/EnDAT_Initialization_UART_PRINT.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 46 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/EnDat_Booster_Pack.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 506 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/EnDat_channel_selection_In_sysconfig.PNG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 24 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/Endat_Example_Implementation.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 61 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/Endat_Load_share_receive.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 18 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/Endat_RT_FlowChart_for_position.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 28 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/Endat_RT_FlowChart_for_supplement.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 38 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/Endat_Recovery_Time_For_Position.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 52 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/Endat_Recovery_Time_For_Supplement.PNG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 55 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/Endat_channel_selection_configuration.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 20 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/Endat_load_share_mode.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 19 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/HDSL_AM64xE1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.7 MiB

BIN
docs_src/docs/api_guide/images/motorcontrol/HDSL_Booster_Pack.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.2 MiB

BIN
docs_src/docs/api_guide/images/motorcontrol/HDSL_Connections.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 450 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/HDSL_Normal.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 15 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/HDSL_SYNC.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 22 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/OOB_Demo_DDRInit.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 173 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/OOB_GUI_root.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 106 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/OOB_GUI_stats.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 75 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/OOB_Linux_ifconfig.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 55 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/OOB_SW_arch.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 47 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/SDFM_EXAMPLE_FLOWCHART.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 218 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/SDFM_FIRMWARE_FLOWCHART.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 350 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/SDFM_HwSetup_image.PNG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 956 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/SDFM_sample_output.PNG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 11 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/SDFM_threshold_comparator_salea_capture.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 28 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/Tamagawa_Booster_Pack.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.3 MiB

BIN
docs_src/docs/api_guide/images/motorcontrol/Tamagawa_SampleOutput.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 265 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/Tamagawa_Setup_am243x_lp.jpeg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.7 MiB

BIN
docs_src/docs/api_guide/images/motorcontrol/Tamagawa_Setup_image.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 2.0 MiB

BIN
docs_src/docs/api_guide/images/motorcontrol/Tamagawa_SysConfig.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 505 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/Tamagawa_UART_output.PNG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 9.8 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/Tamagawa_Uart_Hw_Setup.PNG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 50 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/Tamagawa_connections.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 90 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/Tamagawa_eeprom_write_flow_chart.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 46 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/Tamagawa_flowchart.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 21 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/Tamagawa_initialization_flow_chart.JPG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 18 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/Tamagawa_parse_data.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 8.1 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/Tamagawa_rx_flow_chart.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 159 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/Tamagawa_setup.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 671 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/Tamagawa_setup_tx_data.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 55 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/Tamagawa_tx_flow_chart.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 29 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/Tamagawa_uart_flow_chart.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 42 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/Tamagawa_verify_crc.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 20 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/Threshold_comparator_flow.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 271 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/endat_2_2_supplement_send.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 61 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/endat_continuous_mode.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 91 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/endat_initialization.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 48 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/endat_load_share_mode_initialization.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 51 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/endat_module_integration.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 8.5 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/endat_on_fly_downsampling.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 178 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/endat_overall_block_diagram.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 128 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/endat_receive.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 150 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/endat_receive_downsampling.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 202 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/endat_send.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 37 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/endat_send_receive.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 45 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/hdsl_ddr_trace.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 33 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/hdsl_ddr_uart.PNG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 26 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/hdsl_default_uart_menu.PNG Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 165 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/hdsl_delta_pos.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 22 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/hdsl_external_sync.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 41 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/hdsl_external_sync_sample_edge.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 24 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/hdsl_layer_model.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 41 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/hdsl_loading_fw.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 71 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/hdsl_rssi.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 10 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/hdsl_sampling.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 19 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/hdsl_state_machine.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 43 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/hdsl_sync_algo.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 53 KiB

BIN
docs_src/docs/api_guide/images/motorcontrol/hdsl_test_pattern.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 9.0 KiB

Some files were not shown because too many files have changed in this diff Show More