diff --git a/docs_src/docs/api_guide/components/motor_control/endat.md b/docs_src/docs/api_guide/components/motor_control/endat.md new file mode 100644 index 0000000..2ee017e --- /dev/null +++ b/docs_src/docs/api_guide/components/motor_control/endat.md @@ -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 + diff --git a/docs_src/docs/api_guide/components/motor_control/endat_design.md b/docs_src/docs/api_guide/components/motor_control/endat_design.md new file mode 100644 index 0000000..4b8744f --- /dev/null +++ b/docs_src/docs/api_guide/components/motor_control/endat_design.md @@ -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 + + + + + + + + + + + + + + + + +
Parameter + Value + Details +
Maximum Cable Length + 100m + Supports up-to 8MHz with delay compensation +
Maximum Frequency + 16 MHz + Supports up-to 20m cable +
Startup/Initialization Frequency + 200 KHz + After power on or reset +
Frequencies supported + Upto 8 MHz + Changeable at run-time +
CRC + 6 bits + Position/data verification +
Receive oversample ratio + 8 + +
+ +### 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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Pin name + Signal name + Function +
PRG0_PRU1_GPO0 + pru1_endat0_clk + Channel 0 clock +
PRG0_PRU1_GPO1 + pru1_endat0_out + Channel 0 transmit +
PRG0_PRU1_GPO2 + pru1_endat0_outen + Channel 0 transmit enable +
PRG0_PRU1_GPI13 + pru1_endat0_in + Channel 0 receive +
PRG0_PRU1_GPO3 + pru1_endat1_clk + Channel 1 clock +
PRG0_PRU1_GPO4 + pru1_endat1_out + Channel 1 transmit +
PRG0_PRU1_GPO5 + pru1_endat1_outen + Channel 1 transmit enable +
PRG0_PRU1_GPI14 + pru1_endat1_in + Channel 1 receive +
PRG0_PRU1_GPO6 + pru1_endat2_clk + Channel 2 clock +
PRG0_PRU1_GPO12 + pru1_endat2_out + Channel 2 transmit +
PRG0_PRU1_GPO8 + pru1_endat2_outen + Channel 2 transmit enable +
PRG0_PRU1_GPI11 + pru1_endat2_in + Channel 2 receive +
GPIO42 + endat_en + Onboard RS485 receive enable +
+\cond SOC_AM243X +##### AM243x-LP Booster Pack Pin-Multiplexing + + + + + + + + + + + + + +
Pin name + Signal name + Function +
PRG0_PRU1_GPO0 + pru1_endat0_clk + Channel 0 clock +
PRG0_PRU1_GPO1 + pru1_endat0_out + Channel 0 transmit +
PRG0_PRU1_GPO2 + pru1_endat0_outen + Channel 0 transmit enable +
PRG0_PRU1_GPI13 + pru1_endat0_in + Channel 0 receive +
GPIO Pin(GPIO1_78) + ENC1_EN + Enbale endat mode in Axis 1 of BP (C16 GPIO pin) +
+\endcond \ No newline at end of file diff --git a/docs_src/docs/api_guide/components/motor_control/hdsl.md b/docs_src/docs/api_guide/components/motor_control/hdsl.md new file mode 100644 index 0000000..6715e09 --- /dev/null +++ b/docs_src/docs/api_guide/components/motor_control/hdsl.md @@ -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 \ No newline at end of file diff --git a/docs_src/docs/api_guide/components/motor_control/hdsl_design.md b/docs_src/docs/api_guide/components/motor_control/hdsl_design.md new file mode 100644 index 0000000..288cf57 --- /dev/null +++ b/docs_src/docs/api_guide/components/motor_control/hdsl_design.md @@ -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. + diff --git a/docs_src/docs/api_guide/components/motor_control/motor_control.md b/docs_src/docs/api_guide/components/motor_control/motor_control.md new file mode 100644 index 0000000..7c84c37 --- /dev/null +++ b/docs_src/docs/api_guide/components/motor_control/motor_control.md @@ -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 \ No newline at end of file diff --git a/docs_src/docs/api_guide/components/motor_control/motor_control_am263x.cfg b/docs_src/docs/api_guide/components/motor_control/motor_control_am263x.cfg new file mode 100644 index 0000000..529dcd2 --- /dev/null +++ b/docs_src/docs/api_guide/components/motor_control/motor_control_am263x.cfg @@ -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 \ No newline at end of file diff --git a/docs_src/docs/api_guide/components/motor_control/motor_control_am64x_am243x.cfg b/docs_src/docs/api_guide/components/motor_control/motor_control_am64x_am243x.cfg new file mode 100644 index 0000000..4309c4d --- /dev/null +++ b/docs_src/docs/api_guide/components/motor_control/motor_control_am64x_am243x.cfg @@ -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 diff --git a/docs_src/docs/api_guide/components/motor_control/sdfm.md b/docs_src/docs/api_guide/components/motor_control/sdfm.md new file mode 100644 index 0000000..ec51bd9 --- /dev/null +++ b/docs_src/docs/api_guide/components/motor_control/sdfm.md @@ -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 diff --git a/docs_src/docs/api_guide/components/motor_control/sdfm_design.md b/docs_src/docs/api_guide/components/motor_control/sdfm_design.md new file mode 100644 index 0000000..5d24dd0 --- /dev/null +++ b/docs_src/docs/api_guide/components/motor_control/sdfm_design.md @@ -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 + + + + + + + + + + + + + + +
Parameter + Value + Details +
Normal current OSR + 32 + Tested with 32, 64, 128 & 256 +
Over current OSR + 64 + Tested with 32, 64, 128 & 256 +
Sigma Delta Modulator Clock + 20 MHz + +
Simulated EPWM frequency + 8 KHz + Tested up to 20KHz +
IEP frequency + 300MHz + +
+ +### 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 + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Pin name + Signal name + Function +
GPIO_HIGH_TH_CH0 + MCU_SPI0_D1/B6 + Ch0 High threshold output +
GPIO_LOW_TH_CH0 + MCU_SPI1_D0/C7 + Ch0 low threshold output +
GPIO_HIGH_TH_CH1 + MCU_SPI1_CS0/A7 + Ch1 High threshold output +
GPIO_LOW_TH_CH1 + MCU_SPI1_CLK/D7 + Ch1 low threshold output +
GPIO_HIGH_TH_CH2 + MCU_SPI1_D1/C8 + Ch2 High threshold output +
GPIO_LOW_TH_CH2 + MCU_SPI0_CLK/E6 + Ch2 Low threshold output +
SD0_D + PIN_PRG0_PRU0_GPO1 + Channel0 data input +
SD1_D + PIN_PRG0_PRU0_GPO3 + Channel1 data input +
SD2_D + PIN_PRG0_PRU0_GPO5 + Channel2 data input +
PRG0_ECAP0_IN_APWM_OUT + PIN_PRG0_PRU1_GPO15 + +
GPIO_MTR_1_PWM_EN + GPMC0_AD15/Y20 + +
SD8_CLK + PIN_PRG0_PRU0_GPO16 + SDFM clock input pin +
\ No newline at end of file diff --git a/docs_src/docs/api_guide/components/motor_control/tamagawa.md b/docs_src/docs/api_guide/components/motor_control/tamagawa.md new file mode 100644 index 0000000..4f76713 --- /dev/null +++ b/docs_src/docs/api_guide/components/motor_control/tamagawa.md @@ -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 diff --git a/docs_src/docs/api_guide/components/motor_control/tamagawa_design.md b/docs_src/docs/api_guide/components/motor_control/tamagawa_design.md new file mode 100644 index 0000000..844a70c --- /dev/null +++ b/docs_src/docs/api_guide/components/motor_control/tamagawa_design.md @@ -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" + diff --git a/docs_src/docs/api_guide/components/motor_control/tamagawa_uart.md b/docs_src/docs/api_guide/components/motor_control/tamagawa_uart.md new file mode 100644 index 0000000..f3b9994 --- /dev/null +++ b/docs_src/docs/api_guide/components/motor_control/tamagawa_uart.md @@ -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 diff --git a/docs_src/docs/api_guide/device/am64x/examples.cfg b/docs_src/docs/api_guide/device/am64x/examples.cfg new file mode 100644 index 0000000..4be944f --- /dev/null +++ b/docs_src/docs/api_guide/device/am64x/examples.cfg @@ -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 diff --git a/docs_src/docs/api_guide/device/am64x/includes.cfg b/docs_src/docs/api_guide/device/am64x/includes.cfg new file mode 100644 index 0000000..e7f4a04 --- /dev/null +++ b/docs_src/docs/api_guide/device/am64x/includes.cfg @@ -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" diff --git a/docs_src/docs/api_guide/doxy_warnings_am243x.txt b/docs_src/docs/api_guide/doxy_warnings_am243x.txt new file mode 100644 index 0000000..e69de29 diff --git a/docs_src/docs/api_guide/doxy_warnings_am263x.txt b/docs_src/docs/api_guide/doxy_warnings_am263x.txt new file mode 100644 index 0000000..e69de29 diff --git a/docs_src/docs/api_guide/doxy_warnings_am64x.txt b/docs_src/docs/api_guide/doxy_warnings_am64x.txt new file mode 100644 index 0000000..c8c1658 --- /dev/null +++ b/docs_src/docs/api_guide/doxy_warnings_am64x.txt @@ -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. diff --git a/docs_src/docs/api_guide/doxygen.cfg b/docs_src/docs/api_guide/doxygen.cfg new file mode 100644 index 0000000..35d3887 --- /dev/null +++ b/docs_src/docs/api_guide/doxygen.cfg @@ -0,0 +1,2301 @@ +# Doxyfile 1.8.6 + +# This file describes the settings to be used by the documentation system +# doxygen (www.doxygen.org) for a project. +# +# All text after a double hash (##) is considered a comment and is placed in +# front of the TAG it is preceding. +# +# All text after a single hash (#) is considered a comment and will be ignored. +# The format is: +# TAG = value [value, ...] +# For lists, items can also be appended using: +# TAG += value [value, ...] +# Values that contain spaces should be placed between quotes (\" \"). + +#--------------------------------------------------------------------------- +# Project related configuration options +#--------------------------------------------------------------------------- + +# The PROJECT_NUMBER tag can be used to enter a project or revision number. This +# could be handy for archiving the generated documentation or if some version +# control system is used. + +PROJECT_NUMBER = 08.04.00 + +# Using the PROJECT_BRIEF tag one can provide an optional one line description +# for a project that appears at the top of each page and should give viewer a +# quick idea about the purpose of the project. Keep the description short. + +PROJECT_BRIEF = + +# This tag specifies the encoding used for all characters in the config file +# that follow. The default is UTF-8 which is also the encoding used for all text +# before the first occurrence of this tag. Doxygen uses libiconv (or the iconv +# built into libc) for the transcoding. See http://www.gnu.org/software/libiconv +# for the list of possible encodings. +# The default value is: UTF-8. + +DOXYFILE_ENCODING = UTF-8 + + +# With the PROJECT_LOGO tag one can specify an logo or icon that is included in +# the documentation. The maximum height of the logo should not exceed 55 pixels +# and the maximum width should not exceed 200 pixels. Doxygen will copy the logo +# to the output directory. + +PROJECT_LOGO = $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/theme/ti_logo.svg + +# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) path +# into which the generated documentation will be written. If a relative path is +# entered, it will be relative to the location where doxygen was started. If +# left blank the current directory will be used. + +OUTPUT_DIRECTORY = $(API_GUIDE_OUT_DIR) + +# If the CREATE_SUBDIRS tag is set to YES, then doxygen will create 4096 sub- +# directories (in 2 levels) under the output directory of each output format and +# will distribute the generated files over these directories. Enabling this +# option can be useful when feeding doxygen a huge amount of source files, where +# putting all generated files in the same directory would otherwise causes +# performance problems for the file system. +# The default value is: NO. + +CREATE_SUBDIRS = NO + +# The OUTPUT_LANGUAGE tag is used to specify the language in which all +# documentation generated by doxygen is written. Doxygen will use this +# information to generate all constant output in the proper language. +# Possible values are: Afrikaans, Arabic, Armenian, Brazilian, Catalan, Chinese, +# Chinese-Traditional, Croatian, Czech, Danish, Dutch, English (United States), +# Esperanto, Farsi (Persian), Finnish, French, German, Greek, Hungarian, +# Indonesian, Italian, Japanese, Japanese-en (Japanese with English messages), +# Korean, Korean-en (Korean with English messages), Latvian, Lithuanian, +# Macedonian, Norwegian, Persian (Farsi), Polish, Portuguese, Romanian, Russian, +# Serbian, Serbian-Cyrillic, Slovak, Slovene, Spanish, Swedish, Turkish, +# Ukrainian and Vietnamese. +# The default value is: English. + +OUTPUT_LANGUAGE = English + +# If the BRIEF_MEMBER_DESC tag is set to YES doxygen will include brief member +# descriptions after the members that are listed in the file and class +# documentation (similar to Javadoc). Set to NO to disable this. +# The default value is: YES. + +BRIEF_MEMBER_DESC = YES + +# If the REPEAT_BRIEF tag is set to YES doxygen will prepend the brief +# description of a member or function before the detailed description +# +# Note: If both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the +# brief descriptions will be completely suppressed. +# The default value is: YES. + +REPEAT_BRIEF = YES + +# This tag implements a quasi-intelligent brief description abbreviator that is +# used to form the text in various listings. Each string in this list, if found +# as the leading text of the brief description, will be stripped from the text +# and the result, after processing the whole list, is used as the annotated +# text. Otherwise, the brief description is used as-is. If left blank, the +# following values are used ($name is automatically replaced with the name of +# the entity):The $name class, The $name widget, The $name file, is, provides, +# specifies, contains, represents, a, an and the. + +ABBREVIATE_BRIEF = NO + +# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then +# doxygen will generate a detailed section even if there is only a brief +# description. +# The default value is: NO. + +ALWAYS_DETAILED_SEC = NO + +# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all +# inherited members of a class in the documentation of that class as if those +# members were ordinary class members. Constructors, destructors and assignment +# operators of the base classes will not be shown. +# The default value is: NO. + +INLINE_INHERITED_MEMB = YES + +# If the FULL_PATH_NAMES tag is set to YES doxygen will prepend the full path +# before files name in the file list and in the header files. If set to NO the +# shortest path that makes the file name unique will be used +# The default value is: YES. + +FULL_PATH_NAMES = NO + +# The STRIP_FROM_PATH tag can be used to strip a user-defined part of the path. +# Stripping is only done if one of the specified strings matches the left-hand +# part of the path. The tag can be used to show relative paths in the file list. +# If left blank the directory from which doxygen is run is used as the path to +# strip. +# +# Note that you can specify absolute paths here, but also relative paths, which +# will be relative from the directory where doxygen is started. +# This tag requires that the tag FULL_PATH_NAMES is set to YES. + +STRIP_FROM_PATH = + +# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of the +# path mentioned in the documentation of a class, which tells the reader which +# header file to include in order to use a class. If left blank only the name of +# the header file containing the class definition is used. Otherwise one should +# specify the list of include paths that are normally passed to the compiler +# using the -I flag. + +STRIP_FROM_INC_PATH = + +# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter (but +# less readable) file names. This can be useful is your file systems doesn't +# support long names like on DOS, Mac, or CD-ROM. +# The default value is: NO. + +SHORT_NAMES = NO + +# If the JAVADOC_AUTOBRIEF tag is set to YES then doxygen will interpret the +# first line (until the first dot) of a Javadoc-style comment as the brief +# description. If set to NO, the Javadoc-style will behave just like regular Qt- +# style comments (thus requiring an explicit @brief command for a brief +# description.) +# The default value is: NO. + +JAVADOC_AUTOBRIEF = NO + +# If the QT_AUTOBRIEF tag is set to YES then doxygen will interpret the first +# line (until the first dot) of a Qt-style comment as the brief description. If +# set to NO, the Qt-style will behave just like regular Qt-style comments (thus +# requiring an explicit \brief command for a brief description.) +# The default value is: NO. + +QT_AUTOBRIEF = NO + +# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make doxygen treat a +# multi-line C++ special comment block (i.e. a block of //! or /// comments) as +# a brief description. This used to be the default behavior. The new default is +# to treat a multi-line C++ comment block as a detailed description. Set this +# tag to YES if you prefer the old behavior instead. +# +# Note that setting this tag to YES also means that rational rose comments are +# not recognized any more. +# The default value is: NO. + +MULTILINE_CPP_IS_BRIEF = NO + +# If the INHERIT_DOCS tag is set to YES then an undocumented member inherits the +# documentation from any documented member that it re-implements. +# The default value is: YES. + +INHERIT_DOCS = YES + +# If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce a +# new page for each member. If set to NO, the documentation of a member will be +# part of the file/class/namespace that contains it. +# The default value is: NO. + +SEPARATE_MEMBER_PAGES = NO + +# The TAB_SIZE tag can be used to set the number of spaces in a tab. Doxygen +# uses this value to replace tabs by spaces in code fragments. +# Minimum value: 1, maximum value: 16, default value: 4. + +TAB_SIZE = 4 + +# This tag can be used to specify a number of aliases that act as commands in +# the documentation. An alias has the form: +# name=value +# For example adding +# "sideeffect=@par Side Effects:\n" +# will allow you to put the command \sideeffect (or @sideeffect) in the +# documentation, which will result in a user-defined paragraph with heading +# "Side Effects:". You can put \n's in the value part of an alias to insert +# newlines. + +ALIASES+=htmllink{2}="\2" +ALIASES+=imageStyle{2}="\htmlonly \endhtmlonly" +ALIASES+=inlineVideo{3}="\htmlonly

