This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS570LS3137: RTI vs HET for angle/time measurement

Expert 1995 points
Part Number: TMS570LS3137
Other Parts Discussed in Thread: HALCOGEN, TMDS570LS31HDK

Hello,

I am using the Hercules HDK to capture the angular position and speed of a motor shaft. The Hall / MR sensors generate pulses as the motor starts to rotate. Depending on the design I can adjust the resolution such that the maximum pulse frequency is about 10 KHz - 80 KHz ( I prefer to use the higher resolution alternative- i.e 20 KHz ). I would like to use the TMS570 to calculated the position and speed of the motor. From what I understand there are two ways of doing it: 1) To use GIO to generate an edge detection interrupt, count a few pulses and use RTI to capture time difference between X number of pulses. 2) to use N2HET

While method 1 is more accurate it is quite interrupt intensive and is not ideal especially since my system has 8 speed sensors


Is what the user called as "method 1)" actually MORE accurate than using the N2HET as counting/measurement means (including the integrated angle measurement) by edge detection?

Which of the following options is recommended to achieve angle measurement by interrupt detection (GIO or HET)? Are all implementable just using Halcogen/CCS (without the HET IDE) ?

1) Using the HET for both getting rising/falling edges and also to count the respective periods (and maybe also for measuring directly the angle);

2) Detecting edges by HET (edge-detection) but counting by RTI;

3) Detecting edges by GIO (e.g. interrupt) and counting by RTI.

