• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 251 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.

Original question:

PROCESSOR-SDK-AM64X: PRU 16 Bit Input Capture

PROCESSOR-SDK-AM64X: Parallel Capture mode vs Direct Input Mode AM64x/AM243x

Keith Mecham
Prodigy 80 points

Part Number: PROCESSOR-SDK-AM64X
Other Parts Discussed in Thread: AM2434, SYSCONFIG, ADS127L11, ADS131M08

Tool/software:

Hello,  Similar to this thread, https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1300144/processor-sdk-am64x-pru-16-bit-input-capture, I am trying to read from a 40Msps ADC (MAX1195 or MAX1198) that provides two channels of 8 bit data over a parallel bus.  The 16 bit parallel capture mode seems to be an ideal fit since I can use the ADC clock to trigger the parallel capture on the PRU.  (The ADC datasheet advises that output data is valid on the rising edge of the clock).  According to the AM243x datasheet the PRU should be able to capture the parallel data at up to 50Msps (20ns clock period), but obviously this only works if I can stuff the data somewhere fast enough.

From the old thread, it sounds like the only difference between handling the incoming data with Direct Mode and Parallel Capture mode would be that the PRU will only update bits [0-15] of R30 [b16] transitions low or high.  Is there any speed advantage to this vs using Direct Mode and polling R30 [b16] changes to high or low (in assembly)?  If I understand correctly from the old post Parallel Capture does not initiate any action other than to update R30, so I would need to poll R30 [b16] regardless to determine when to transfer the data to a buffer block.

Also, the examples given in the SDK for the ADS85x8 are quite slow, using the macros to detect when a pin changes high/low adds quite a bit of latency.  For my application I only have 8 clock cycles (running at 333 on the AM2434) to grab the int16 and store it in the buffer before the next sample shows up, so I will need to eliminate the debounce delays or just poll the pin directly rather than use the macros.

Am I tracking everything correctly or have I made some bad assumptions?  Please correct me or confirm if I am close.

Also, in SysConfig there is an ICSS PRU block for ADC that is used in the ADS85x8 example.  Several control signals are defined in this block that I don't need.  Is it possible to modify or create my own version of the ADC config block, or should I just set everything up manually?  Is there an example of setting up the registers for parallel capture in assembly rather than SysConfig?

Thanks!

  • 0
    TI__Expert 7395 points

    Hi Keith,

    Keith Mecham said:
    If I understand correctly from the old post Parallel Capture does not initiate any action other than to update R30, so I would need to poll R30 [b16] regardless to determine when to transfer the data to a buffer block.

    Your understanding is correct, it is just R31 instead of R30 where the data and external CLOCKIN is read.

    Using parallel mode gives you flexibility to use any external signal instead of reading at every PRU clock cycle, there won't be any significant speed advantage for your use case.

    Keith Mecham said:
    Is it possible to modify or create my own version of the ADC config block, or should I just set everything up manually?
    The Sysconfig 'ADC' module can currently be used only for the ADCs available in MCU+ SDK (ADS85x8, ADS127L11 and ADS131M08), for any other ADC you can add an instance of the 'PRU (ICSS)' and select the required signals and functionality.
    To create your own version of the ADC module, you will have to modify the sysconfig template files (I do not recommend this since the auto-generated files will be impacted).
    Keith Mecham said:
    Is there an example of setting up the registers for parallel capture in assembly rather than SysConfig?
    The serial, parallel, and byte-parallel mode available in the ADC sysconfig refer to the different interfaces supported by ADS85x8 ADCs and not the PRU parallel mode. You will have to set the PRU GPI to 16-bit parallel mode in the application/firmware.

    Regards,

    Nitika

  • 0 in reply to Nitika Verma
    Prodigy 80 points

    Hi Nitika,

    Thank you for the quick response to my questions, and for correcting me on R31 vs R30.  I will code this up and run some tests writing to registers.

    My next step is to buffer the captured data in a shared memory location that I can access with the R5F_0_0 core.  I found some other threads discussing using Data RAM, and for the AM243x I am finding that each PRU has 8k available, plus a 64k shared Data RAM block.  Do you know if both of these types of ram can be accessed by the R5F cores?

    Best Regards,

  • 0 in reply to Keith Mecham
    TI__Expert 7395 points

    Hi Keith,

    Yes, The R5F core can access both PRU DRAMs and Shared RAM memory.

    PRU also has access to the 2MB MSRAM and 2GB DDR memory if you need a larger memory but the access latency can be higher for them.

    Regards,

    Nitika