\2

\endhtmlonly" +ALIASES+=VAR_MY_NAME="my_value" +ALIASES+=VAR_TI_HOME_PAGE="\htmllink{https://www.ti.com,TI}" +ALIASES+=VAR_SDK_NAME="MCU+ SDK" +ALIASES+=VAR_CCS_VERSION="12.4.0" +ALIASES+=VAR_CCS_FOLDER_VERSION="1240" +ALIASES+=VAR_CCS_VERSION_AM263X="12.4.0" +ALIASES+=VAR_CCS_FOLDER_VERSION_AM263X="1240" +ALIASES+=VAR_SYSCFG_VERSION="1.17.0" +ALIASES+=VAR_SYSCFG_BUILD="3128" +ALIASES+=VAR_SYSCFG_VERSION_FULL="1.17.0_3128" +ALIASES+=VAR_SYSCFG_VERSION_AM273X="1.17.0" +ALIASES+=VAR_SYSCFG_BUILD_AM273X="3128" +ALIASES+=VAR_SYSCFG_VERSION_FULL_AM273X="1.17.0_3128" +ALIASES+=VAR_SYSCFG_VERSION_AM263X="1.17.0" +ALIASES+=VAR_SYSCFG_BUILD_AM263X="3128" +ALIASES+=VAR_SYSCFG_VERSION_FULL_AM263X="1.17.0_3128" +ALIASES+=VAR_TI_ARM_CLANG_VERSION="2.1.3.LTS" +ALIASES+=VAR_TI_C6000_CGT_VERSION="8.3.12" +ALIASES+=VAR_GCC_AARCH64_VERSION="9.2-2019.12" +ALIASES+=VAR_GCC_ARM_VERSION="7-2017-q4-major" +ALIASES+=VAR_FREERTOS_KERNEL_VERSION="10.4.3" +ALIASES+=VAR_FREERTOS_SMP_KERNEL_VERSION="202110.00-SMP" +ALIASES+=VAR_DSPLIB_VERSION="3.4.0.0" +ALIASES+=VAR_TINYUSB_VERSION="0.14.0" +ALIASES+=VAR_LWIP_VERSION="STABLE-2_1_2_RELEASE" +ALIASES+=VAR_SECURITY_MBEDTLS_VERSION="mbedtls-3.0.0" +ALIASES+=VAR_MBEDTLS_VERSION="mbedtls-2.13.1" +ALIASES+=VAR_SYSCFG_USAGE_NOTE="\note It is strongly recommend to use SysConfig where it is available instead of using direct SW API calls. This will help simplify the SW application and also catch common mistakes early in the development cycle." + +# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C sources +# only. Doxygen will then generate output that is more tailored for C. For +# instance, some of the names that are used will be different. The list of all +# members will be omitted, etc. +# The default value is: NO. + +OPTIMIZE_OUTPUT_FOR_C = YES + +# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java or +# Python sources only. Doxygen will then generate output that is more tailored +# for that language. For instance, namespaces will be presented as packages, +# qualified scopes will look different, etc. +# The default value is: NO. + +OPTIMIZE_OUTPUT_JAVA = NO + +# Set the OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran +# sources. Doxygen will then generate output that is tailored for Fortran. +# The default value is: NO. + +OPTIMIZE_FOR_FORTRAN = NO + +# Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL +# sources. Doxygen will then generate output that is tailored for VHDL. +# The default value is: NO. + +OPTIMIZE_OUTPUT_VHDL = NO + +# Doxygen selects the parser to use depending on the extension of the files it +# parses. With this tag you can assign which parser to use for a given +# extension. Doxygen has a built-in mapping, but you can override or extend it +# using this tag. The format is ext=language, where ext is a file extension, and +# language is one of the parsers supported by doxygen: IDL, Java, Javascript, +# C#, C, C++, D, PHP, Objective-C, Python, Fortran, VHDL. For instance to make +# doxygen treat .inc files as Fortran files (default is PHP), and .f files as C +# (default is Fortran), use: inc=Fortran f=C. +# +# Note For files without extension you can use no_extension as a placeholder. +# +# Note that for custom extensions you also need to set FILE_PATTERNS otherwise +# the files are not read by doxygen. + +EXTENSION_MAPPING = + +# If the MARKDOWN_SUPPORT tag is enabled then doxygen pre-processes all comments +# according to the Markdown format, which allows for more readable +# documentation. See http://daringfireball.net/projects/markdown/ for details. +# The output of markdown processing is further processed by doxygen, so you can +# mix doxygen, HTML, and XML commands with Markdown formatting. Disable only in +# case of backward compatibilities issues. +# The default value is: YES. + +MARKDOWN_SUPPORT = YES + +# When enabled doxygen tries to link words that correspond to documented +# classes, or namespaces to their corresponding documentation. Such a link can +# be prevented in individual cases by by putting a % sign in front of the word +# or globally by setting AUTOLINK_SUPPORT to NO. +# The default value is: YES. + +AUTOLINK_SUPPORT = YES + +# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want +# to include (a tag file for) the STL sources as input, then you should set this +# tag to YES in order to let doxygen match functions declarations and +# definitions whose arguments contain STL classes (e.g. func(std::string); +# versus func(std::string) {}). This also make the inheritance and collaboration +# diagrams that involve STL classes more complete and accurate. +# The default value is: NO. + +BUILTIN_STL_SUPPORT = NO + +# If you use Microsoft's C++/CLI language, you should set this option to YES to +# enable parsing support. +# The default value is: NO. + +CPP_CLI_SUPPORT = NO + +# Set the SIP_SUPPORT tag to YES if your project consists of sip (see: +# http://www.riverbankcomputing.co.uk/software/sip/intro) sources only. Doxygen +# will parse them like normal C++ but will assume all classes use public instead +# of private inheritance when no explicit protection keyword is present. +# The default value is: NO. + +SIP_SUPPORT = NO + +# For Microsoft's IDL there are propget and propput attributes to indicate +# getter and setter methods for a property. Setting this option to YES will make +# doxygen to replace the get and set methods by a property in the documentation. +# This will only work if the methods are indeed getting or setting a simple +# type. If this is not the case, or you want to show the methods anyway, you +# should set this option to NO. +# The default value is: YES. + +IDL_PROPERTY_SUPPORT = YES + +# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC +# tag is set to YES, then doxygen will reuse the documentation of the first +# member in the group (if any) for the other members of the group. By default +# all members of a group must be documented explicitly. +# The default value is: NO. + +DISTRIBUTE_GROUP_DOC = NO + +# Set the SUBGROUPING tag to YES to allow class member groups of the same type +# (for instance a group of public functions) to be put as a subgroup of that +# type (e.g. under the Public Functions section). Set it to NO to prevent +# subgrouping. Alternatively, this can be done per class using the +# \nosubgrouping command. +# The default value is: YES. + +SUBGROUPING = YES + +# When the INLINE_GROUPED_CLASSES tag is set to YES, classes, structs and unions +# are shown inside the group in which they are included (e.g. using \ingroup) +# instead of on a separate page (for HTML and Man pages) or section (for LaTeX +# and RTF). +# +# Note that this feature does not work in combination with +# SEPARATE_MEMBER_PAGES. +# The default value is: NO. + +INLINE_GROUPED_CLASSES = NO + +# When the INLINE_SIMPLE_STRUCTS tag is set to YES, structs, classes, and unions +# with only public data fields or simple typedef fields will be shown inline in +# the documentation of the scope in which they are defined (i.e. file, +# namespace, or group documentation), provided this scope is documented. If set +# to NO, structs, classes, and unions are shown on a separate page (for HTML and +# Man pages) or section (for LaTeX and RTF). +# The default value is: NO. + +INLINE_SIMPLE_STRUCTS = NO + +# When TYPEDEF_HIDES_STRUCT tag is enabled, a typedef of a struct, union, or +# enum is documented as struct, union, or enum with the name of the typedef. So +# typedef struct TypeS {} TypeT, will appear in the documentation as a struct +# with name TypeT. When disabled the typedef will appear as a member of a file, +# namespace, or class. And the struct will be named TypeS. This can typically be +# useful for C code in case the coding convention dictates that all compound +# types are typedef'ed and only the typedef is referenced, never the tag name. +# The default value is: NO. + +TYPEDEF_HIDES_STRUCT = YES + +# The size of the symbol lookup cache can be set using LOOKUP_CACHE_SIZE. This +# cache is used to resolve symbols given their name and scope. Since this can be +# an expensive process and often the same symbol appears multiple times in the +# code, doxygen keeps a cache of pre-resolved symbols. If the cache is too small +# doxygen will become slower. If the cache is too large, memory is wasted. The +# cache size is given by this formula: 2^(16+LOOKUP_CACHE_SIZE). The valid range +# is 0..9, the default is 0, corresponding to a cache size of 2^16=65536 +# symbols. At the end of a run doxygen will report the cache usage and suggest +# the optimal cache size from a speed point of view. +# Minimum value: 0, maximum value: 9, default value: 0. + +LOOKUP_CACHE_SIZE = 0 + +#--------------------------------------------------------------------------- +# Build related configuration options +#--------------------------------------------------------------------------- + +# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in +# documentation are documented, even if no documentation was available. Private +# class members and static file members will be hidden unless the +# EXTRACT_PRIVATE respectively EXTRACT_STATIC tags are set to YES. +# Note: This will also disable the warnings about undocumented members that are +# normally produced when WARNINGS is set to YES. +# The default value is: NO. + +EXTRACT_ALL = YES + +# If the EXTRACT_PRIVATE tag is set to YES all private members of a class will +# be included in the documentation. +# The default value is: NO. + +EXTRACT_PRIVATE = YES + +# If the EXTRACT_PACKAGE tag is set to YES all members with package or internal +# scope will be included in the documentation. +# The default value is: NO. + +EXTRACT_PACKAGE = NO + +# If the EXTRACT_STATIC tag is set to YES all static members of a file will be +# included in the documentation. +# The default value is: NO. + +EXTRACT_STATIC = YES + +# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs) defined +# locally in source files will be included in the documentation. If set to NO +# only classes defined in header files are included. Does not have any effect +# for Java sources. +# The default value is: YES. + +EXTRACT_LOCAL_CLASSES = YES + +# This flag is only useful for Objective-C code. When set to YES local methods, +# which are defined in the implementation section but not in the interface are +# included in the documentation. If set to NO only methods in the interface are +# included. +# The default value is: NO. + +EXTRACT_LOCAL_METHODS = YES + +# If this flag is set to YES, the members of anonymous namespaces will be +# extracted and appear in the documentation as a namespace called +# 'anonymous_namespace{file}', where file will be replaced with the base name of +# the file that contains the anonymous namespace. By default anonymous namespace +# are hidden. +# The default value is: NO. + +EXTRACT_ANON_NSPACES = YES + +# If the HIDE_UNDOC_MEMBERS tag is set to YES, doxygen will hide all +# undocumented members inside documented classes or files. If set to NO these +# members will be included in the various overviews, but no documentation +# section is generated. This option has no effect if EXTRACT_ALL is enabled. +# The default value is: NO. + +HIDE_UNDOC_MEMBERS = NO + +# If the HIDE_UNDOC_CLASSES tag is set to YES, doxygen will hide all +# undocumented classes that are normally visible in the class hierarchy. If set +# to NO these classes will be included in the various overviews. This option has +# no effect if EXTRACT_ALL is enabled. +# The default value is: NO. + +HIDE_UNDOC_CLASSES = NO + +# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, doxygen will hide all friend +# (class|struct|union) declarations. If set to NO these declarations will be +# included in the documentation. +# The default value is: NO. + +HIDE_FRIEND_COMPOUNDS = NO + +# If the HIDE_IN_BODY_DOCS tag is set to YES, doxygen will hide any +# documentation blocks found inside the body of a function. If set to NO these +# blocks will be appended to the function's detailed documentation block. +# The default value is: NO. + +HIDE_IN_BODY_DOCS = NO + +# The INTERNAL_DOCS tag determines if documentation that is typed after a +# \internal command is included. If the tag is set to NO then the documentation +# will be excluded. Set it to YES to include the internal documentation. +# The default value is: NO. + +INTERNAL_DOCS = NO + +# If the CASE_SENSE_NAMES tag is set to NO then doxygen will only generate file +# names in lower-case letters. If set to YES upper-case letters are also +# allowed. This is useful if you have classes or files whose names only differ +# in case and if your file system supports case sensitive file names. Windows +# and Mac users are advised to set this option to NO. +# The default value is: system dependent. + +CASE_SENSE_NAMES = YES + +# If the HIDE_SCOPE_NAMES tag is set to NO then doxygen will show members with +# their full class and namespace scopes in the documentation. If set to YES the +# scope will be hidden. +# The default value is: NO. + +HIDE_SCOPE_NAMES = NO + +# If the SHOW_INCLUDE_FILES tag is set to YES then doxygen will put a list of +# the files that are included by a file in the documentation of that file. +# The default value is: YES. + +SHOW_INCLUDE_FILES = YES + +# If the SHOW_GROUPED_MEMB_INC tag is set to YES then Doxygen will add for each +# grouped member an include statement to the documentation, telling the reader +# which file to include in order to use the member. +# The default value is: NO. + +SHOW_GROUPED_MEMB_INC = NO + +# If the FORCE_LOCAL_INCLUDES tag is set to YES then doxygen will list include +# files with double quotes in the documentation rather than with sharp brackets. +# The default value is: NO. + +FORCE_LOCAL_INCLUDES = NO + +# If the INLINE_INFO tag is set to YES then a tag [inline] is inserted in the +# documentation for inline members. +# The default value is: YES. + +INLINE_INFO = YES + +# If the SORT_MEMBER_DOCS tag is set to YES then doxygen will sort the +# (detailed) documentation of file and class members alphabetically by member +# name. If set to NO the members will appear in declaration order. +# The default value is: YES. + +SORT_MEMBER_DOCS = NO + +# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the brief +# descriptions of file, namespace and class members alphabetically by member +# name. If set to NO the members will appear in declaration order. Note that +# this will also influence the order of the classes in the class list. +# The default value is: NO. + +SORT_BRIEF_DOCS = NO + +# If the SORT_MEMBERS_CTORS_1ST tag is set to YES then doxygen will sort the +# (brief and detailed) documentation of class members so that constructors and +# destructors are listed first. If set to NO the constructors will appear in the +# respective orders defined by SORT_BRIEF_DOCS and SORT_MEMBER_DOCS. +# Note: If SORT_BRIEF_DOCS is set to NO this option is ignored for sorting brief +# member documentation. +# Note: If SORT_MEMBER_DOCS is set to NO this option is ignored for sorting +# detailed member documentation. +# The default value is: NO. + +SORT_MEMBERS_CTORS_1ST = NO + +# If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the hierarchy +# of group names into alphabetical order. If set to NO the group names will +# appear in their defined order. +# The default value is: NO. + +SORT_GROUP_NAMES = YES + +# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be sorted by +# fully-qualified names, including namespaces. If set to NO, the class list will +# be sorted only by class name, not including the namespace part. +# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES. +# Note: This option applies only to the class list, not to the alphabetical +# list. +# The default value is: NO. + +SORT_BY_SCOPE_NAME = NO + +# If the STRICT_PROTO_MATCHING option is enabled and doxygen fails to do proper +# type resolution of all parameters of a function it will reject a match between +# the prototype and the implementation of a member function even if there is +# only one candidate or it is obvious which candidate to choose by doing a +# simple string match. By disabling STRICT_PROTO_MATCHING doxygen will still +# accept a match between prototype and implementation in such cases. +# The default value is: NO. + +STRICT_PROTO_MATCHING = NO + +# The GENERATE_TODOLIST tag can be used to enable ( YES) or disable ( NO) the +# todo list. This list is created by putting \todo commands in the +# documentation. +# The default value is: YES. + +GENERATE_TODOLIST = YES + +# The GENERATE_TESTLIST tag can be used to enable ( YES) or disable ( NO) the +# test list. This list is created by putting \test commands in the +# documentation. +# The default value is: YES. + +GENERATE_TESTLIST = YES + +# The GENERATE_BUGLIST tag can be used to enable ( YES) or disable ( NO) the bug +# list. This list is created by putting \bug commands in the documentation. +# The default value is: YES. + +GENERATE_BUGLIST = YES + +# The GENERATE_DEPRECATEDLIST tag can be used to enable ( YES) or disable ( NO) +# the deprecated list. This list is created by putting \deprecated commands in +# the documentation. +# The default value is: YES. + +GENERATE_DEPRECATEDLIST= YES + +# The ENABLED_SECTIONS tag can be used to enable conditional documentation +# sections, marked by \if ... \endif and \cond +# ... \endcond blocks. + +ENABLED_SECTIONS = + +# The MAX_INITIALIZER_LINES tag determines the maximum number of lines that the +# initial value of a variable or macro / define can have for it to appear in the +# documentation. If the initializer consists of more lines than specified here +# it will be hidden. Use a value of 0 to hide initializers completely. The +# appearance of the value of individual variables and macros / defines can be +# controlled using \showinitializer or \hideinitializer command in the +# documentation regardless of this setting. +# Minimum value: 0, maximum value: 10000, default value: 30. + +MAX_INITIALIZER_LINES = 30 + +# Set the SHOW_USED_FILES tag to NO to disable the list of files generated at +# the bottom of the documentation of classes and structs. If set to YES the list +# will mention the files that were used to generate the documentation. +# The default value is: YES. + +SHOW_USED_FILES = YES + +# Set the SHOW_FILES tag to NO to disable the generation of the Files page. This +# will remove the Files entry from the Quick Index and from the Folder Tree View +# (if specified). +# The default value is: YES. + +SHOW_FILES = YES + +# Set the SHOW_NAMESPACES tag to NO to disable the generation of the Namespaces +# page. This will remove the Namespaces entry from the Quick Index and from the +# Folder Tree View (if specified). +# The default value is: YES. + +SHOW_NAMESPACES = YES + +# The FILE_VERSION_FILTER tag can be used to specify a program or script that +# doxygen should invoke to get the current version for each file (typically from +# the version control system). Doxygen will invoke the program by executing (via +# popen()) the command command input-file, where command is the value of the +# FILE_VERSION_FILTER tag, and input-file is the name of an input file provided +# by doxygen. Whatever the program writes to standard output is used as the file +# version. For an example see the documentation. + +FILE_VERSION_FILTER = + +# The LAYOUT_FILE tag can be used to specify a layout file which will be parsed +# by doxygen. The layout file controls the global structure of the generated +# output files in an output format independent way. To create the layout file +# that represents doxygen's defaults, run doxygen with the -l option. You can +# optionally specify a file name after the option, if omitted DoxygenLayout.xml +# will be used as the name of the layout file. +# +# Note that if you run doxygen from a directory containing a file called +# DoxygenLayout.xml, doxygen will parse it automatically even if the LAYOUT_FILE +# tag is left empty. + +LAYOUT_FILE = $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/theme/layout.xml + +# The CITE_BIB_FILES tag can be used to specify one or more bib files containing +# the reference definitions. This must be a list of .bib files. The .bib +# extension is automatically appended if omitted. This requires the bibtex tool +# to be installed. See also http://en.wikipedia.org/wiki/BibTeX for more info. +# For LaTeX the style of the bibliography can be controlled using +# LATEX_BIB_STYLE. To use this feature you need bibtex and perl available in the +# search path. Do not use file names with spaces, bibtex cannot handle them. See +# also \cite for info how to create references. + +CITE_BIB_FILES = + +#--------------------------------------------------------------------------- +# Configuration options related to warning and progress messages +#--------------------------------------------------------------------------- + +# The QUIET tag can be used to turn on/off the messages that are generated to +# standard output by doxygen. If QUIET is set to YES this implies that the +# messages are off. +# The default value is: NO. + +QUIET = NO + +# The WARNINGS tag can be used to turn on/off the warning messages that are +# generated to standard error ( stderr) by doxygen. If WARNINGS is set to YES +# this implies that the warnings are on. +# +# Tip: Turn warnings on while writing the documentation. +# The default value is: YES. + +WARNINGS = YES + +# If the WARN_IF_UNDOCUMENTED tag is set to YES, then doxygen will generate +# warnings for undocumented members. If EXTRACT_ALL is set to YES then this flag +# will automatically be disabled. +# The default value is: YES. + +WARN_IF_UNDOCUMENTED = YES + +# If the WARN_IF_DOC_ERROR tag is set to YES, doxygen will generate warnings for +# potential errors in the documentation, such as not documenting some parameters +# in a documented function, or documenting parameters that don't exist or using +# markup commands wrongly. +# The default value is: YES. + +WARN_IF_DOC_ERROR = YES + +# This WARN_NO_PARAMDOC option can be enabled to get warnings for functions that +# are documented, but have no documentation for their parameters or return +# value. If set to NO doxygen will only warn about wrong or incomplete parameter +# documentation, but not about the absence of documentation. +# The default value is: NO. + +WARN_NO_PARAMDOC = YES + +# The WARN_FORMAT tag determines the format of the warning messages that doxygen +# can produce. The string should contain the $file, $line, and $text tags, which +# will be replaced by the file and line number from which the warning originated +# and the warning text. Optionally the format may contain $version, which will +# be replaced by the version of the file (if it could be obtained via +# FILE_VERSION_FILTER) +# The default value is: $file:$line: $text. + +WARN_FORMAT = "$file:$line: $text " + +# The WARN_LOGFILE tag can be used to specify a file to which warning and error +# messages should be written. If left blank the output is written to standard +# error (stderr). + +WARN_LOGFILE = + +#--------------------------------------------------------------------------- +# Configuration options related to the input files +#--------------------------------------------------------------------------- + +# The INPUT tag is used to specify the files and/or directories that contain +# documented source files. You may enter file names like myfile.cpp or +# directories like /usr/src/myproject. Separate the files or directories with +# spaces. +# Note: If this tag is empty the current directory is searched. + +INPUT = +@INCLUDE = $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/device/$(DEVICE)/includes.cfg + +# This tag can be used to specify the character encoding of the source files +# that doxygen parses. Internally doxygen uses the UTF-8 encoding. Doxygen uses +# libiconv (or the iconv built into libc) for the transcoding. See the libiconv +# documentation (see: http://www.gnu.org/software/libiconv) for the list of +# possible encodings. +# The default value is: UTF-8. + +INPUT_ENCODING = UTF-8 + +# If the value of the INPUT tag contains directories, you can use the +# FILE_PATTERNS tag to specify one or more wildcard patterns (like *.cpp and +# *.h) to filter out the source-files in the directories. If left blank the +# following patterns are tested:*.c, *.cc, *.cxx, *.cpp, *.c++, *.java, *.ii, +# *.ixx, *.ipp, *.i++, *.inl, *.idl, *.ddl, *.odl, *.h, *.hh, *.hxx, *.hpp, +# *.h++, *.cs, *.d, *.php, *.php4, *.php5, *.phtml, *.inc, *.m, *.markdown, +# *.md, *.mm, *.dox, *.py, *.f90, *.f, *.for, *.tcl, *.vhd, *.vhdl, *.ucf, +# *.qsf, *.as and *.js. + +FILE_PATTERNS = *.h \ + *.c \ + *.html \ + *.md + +# The RECURSIVE tag can be used to specify whether or not subdirectories should +# be searched for input files as well. +# The default value is: NO. + +RECURSIVE = NO + +# The EXCLUDE tag can be used to specify files and/or directories that should be +# excluded from the INPUT source files. This way you can easily exclude a +# subdirectory from a directory tree whose root is specified with the INPUT tag. +# +# Note that relative paths are relative to the directory from which doxygen is +# run. + +EXCLUDE = + +# The EXCLUDE_SYMLINKS tag can be used to select whether or not files or +# directories that are symbolic links (a Unix file system feature) are excluded +# from the input. +# The default value is: NO. + +EXCLUDE_SYMLINKS = YES + +# If the value of the INPUT tag contains directories, you can use the +# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude +# certain files from those directories. +# +# Note that the wildcards are matched against the file with absolute path, so to +# exclude all test directories for example use the pattern */test/* + +EXCLUDE_PATTERNS = + +# The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names +# (namespaces, classes, functions, etc.) that should be excluded from the +# output. The symbol name can be a fully qualified name, a word, or if the +# wildcard * is used, a substring. Examples: ANamespace, AClass, +# AClass::ANamespace, ANamespace::*Test +# +# Note that the wildcards are matched against the file with absolute path, so to +# exclude all test directories use the pattern */test/* + +EXCLUDE_SYMBOLS = + +# The EXAMPLE_PATH tag can be used to specify one or more files or directories +# that contain example code fragments that are included (see the \include +# command). + +EXAMPLE_PATH = + +# If the value of the EXAMPLE_PATH tag contains directories, you can use the +# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp and +# *.h) to filter out the source-files in the directories. If left blank all +# files are included. + +EXAMPLE_PATTERNS = + +# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be +# searched for input files to be used with the \include or \dontinclude commands +# irrespective of the value of the RECURSIVE tag. +# The default value is: NO. + +EXAMPLE_RECURSIVE = NO + +# The IMAGE_PATH tag can be used to specify one or more files or directories +# that contain images that are to be included in the documentation (see the +# \image command). + +IMAGE_PATH+=$(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/images/ +IMAGE_PATH+=$(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/images/motorcontrol + +# The INPUT_FILTER tag can be used to specify a program that doxygen should +# invoke to filter for each input file. Doxygen will invoke the filter program +# by executing (via popen()) the command: +# +# +# +# where is the value of the INPUT_FILTER tag, and is the +# name of an input file. Doxygen will then use the output that the filter +# program writes to standard output. If FILTER_PATTERNS is specified, this tag +# will be ignored. +# +# Note that the filter must not add or remove lines; it is applied before the +# code is scanned, but not when the output code is generated. If lines are added +# or removed, the anchors will not be placed correctly. + +INPUT_FILTER = + +# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern +# basis. Doxygen will compare the file name with each pattern and apply the +# filter if there is a match. The filters are a list of the form: pattern=filter +# (like *.cpp=my_cpp_filter). See INPUT_FILTER for further information on how +# filters are used. If the FILTER_PATTERNS tag is empty or if none of the +# patterns match the file name, INPUT_FILTER is applied. + +FILTER_PATTERNS = + +# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using +# INPUT_FILTER ) will also be used to filter the input files that are used for +# producing the source files to browse (i.e. when SOURCE_BROWSER is set to YES). +# The default value is: NO. + +FILTER_SOURCE_FILES = NO + +# The FILTER_SOURCE_PATTERNS tag can be used to specify source filters per file +# pattern. A pattern will override the setting for FILTER_PATTERN (if any) and +# it is also possible to disable source filtering for a specific pattern using +# *.ext= (so without naming a filter). +# This tag requires that the tag FILTER_SOURCE_FILES is set to YES. + +FILTER_SOURCE_PATTERNS = + +# If the USE_MDFILE_AS_MAINPAGE tag refers to the name of a markdown file that +# is part of the input, its contents will be placed on the main page +# (index.html). This can be useful if you have a project on for instance GitHub +# and want to reuse the introduction page also for the doxygen output. + +USE_MDFILE_AS_MAINPAGE = + +#--------------------------------------------------------------------------- +# Configuration options related to source browsing +#--------------------------------------------------------------------------- + +# If the SOURCE_BROWSER tag is set to YES then a list of source files will be +# generated. Documented entities will be cross-referenced with these sources. +# +# Note: To get rid of all source code in the generated output, make sure that +# also VERBATIM_HEADERS is set to NO. +# The default value is: NO. + +SOURCE_BROWSER = NO + +# Setting the INLINE_SOURCES tag to YES will include the body of functions, +# classes and enums directly into the documentation. +# The default value is: NO. + +INLINE_SOURCES = NO + +# Setting the STRIP_CODE_COMMENTS tag to YES will instruct doxygen to hide any +# special comment blocks from generated source code fragments. Normal C, C++ and +# Fortran comments will always remain visible. +# The default value is: YES. + +STRIP_CODE_COMMENTS = YES + +# If the REFERENCED_BY_RELATION tag is set to YES then for each documented +# function all documented functions referencing it will be listed. +# The default value is: NO. + +REFERENCED_BY_RELATION = NO + +# If the REFERENCES_RELATION tag is set to YES then for each documented function +# all documented entities called/used by that function will be listed. +# The default value is: NO. + +REFERENCES_RELATION = NO + +# If the REFERENCES_LINK_SOURCE tag is set to YES and SOURCE_BROWSER tag is set +# to YES, then the hyperlinks from functions in REFERENCES_RELATION and +# REFERENCED_BY_RELATION lists will link to the source code. Otherwise they will +# link to the documentation. +# The default value is: YES. + +REFERENCES_LINK_SOURCE = YES + +# If SOURCE_TOOLTIPS is enabled (the default) then hovering a hyperlink in the +# source code will show a tooltip with additional information such as prototype, +# brief description and links to the definition and documentation. Since this +# will make the HTML file larger and loading of large files a bit slower, you +# can opt to disable this feature. +# The default value is: YES. +# This tag requires that the tag SOURCE_BROWSER is set to YES. + +SOURCE_TOOLTIPS = YES + +# If the USE_HTAGS tag is set to YES then the references to source code will +# point to the HTML generated by the htags(1) tool instead of doxygen built-in +# source browser. The htags tool is part of GNU's global source tagging system +# (see http://www.gnu.org/software/global/global.html). You will need version +# 4.8.6 or higher. +# +# To use it do the following: +# - Install the latest version of global +# - Enable SOURCE_BROWSER and USE_HTAGS in the config file +# - Make sure the INPUT points to the root of the source tree +# - Run doxygen as normal +# +# Doxygen will invoke htags (and that will in turn invoke gtags), so these +# tools must be available from the command line (i.e. in the search path). +# +# The result: instead of the source browser generated by doxygen, the links to +# source code will now point to the output of htags. +# The default value is: NO. +# This tag requires that the tag SOURCE_BROWSER is set to YES. + +USE_HTAGS = NO + +# If the VERBATIM_HEADERS tag is set the YES then doxygen will generate a +# verbatim copy of the header file for each class for which an include is +# specified. Set to NO to disable this. +# See also: Section \class. +# The default value is: YES. + +VERBATIM_HEADERS = YES + +#--------------------------------------------------------------------------- +# Configuration options related to the alphabetical class index +#--------------------------------------------------------------------------- + +# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index of all +# compounds will be generated. Enable this if the project contains a lot of +# classes, structs, unions or interfaces. +# The default value is: YES. + +ALPHABETICAL_INDEX = NO + +# The COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns in +# which the alphabetical index list will be split. +# Minimum value: 1, maximum value: 20, default value: 5. +# This tag requires that the tag ALPHABETICAL_INDEX is set to YES. + +COLS_IN_ALPHA_INDEX = 5 + +# In case all classes in a project start with a common prefix, all classes will +# be put under the same header in the alphabetical index. The IGNORE_PREFIX tag +# can be used to specify a prefix (or a list of prefixes) that should be ignored +# while generating the index headers. +# This tag requires that the tag ALPHABETICAL_INDEX is set to YES. + +IGNORE_PREFIX = + +#--------------------------------------------------------------------------- +# Configuration options related to the HTML output +#--------------------------------------------------------------------------- + +# If the GENERATE_HTML tag is set to YES doxygen will generate HTML output +# The default value is: YES. + +GENERATE_HTML = YES + +# The HTML_OUTPUT tag is used to specify where the HTML docs will be put. If a +# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of +# it. +# The default directory is: html. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_OUTPUT = . + +# The HTML_FILE_EXTENSION tag can be used to specify the file extension for each +# generated HTML page (for example: .htm, .php, .asp). +# The default value is: .html. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_FILE_EXTENSION = .html + +# The HTML_HEADER tag can be used to specify a user-defined HTML header file for +# each generated HTML page. If the tag is left blank doxygen will generate a +# standard header. +# +# To get valid HTML the header file that includes any scripts and style sheets +# that doxygen needs, which is dependent on the configuration options used (e.g. +# the setting GENERATE_TREEVIEW). It is highly recommended to start with a +# default header using +# doxygen -w html new_header.html new_footer.html new_stylesheet.css +# YourConfigFile +# and then modify the file new_header.html. See also section "Doxygen usage" +# for information on how to generate the default header that doxygen normally +# uses. +# Note: The header is subject to change so you typically have to regenerate the +# default header when upgrading to a newer version of doxygen. For a description +# of the possible markers and block names see the documentation. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_HEADER = $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/theme/header.html + +# The HTML_FOOTER tag can be used to specify a user-defined HTML footer for each +# generated HTML page. If the tag is left blank doxygen will generate a standard +# footer. See HTML_HEADER for more information on how to generate a default +# footer and what special commands can be used inside the footer. See also +# section "Doxygen usage" for information on how to generate the default footer +# that doxygen normally uses. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_FOOTER = $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/theme/footer.html + +# The HTML_STYLESHEET tag can be used to specify a user-defined cascading style +# sheet that is used by each HTML page. It can be used to fine-tune the look of +# the HTML output. If left blank doxygen will generate a default style sheet. +# See also section "Doxygen usage" for information on how to generate the style +# sheet that doxygen normally uses. +# Note: It is recommended to use HTML_EXTRA_STYLESHEET instead of this tag, as +# it is more robust and this tag (HTML_STYLESHEET) will in the future become +# obsolete. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_STYLESHEET = + +# The HTML_EXTRA_STYLESHEET tag can be used to specify an additional user- +# defined cascading style sheet that is included after the standard style sheets +# created by doxygen. Using this option one can overrule certain style aspects. +# This is preferred over using HTML_STYLESHEET since it does not replace the +# standard style sheet and is therefor more robust against future updates. +# Doxygen will copy the style sheet file to the output directory. For an example +# see the documentation. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_EXTRA_STYLESHEET = $(MOTOR_CONTROL_SDK_PATH)/docs_src/docs/api_guide/theme/stylesheet.css + +# The HTML_EXTRA_FILES tag can be used to specify one or more extra images or +# other source files which should be copied to the HTML output directory. Note +# that these files will be copied to the base HTML output directory. Use the +# $relpath^ marker in the HTML_HEADER and/or HTML_FOOTER files to load these +# files. In the HTML_STYLESHEET file, use the file name only. Also note that the +# files will be copied as-is; there are no commands or markers available. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_EXTRA_FILES = + +# The HTML_COLORSTYLE_HUE tag controls the color of the HTML output. Doxygen +# will adjust the colors in the stylesheet and background images according to +# this color. Hue is specified as an angle on a colorwheel, see +# http://en.wikipedia.org/wiki/Hue for more information. For instance the value +# 0 represents red, 60 is yellow, 120 is green, 180 is cyan, 240 is blue, 300 +# purple, and 360 is red again. +# Minimum value: 0, maximum value: 359, default value: 220. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_COLORSTYLE_HUE = 0 + +# The HTML_COLORSTYLE_SAT tag controls the purity (or saturation) of the colors +# in the HTML output. For a value of 0 the output will use grayscales only. A +# value of 255 will produce the most vivid colors. +# Minimum value: 0, maximum value: 255, default value: 100. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_COLORSTYLE_SAT = 0 + +# The HTML_COLORSTYLE_GAMMA tag controls the gamma correction applied to the +# luminance component of the colors in the HTML output. Values below 100 +# gradually make the output lighter, whereas values above 100 make the output +# darker. The value divided by 100 is the actual gamma applied, so 80 represents +# a gamma of 0.8, The value 220 represents a gamma of 2.2, and 100 does not +# change the gamma. +# Minimum value: 40, maximum value: 240, default value: 80. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_COLORSTYLE_GAMMA = 100 + +# If the HTML_TIMESTAMP tag is set to YES then the footer of each generated HTML +# page will contain the date and time when the page was generated. Setting this +# to NO can help when comparing the output of multiple runs. +# The default value is: YES. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_TIMESTAMP = NO + +# If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML +# documentation will contain sections that can be hidden and shown after the +# page has loaded. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_DYNAMIC_SECTIONS = NO + +# With HTML_INDEX_NUM_ENTRIES one can control the preferred number of entries +# shown in the various tree structured indices initially; the user can expand +# and collapse entries dynamically later on. Doxygen will expand the tree to +# such a level that at most the specified number of entries are visible (unless +# a fully collapsed tree already exceeds this amount). So setting the number of +# entries 1 will produce a full collapsed tree by default. 0 is a special value +# representing an infinite number of entries and will result in a full expanded +# tree by default. +# Minimum value: 0, maximum value: 9999, default value: 100. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_INDEX_NUM_ENTRIES = 100 + +# If the GENERATE_DOCSET tag is set to YES, additional index files will be +# generated that can be used as input for Apple's Xcode 3 integrated development +# environment (see: http://developer.apple.com/tools/xcode/), introduced with +# OSX 10.5 (Leopard). To create a documentation set, doxygen will generate a +# Makefile in the HTML output directory. Running make will produce the docset in +# that directory and running make install will install the docset in +# ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find it at +# startup. See http://developer.apple.com/tools/creatingdocsetswithdoxygen.html +# for more information. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +GENERATE_DOCSET = NO + +# This tag determines the name of the docset feed. A documentation feed provides +# an umbrella under which multiple documentation sets from a single provider +# (such as a company or product suite) can be grouped. +# The default value is: Doxygen generated docs. +# This tag requires that the tag GENERATE_DOCSET is set to YES. + +DOCSET_FEEDNAME = "Doxygen generated docs" + +# This tag specifies a string that should uniquely identify the documentation +# set bundle. This should be a reverse domain-name style string, e.g. +# com.mycompany.MyDocSet. Doxygen will append .docset to the name. +# The default value is: org.doxygen.Project. +# This tag requires that the tag GENERATE_DOCSET is set to YES. + +DOCSET_BUNDLE_ID = org.doxygen.Project + +# The DOCSET_PUBLISHER_ID tag specifies a string that should uniquely identify +# the documentation publisher. This should be a reverse domain-name style +# string, e.g. com.mycompany.MyDocSet.documentation. +# The default value is: org.doxygen.Publisher. +# This tag requires that the tag GENERATE_DOCSET is set to YES. + +DOCSET_PUBLISHER_ID = org.doxygen.Publisher + +# The DOCSET_PUBLISHER_NAME tag identifies the documentation publisher. +# The default value is: Publisher. +# This tag requires that the tag GENERATE_DOCSET is set to YES. + +DOCSET_PUBLISHER_NAME = Publisher + +# If the GENERATE_HTMLHELP tag is set to YES then doxygen generates three +# additional HTML index files: index.hhp, index.hhc, and index.hhk. The +# index.hhp is a project file that can be read by Microsoft's HTML Help Workshop +# (see: http://www.microsoft.com/en-us/download/details.aspx?id=21138) on +# Windows. +# +# The HTML Help Workshop contains a compiler that can convert all HTML output +# generated by doxygen into a single compiled HTML file (.chm). Compiled HTML +# files are now used as the Windows 98 help format, and will replace the old +# Windows help format (.hlp) on all Windows platforms in the future. Compressed +# HTML files also contain an index, a table of contents, and you can search for +# words in the documentation. The HTML workshop also contains a viewer for +# compressed HTML files. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +GENERATE_HTMLHELP = NO + +# The CHM_FILE tag can be used to specify the file name of the resulting .chm +# file. You can add a path in front of the file if the result should not be +# written to the html output directory. +# This tag requires that the tag GENERATE_HTMLHELP is set to YES. + +CHM_FILE = + +# The HHC_LOCATION tag can be used to specify the location (absolute path +# including file name) of the HTML help compiler ( hhc.exe). If non-empty +# doxygen will try to run the HTML help compiler on the generated index.hhp. +# The file has to be specified with full path. +# This tag requires that the tag GENERATE_HTMLHELP is set to YES. + +HHC_LOCATION = "c:\Program Files (x86)\HTML Help Workshop\hhc.exe " + +# The GENERATE_CHI flag controls if a separate .chi index file is generated ( +# YES) or that it should be included in the master .chm file ( NO). +# The default value is: NO. +# This tag requires that the tag GENERATE_HTMLHELP is set to YES. + +GENERATE_CHI = NO + +# The CHM_INDEX_ENCODING is used to encode HtmlHelp index ( hhk), content ( hhc) +# and project file content. +# This tag requires that the tag GENERATE_HTMLHELP is set to YES. + +CHM_INDEX_ENCODING = + +# The BINARY_TOC flag controls whether a binary table of contents is generated ( +# YES) or a normal table of contents ( NO) in the .chm file. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTMLHELP is set to YES. + +BINARY_TOC = NO + +# The TOC_EXPAND flag can be set to YES to add extra items for group members to +# the table of contents of the HTML help documentation and to the tree view. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTMLHELP is set to YES. + +TOC_EXPAND = YES + +# If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and +# QHP_VIRTUAL_FOLDER are set, an additional index file will be generated that +# can be used as input for Qt's qhelpgenerator to generate a Qt Compressed Help +# (.qch) of the generated HTML documentation. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +GENERATE_QHP = NO + +# If the QHG_LOCATION tag is specified, the QCH_FILE tag can be used to specify +# the file name of the resulting .qch file. The path specified is relative to +# the HTML output folder. +# This tag requires that the tag GENERATE_QHP is set to YES. + +QCH_FILE = + +# The QHP_NAMESPACE tag specifies the namespace to use when generating Qt Help +# Project output. For more information please see Qt Help Project / Namespace +# (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#namespace). +# The default value is: org.doxygen.Project. +# This tag requires that the tag GENERATE_QHP is set to YES. + +QHP_NAMESPACE = + +# The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating Qt +# Help Project output. For more information please see Qt Help Project / Virtual +# Folders (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#virtual- +# folders). +# The default value is: doc. +# This tag requires that the tag GENERATE_QHP is set to YES. + +QHP_VIRTUAL_FOLDER = doc + +# If the QHP_CUST_FILTER_NAME tag is set, it specifies the name of a custom +# filter to add. For more information please see Qt Help Project / Custom +# Filters (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom- +# filters). +# This tag requires that the tag GENERATE_QHP is set to YES. + +QHP_CUST_FILTER_NAME = + +# The QHP_CUST_FILTER_ATTRS tag specifies the list of the attributes of the +# custom filter to add. For more information please see Qt Help Project / Custom +# Filters (see: http://qt-project.org/doc/qt-4.8/qthelpproject.html#custom- +# filters). +# This tag requires that the tag GENERATE_QHP is set to YES. + +QHP_CUST_FILTER_ATTRS = + +# The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this +# project's filter section matches. Qt Help Project / Filter Attributes (see: +# http://qt-project.org/doc/qt-4.8/qthelpproject.html#filter-attributes). +# This tag requires that the tag GENERATE_QHP is set to YES. + +QHP_SECT_FILTER_ATTRS = + +# The QHG_LOCATION tag can be used to specify the location of Qt's +# qhelpgenerator. If non-empty doxygen will try to run qhelpgenerator on the +# generated .qhp file. +# This tag requires that the tag GENERATE_QHP is set to YES. + +QHG_LOCATION = + +# If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files will be +# generated, together with the HTML files, they form an Eclipse help plugin. To +# install this plugin and make it available under the help contents menu in +# Eclipse, the contents of the directory containing the HTML and XML files needs +# to be copied into the plugins directory of eclipse. The name of the directory +# within the plugins directory should be the same as the ECLIPSE_DOC_ID value. +# After copying Eclipse needs to be restarted before the help appears. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +GENERATE_ECLIPSEHELP = NO + +# A unique identifier for the Eclipse help plugin. When installing the plugin +# the directory name containing the HTML and XML files should also have this +# name. Each documentation set should have its own identifier. +# The default value is: org.doxygen.Project. +# This tag requires that the tag GENERATE_ECLIPSEHELP is set to YES. + +ECLIPSE_DOC_ID = org.doxygen.Project + +# If you want full control over the layout of the generated HTML pages it might +# be necessary to disable the index and replace it with your own. The +# DISABLE_INDEX tag can be used to turn on/off the condensed index (tabs) at top +# of each HTML page. A value of NO enables the index and the value YES disables +# it. Since the tabs in the index contain the same information as the navigation +# tree, you can set this option to YES if you also set GENERATE_TREEVIEW to YES. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +DISABLE_INDEX = YES + +# The GENERATE_TREEVIEW tag is used to specify whether a tree-like index +# structure should be generated to display hierarchical information. If the tag +# value is set to YES, a side panel will be generated containing a tree-like +# index structure (just like the one that is generated for HTML Help). For this +# to work a browser that supports JavaScript, DHTML, CSS and frames is required +# (i.e. any modern browser). Windows users are probably better off using the +# HTML help feature. Via custom stylesheets (see HTML_EXTRA_STYLESHEET) one can +# further fine-tune the look of the index. As an example, the default style +# sheet generated by doxygen has an example that shows how to put an image at +# the root of the tree instead of the PROJECT_NAME. Since the tree basically has +# the same information as the tab index, you could consider setting +# DISABLE_INDEX to YES when enabling this option. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +GENERATE_TREEVIEW = YES + +# The ENUM_VALUES_PER_LINE tag can be used to set the number of enum values that +# doxygen will group on one line in the generated HTML documentation. +# +# Note that a value of 0 will completely suppress the enum values from appearing +# in the overview section. +# Minimum value: 0, maximum value: 20, default value: 4. +# This tag requires that the tag GENERATE_HTML is set to YES. + +ENUM_VALUES_PER_LINE = 4 + +# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be used +# to set the initial width (in pixels) of the frame in which the tree is shown. +# Minimum value: 0, maximum value: 1500, default value: 250. +# This tag requires that the tag GENERATE_HTML is set to YES. + +TREEVIEW_WIDTH = 250 + +# When the EXT_LINKS_IN_WINDOW option is set to YES doxygen will open links to +# external symbols imported via tag files in a separate window. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +EXT_LINKS_IN_WINDOW = NO + +# Use this tag to change the font size of LaTeX formulas included as images in +# the HTML documentation. When you change the font size after a successful +# doxygen run you need to manually remove any form_*.png images from the HTML +# output directory to force them to be regenerated. +# Minimum value: 8, maximum value: 50, default value: 10. +# This tag requires that the tag GENERATE_HTML is set to YES. + +FORMULA_FONTSIZE = 10 + +# Use the FORMULA_TRANPARENT tag to determine whether or not the images +# generated for formulas are transparent PNGs. Transparent PNGs are not +# supported properly for IE 6.0, but are supported on all modern browsers. +# +# Note that when changing this option you need to delete any form_*.png files in +# the HTML output directory before the changes have effect. +# The default value is: YES. +# This tag requires that the tag GENERATE_HTML is set to YES. + +FORMULA_TRANSPARENT = YES + +# Enable the USE_MATHJAX option to render LaTeX formulas using MathJax (see +# http://www.mathjax.org) which uses client side Javascript for the rendering +# instead of using prerendered bitmaps. Use this if you do not have LaTeX +# installed or if you want to formulas look prettier in the HTML output. When +# enabled you may also need to install MathJax separately and configure the path +# to it using the MATHJAX_RELPATH option. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +USE_MATHJAX = NO + +# When MathJax is enabled you can set the default output format to be used for +# the MathJax output. See the MathJax site (see: +# http://docs.mathjax.org/en/latest/output.html) for more details. +# Possible values are: HTML-CSS (which is slower, but has the best +# compatibility), NativeMML (i.e. MathML) and SVG. +# The default value is: HTML-CSS. +# This tag requires that the tag USE_MATHJAX is set to YES. + +MATHJAX_FORMAT = HTML-CSS + +# When MathJax is enabled you need to specify the location relative to the HTML +# output directory using the MATHJAX_RELPATH option. The destination directory +# should contain the MathJax.js script. For instance, if the mathjax directory +# is located at the same level as the HTML output directory, then +# MATHJAX_RELPATH should be ../mathjax. The default value points to the MathJax +# Content Delivery Network so you can quickly see the result without installing +# MathJax. However, it is strongly recommended to install a local copy of +# MathJax from http://www.mathjax.org before deployment. +# The default value is: http://cdn.mathjax.org/mathjax/latest. +# This tag requires that the tag USE_MATHJAX is set to YES. + +MATHJAX_RELPATH = http://cdn.mathjax.org/mathjax/latest + +# The MATHJAX_EXTENSIONS tag can be used to specify one or more MathJax +# extension names that should be enabled during MathJax rendering. For example +# MATHJAX_EXTENSIONS = TeX/AMSmath TeX/AMSsymbols +# This tag requires that the tag USE_MATHJAX is set to YES. + +MATHJAX_EXTENSIONS = + +# The MATHJAX_CODEFILE tag can be used to specify a file with javascript pieces +# of code that will be used on startup of the MathJax code. See the MathJax site +# (see: http://docs.mathjax.org/en/latest/output.html) for more details. For an +# example see the documentation. +# This tag requires that the tag USE_MATHJAX is set to YES. + +MATHJAX_CODEFILE = + +# When the SEARCHENGINE tag is enabled doxygen will generate a search box for +# the HTML output. The underlying search engine uses javascript and DHTML and +# should work on any modern browser. Note that when using HTML help +# (GENERATE_HTMLHELP), Qt help (GENERATE_QHP), or docsets (GENERATE_DOCSET) +# there is already a search function so this one should typically be disabled. +# For large projects the javascript based search engine can be slow, then +# enabling SERVER_BASED_SEARCH may provide a better solution. It is possible to +# search using the keyboard; to jump to the search box use + S +# (what the is depends on the OS and browser, but it is typically +# , /