TMS570LC4357: Delay from an event software and a GPIO input (RTI or N2HET?)

Hello Alain,

Can you explain in more detail what you need? In other words, you mention you need to know the time between a software event and a GPIO toggle. This inherrently would imply that the CPU is involved because it is running the software and would be the source of the event. Correct?

If I interpret your first scenario, the SW event would trigger a read of the RTI followed by the CPU writing to the GPIO register to raise to a high level triggering an interrupt and subsequent time 2 read of the RTI to compute the overall time between when the SW event happens and the GPIO is raised. If you would use the method, you would anticipate a significant loading on the CPU due to the number of GPIOs and frequency of the SW events. Correct? How frequently do you expect the SW events to happen? And, is there any way these software events can be used to trigger the GPIO set function in a deterministic way or, at least, within a time frame suitable for the application to not care about the latency. i.e., if the SW event triggered a SWI (SW interrupt) and the GPIO is set immediately in this GPIO. Or if the SW event was tied to a DMA event that wrote to the GPIO Set register, etc. This gets back to the requirement for how accurate the timing would need to be.

In the second scenario, the SW event would trigger an action on the NHET in a similar manner? How do you anticipate the NHET being used in this capacity? The NHET can be used to generate pulsed outputs or capture pulsed inputs. i.e. PWM out and input capture. But it can also do much more. There are counters also included in the instruction set so that you can count pulses or, I believe, loop times in the NHET code. I'm not an NHET expert but I a sure there is some way that it could do what you want to some degree but I don't know about the resolution of the timing.

Hi Chuck, 

I'll try to explain mode in detail. The goal is to synchronize 3 (or more) TI boards. In order to, the idea is to have one discrete line from each board to the other ones and check the time differences between them. The SW period will be 1ms, and we want to be synchronized less than 10µs. 

View from one board, it will be 2 (or more) GPIO inputs. At the start of the cycle (the SW event I have mentionned in my previous post), the SW will get a timetag (RTI, or HET), start a counter (RTI or HET) and raise his GPIO. When the other TI board starts is cycle, his GPIO goes up and by reading the counter we can know the time difference between the two boards. Same for the third one.

We will try to do that with the lower CPU compsumtion as possible. 

With RTI Method: We will have one interrupt for each input line each 1ms. Each time an interrupt will bee raised, we will get the RTI counter and made the difference with the counter at the beginning of the cycle. 

With HET Method, what I would like to know is how to start a counter when a GPIO is raised and get/reset this counter by SW.

I hope my explanations will be enougth to be understandable. 

Best Regards

Alain 

 

Hi Alain,

I understand now, I believe.

For the RTI solution, you would use the GPIO interrupt to trigger an interrupt to the CPU and then process the RTI, set additional GPIO output, and read new RTI value to derive the time that has passed for synchronization purposes. One possibility for this method would be to have the Interrupt trigger a set of daisy changed DMA transactions. The first DMA transfer would read the RTI and move to an SRAM location, the second would write to the GPIO output buffer/GPIO DSET register, and the last DMA transaction would read the RTI again and move to SRAM. Once done, the CPU could then do the delta calculation.

For the NHET solution, you should be able to have the signal as an input to a NHET channel where you could capture the transition from low to high (or vice versa dependent on your need) and based on this transition, start the counter that would be incremented based on the loop resolution time and then set another HET channel as asserted (high or low) then stop the counter and capture the value. Note that this would probably always be a consistent value since each instruction will execute based on the LR time you configure. Since the execution of this code is based on a digital clock/logic, the timing will be very deterministic and any variation will probably beyond the capability of any counter in NHET to capture. I will discuss with a colleage who is more of a NHET expert than I am so maybe he will have some ideas.