For example, from this post the RTI looks to me being preferred over the dedicated HET functionalities.

  • Hello,

    To use NHET, you need to write code to handle the edge detection, period measurement, etc. The NHET timer resolution depends on the LRP and HRP. The LRP must be larger than the longest path of the N2HET program in N2HET RAM. The latency of the edge detection is 1 LRP. For example, N2HET program has 16 instructions which takes 20 vclk cycles, and the LRP is 32 (>20). If the edge of the input signal happens right after ECNT execution, the edge will be detected by ECNT in next LRP. The LRP = 32*HRP, if HR=VCLK=90MHz, LRP is about 320ns. 

    The code generated by HALCoGen includes PWM, edge detection, and capture. I prefer to develop my own short program using HET IDE. 

    I'd like to use N2HET for those detection which can reduce the CPU overhead and interrupt load. The HTU can be used to transfer data between CPU memory and N2HET RAM.

  • I made a little test with the same routine using the HET with edge detection and using the edge detection of the GIO: the occurrence of a rising/falling edge at the respective inputs turns on an LED or another one. I have observed that the edge routine of the GIO is much faster that that one coming from the HET. Is it due to the LRP? 

    Halcogen sets by default the LRP to 1422.222 ns. Should I shorten it to get the same performance of using the GIO ? Below the code I used to evaluate those performance (I use the TMDS570LS31HDK as development kit):

    /* USER CODE END */
    
    int main(void)
    {
    /* USER CODE BEGIN (3) */
        vimInit();
            _enable_IRQ();
            _enable_FIQ();
            gioInit();
            hetInit();
    
    /*generates a 3.3v output from GIO[4]*/
            gioSetBit(gioPORTA,4,1);
    
    
    /*Enable edge detection (HET[8-9] enabled by Halcogen and associated to edge0-1): rising edge in HET[8] and falling edge in HET[9]*/
            edgeEnableNotification(hetREG1, edge0);
            edgeEnableNotification(hetREG1, edge1);
    
    /*Enable rising edge in GIOA[0] and falling edge in GIOA[1] by Halcogen*/
            gioEnableNotification(gioPORTA, 0u);
            gioEnableNotification(gioPORTA, 1u);
    
            
    
    /* USER CODE END */
    
        return 0;
    }
    
    
    /* USER CODE BEGIN (4) */
    void edgeNotification( hetBASE_t * hetREG, uint32 edge )
    {
    
        if (edge == edge0)
        {
            gioSetBit(hetPORT1,25,0);
            gioSetBit(hetPORT1,0,1);
        }
        else
        {
    
            gioSetBit(hetPORT1,0,0);
            gioSetBit(hetPORT1,25,1);
    
        }
    }
    
    void gioNotification(gioPORT_t *port, uint32 bit)
    {
        if (bit > 0u)
        {
            gioSetBit(hetPORT1,0,0);
            gioSetBit(hetPORT1,25,1);
    
        }
        else
        {
            gioSetBit(hetPORT1,25,0);
            gioSetBit(hetPORT1,0,1);
        }
    }

  • Hello,

    It is caused by the LRP and execution time of GIO ISR. GIO interrupt has higher priority, N2HET interrupt is put in pending until GIO ISR is done.

    The edge detection uses PCNT instruction which takes only 1 clock cycle. If there are less than 7 instructions in your code, LRP can be configured as shorter as 8 cycles (88.88ns, VCLK=90MHz is used in your exmaple), so the maximum delay is reduced to 88ns. How fast response is required by your application for 20KHz (50000ns period) input?

  • Let's say that 1-10 micro seconds would be ok. Furthermore, similar to the lines above, I have only to handle the logic state of 4 outputs in my code when a rising/falling occurs.

    So, basically the maximum delay that I can observe since an edge occurs (rising or falling) corresponds to what is indicated in Halcogen as "Actual LR Time", correct?

  • yes, the maximum is mainly caused by the LRP. In HALCoGen NHET code, 128 is used for LRP. This is why the delay is 1422ns. 

  • I shortened the LRP but I observed 2 problems:

    - when the Loop Time is 183.333ns, the LR Prescale is 4 and the Actual LR Time is 183.333ns, my code is not executed (the output HET1[0] does not turns on, etc.); when the Loop Time is 183.334ns, the LR Prescale jumps to 5 and the Actual LR Time becomes 355.556ns. With these last settings the code runs normally.

    Can you tell me why ?

    Regards.

  • Hello,

    The loop resolution period (LRP) must be selected to be larger than the number of Time slots (VCLK2 cycles) required to complete the worst-case execution path through the N2HET program. Otherwise, the program will execute unpredictably because some instructions will not be executed each time through the loop.

    If the LR is 4, the LRP supports 16 time slots. But if the LR=5, the LRP supports 32 time slots. 

    How many instructions are used in your code? If total cycles taken by the instructions is > 16, your code will not execute correctly.

  • Hi,

    What is considered as instruction? The single line of C-code, the (equivalent) assembly code or what else? 

    Another question: coming back to the original topic HET vs RTI, what do you think is more accurate at the end? So far I have been considered as approach to measure the time between two edges, reading the RTI once the edge is detected (e.g. rising edge) and stopping at the consecutive edge (e.g. falling edge). Is there a more accurate way to get such measure with the HET simply with Halcogen?

    Thanks ahead.

    Regards.

  • Hello,

    1. Please refer to the "Instruction set" in the chapter of N2HET module. ECNT instruction is used for edge detection. ECNT takes 1 VCLK cycle. You can use HET IDE to develop and simulate your own code.

    HET IDE can generate c file and header file used in CCS project:

    2. In het.c, the instruction 17 is ECNT (c file)

    3. You can use ether GIO or NHET. GIO is faster than NHET.

  • Thank you for the clarification.

    QJ Wang said:
    GIO is faster than NHET.

    How much faster? I am searching for some section in the datasheet where I can numerically evaluate such timing difference but unsuccessfully since there the HET specifications are part of the GIO specifications.

    So I just wonder what is actually the advantage of using the HET for edge detection.

  • Hello,

    The N2HET pins can be used as GPIO, but NHET pins ar enot able to generate interrupt in GPIO mode. 

    N2HET is a coprocessor, and supports up to 30 instructions. Most instructions execute in one VCLK clock. NHET generates many complex output waveforms and capture input signals without CPU interrupts which will save CPU bandwidth. The CPU can stop the N2HET, view N2HET memory content, and update the data field of instructions asynchronously. For NHET features, please refer to N2HET chapter of TRM. 

  • QJ Wang said:
    NHET generates many complex output waveforms and capture input signals without CPU interrupts which will save CPU bandwidth

    For the output waveform I see that, but for input capture, as long as I transmit the interrupt to the VIM also the CPU is engaged, isn't it?

    Can you please tell me even roughly how slower is the HET compared to the GIOs in terms of input capture?

    Thanks!

    Regards.

  • Hello,

    You are right. The interrupt is handled by CPU. The the edge of the input signal can be used to trigger other operations (start a PWM, change the PWM parameters, edge count, etc) by NHET code in NHET RAM, the external interrupt is not required.

    The delay time of NHET interrupt varies. If the edge happens just before the execution ECNT instruction, the edge is detected by ECNT and HETFLG is set immediately, the delay time is 11.1 ns or less (VCLK=90MHz). If the edge happens just after the ECNT is executed, the edge will be detected by next ECNT in next LRP, the delay is LRP. In the worst case scenario, the delay is LRP.

  • QJ Wang said:
    The the edge of the input signal can be used to trigger other operations (start a PWM, change the PWM parameters, edge count, etc) by NHET code in NHET RAM, the external interrupt is not required.

    Is this feature (start PWM without external interrupt, etc.) something can be done without the HET IDE ? If yes, can you please tell me how?

    QJ Wang said:
    In the worst case scenario, the delay is LRP.

    So, can LRP be seen as the worse delay between N2HET and GIO when the same edge is applied to both?

  • Hello,

    The ECNT contains a conditional address. When an edge event is detected, the code will jump to conditional address. So you can change the PWM parameters using MOV32 or MOV64 here. I don't have example code.

    Yes, the LRP is the worst delay.