• State
  • Locked Locked
  • Replies 12 replies
  • Subscribers 32 subscribers
  • Views 4218 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TM4C129XNCZAD: Are timer-triggered, timestamped Quad SSI transfers possible with scatter/gather uDMA?

Leo Bredehoft58
Expert 1260 points
Part Number: TM4C129XNCZAD

I would like to build a continuously-running, streamed uDMA transfer, whose output I convert in software for transmission over a TCP socket.  The socket conversion work I understand and am confident will work, but I don't have full confidence in whether or not the uDMA scatter/gather will do what I need.  On request from a repeating hardware timer, I would like a repeating scatter/gather to:

1) Transfer a block of data acquired from external ADC's using the Quad SSI in Quad mode.

2) Immediately after the last sample of the block is transferred, perform a single transfer from EMACTIMSEC/EMACTIMNANO to memory as a timestamp.  I may decide I would like to transfer from a timer/counter instead, if that turns out to be the right thing to do.

3) Relinquish the data stored to software with an interrupt.

4) Repeat steps 1, 2 and 3 into another buffer, while software is processing the relinquished data.  This is the "pong" of a "Ping-Pong", although this work is actually implemented using scatter/gather.

5) Start over at step 1.

Is uDMA scatter/gather capable of doing this?

  • 0
    Guru 92251 points

    From reading the TM4C129XNCZAD the "scatter-gather" and "Ping-Pong" both use the primary and alternate data structures, and so I don't think you can use "scatter-gather" and "Ping-Pong" at the same time.

    Given that you only appear to need scatter-gather to collect a timestamp upon transfer of the last sample could you use ping-pong mode for the transfers and read the timestamp in the interrupt for completion of the block?

    Not sure how accurate a timestamp you require, and if the interrupt handling latency / jitter will cause an issue for the collected timestamp.

  • 0 in reply to Chester Gillon
    Expert 1260 points

    Hi Chester:

    Thanks for the quick answer!  I shouldn't have mixed the scatter-gather and Ping-Pong nomenclature.  I mean only to use the scatter-gather hardware mechanism, although Ping-Pong-style alternation of buffers would be embedded in the SG transfer sequence.  The timestamp requirement is stringent, in terms of a few hundred nanoseconds if possible, so I would like for hardware to be responsible for the transfer.  I believe interrupt latency would be a big problem, so I don't wish to use interrupts for that purpose.

    Best regards,

    Leo Bredehoft

  • 0 in reply to Leo Bredehoft58
    Expert 1260 points

    Will the proposed scheme work?

  • 0 in reply to Leo Bredehoft58
    Expert 1260 points
    Instead of using a hardware timer request to trigger the gather DMA, I would like to trigger an SPI DMA read on a GPIO falling edge, from an ADC "BUSY" signal deassertion. After a few thousand such SSI BUSY-triggered transfers, I would like to store a timestamp from EMACTIMSEC/EMACTIMNANO and cause an interrupt. Then, I would like to start the process over, into a different buffer. This would be a looped, continuous process. I would like to know if this can be done with the chip, before I build the hardware. Thanks!
  • 0 in reply to Leo Bredehoft58
    Expert 1260 points
    According to TM4C129XNCZ Data Sheet section 9.2.6.6, Peripheral Scatter-Gather, it looks like this could be possible, if the EMACTIMSEC/EMACTIMNANO transfer is treated as memory-to-memory. Does anyone know?
  • 0 in reply to Leo Bredehoft58
    TI__Guru 72500 points
    If I understand your question correctly, you want to use a GPIO falling edge from an external ADC to trigger an SPI read operation. That should work, you would actually have the uDMA do a dummy write to the SSInDR (data register) to start the SPI transfer (assuming the TM4C is the SPI master). Then you would need another uDMA to copy the SPI received data to a RAM buffer. To create the time read from the EMAC registers after some thousand ADC conversions, you could connect the same ADC busy signal to a timer pin and use the timer to count events. When the event count matches, have it trigger a third uDMA channel to copy from the EMAC registers to RAM and create an interrupt.
  • 0 in reply to Bob Crosby
    Guru 117855 points

    Bob - believe your guidance to be quite resourceful & clever. (and of course "ticked" Like.)

    Now - poster's request seeks to (avoid) "building the hardware" (post 27 Apr, 12:38) until his understanding/hope has been verified.

    Cannot he avoid "building the hardware" via use of a launchpad - cabled into an "ADC Eval board" (assumes the exact or similar ADC is available) so that his key/critical operational requirements may be, "teased out?"   Such technique has (often) enabled my small group to draw sound conclusions - even when - and especially when - the "final hardware" has "vapor" consistency.      (neither yet exists or is available!)

    From experience - the development & regular practice of such method would prove beneficial to SO (many) here...     (Forum help is less available in the "real-world.")

  • 0 in reply to Bob Crosby
    Expert 1260 points
    Thanks for your answer.

    Each SSI read transfer (as master) would consist of 8-10 bytes in Bi-SSI mode (including the 2x Bi-SSI overhead), with one GPIO request for each transfer. I guess that the SPI transfers would be scatter-gather, with some provision for looping the SG list back to the first command for continuous operation.

    I'm not sure how to build the SG list for a hardware-continuous alternating-buffer scheme, with 1000 transfers per buffer. It doesn't have to be alternating, either. It's probably even preferable to just stream into a single rotating buffer, whose data is chased by a task in the background, or in a low-priority interrupt. Could I do that? How do I loop for continuous, hardware-guaranteed transfers, without requiring any DMA reprogramming in an interrupt routine? I have streamed, no-jitter-allowed, ADC sample rates approaching 2M samples/second, so interrupt latency can't sit directly in the way of sample transfer -- it needs to be hardware-managed. I would hope that I wouldn't have to build a task list of 1000 descriptors.

    I need to be able to bound the time between the timestamp and the samples. If the two DMA streams are started at the same time, it would seem that I could consider the last SSI transfer to be within a few internal bus latencies of the stored timestamp. Does that sound reasonable? Maybe the timestamp DMA can be at a higher priority than the SSI DMA, and it can be used to do some kind of live surgery on the task list, forcing buffer wraparound/switch to be at the same time as the timestamp.

    What kind of maximum delay would you expect from GPIO transition to start of SSI transfer on the interface? That will set an upper bound on my sample rate.

    If you want, you can contact me at the email TI has on file, and we can set up a phone call.

    Best regards,
    Leo Bredehoft
  • 0 in reply to Leo Bredehoft58
    Expert 1260 points
    I have a TM4C129X development board which I would be happy to use to test ideas out. But if you find a show-stopper in the above requirements, I may have to just skip that and resort to some EPLD-based external help, selecting whatever is the most appropriate interface for the MCU. On the software side, this design is streaming the received data over Ethernet, after doing some hand-optimized bit packing, which still leaves 75% of the processor for overhead. That is just FYI -- I think I have the software under control. I'm getting help from a network-savvy TI person on e2e.ti.com/.../2174529.
  • 0 in reply to Leo Bredehoft58
    Guru 117855 points

    May I ask if your "27 Apr, 2:57" post targets me?

    I love the detail & your (very) considered task description. The level of detail (may) over-challenge - thus firm/I - most always fall back upon, "Live experimentation - which may be replicated" to "tease out" key/critical facts.

    As your requirement has so many, "Complex and Moving Parts" - to my mind - "KISS" and systematic, individual, progressive verification is the ONLY (best way) to proceed!

  • 0 in reply to cb1_mobile
    Expert 1260 points
    Yes, I was responding to the experimentation idea. Given the time pressures on the effort, I'm trying to trade off between empirically-determined optimality and quick results in areas where this design is just peripheral support. If I can succeed with design by informed decree here, then I can hope to have time where I know I will have to do a lot of experimentation. Thanks for your comments -- any suggestions you have are very welcome.
  • 0 in reply to Leo Bredehoft58
    Guru 117855 points

    Thank you - note that today registers as, "day 14" since your (initial) post arrived.
    The nature of your requirement is highly complex - and appears (not quite) "at the ready" for (even) the talented vendor staff here. (perhaps)

    I stand by the use of, "Systematic, progressive, tightly bound experimentation" to gain (real) understanding & verification of even (especially) critical & complex device behavior!    Especially so when, "Time is of the essence."

    And clearly - you're smart/experienced enough to appreciate that (sometimes) such "experimentation" will enable the discovery of (even) improved/alternate - methods/handlings - neither having arrived via the "less illuminating/probing/extracting," - normal forum back-forth!