• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 2 answers
  • Subscribers 100 subscribers
  • Views 374 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

BEAGLEBK: PRU input signal

PAk
Mastermind 6995 points

Part Number: BEAGLEBK

Hello. 

I am quite new to PRU, sorry in advance if I make any mistake.

I would need to read a parallel LVDS signal which is a 4 data channels + CLK and Framesync, that looks like this:

As you can see, the signals change in every edge (both falling and rising edges). Of course, we would place a differential LVDS driver receptor prior to the beaglebone pru ports (so signal will be exactly as the black + traces in the figure). Our intention is to send them later to memory and probably the ARM would create a UDP packet to send them over ethernet.

I would like to know if there is a way to receive these signals with the PRU in any way and process them correctly.

Would it be a Direct Connection Mode configuration?

Thank you all.

  • 0
    TI__Guru**** 393215 points

    Hi,

    From what I see your data input would change at every clock edge. The PRU cannot capture serial data on an external clock. Capture may be possible in 16-bit parallel capture mode, but it would need a lot of software overhead as you will need to change the clock active edge on every sampled bit, and then you will need to reassemble the captured frame by software. A limiting factor would also be the input clock frequency. The PRU operates at 200MHz and the maximum input clock frequency in 16-bit parallel capture mode is 50MHz.

    Please read the whole section 4.4.1.2.3 in the AM335x TRM Rev. Q for detailed description of the PRU general-purpose inputs and different modes of operation.

  • 0 in reply to Biser Gatchev-XID
    Mastermind 6995 points

    Thank you Biser, this answer is very helpful.

    How much overhead would take to chang the clock active edge on every sampled bit? From my understanding, if every instruction takes a clock cycle, this could be done at a frequency of 100MHz, hence the 50MHz effective sampling for the parallel capture mode wouldn't be affected. Later the other PRU could format the sampled data.

    Another solution for avoiding overhead could be to sample the clock with PRU0 and generate a clock of a higher frequency on an output pin and pass it along to PRU1 clk. Do you think it is feasible?

    Regarding to Serial Data and clocking, would it be possible to make a fast polling on the CLK  & FRAME signals, and in every change read/sample the 4 channels simultaneously?

    On the other hand, there is a possibility of using a 16 bit parallel mode in our device, however, if I am correct the beaglebone is only capable of reading 14 parallel inputs + clk for one pur (on pru1). Would it be possible to combine input pins for both PRUs and arrange them later in memory?

    Thank you very much for your time and help, as you see I don't control all the possibilities of PRUs (yet).

    BR

  • 0 in reply to Biser Gatchev-XID
    Mastermind 6995 points

    I still need some clarification for marking the answer as solved. Best regards

  • 0 in reply to PAk
    TI__Guru**** 393215 points

    PAk said:
    How much overhead would take to chang the clock active edge on every sampled bit?

    I cannot say, this is not an use case that has been tested and verified by TI.

    PAk said:
    Another solution for avoiding overhead could be to sample the clock with PRU0 and generate a clock of a higher frequency on an output pin and pass it along to PRU1 clk. Do you think it is feasible?

    Again, this is something that has not been tested. You can try it by yourself.

    PAk said:
    On the other hand, there is a possibility of using a 16 bit parallel mode in our device, however, if I am correct the beaglebone is only capable of reading 14 parallel inputs + clk for one pur (on pru1). Would it be possible to combine input pins for both PRUs and arrange them later in memory?

    Yes, this is specific to the BBB design. Not all PRU inputs are available, as some are taken for other functions. Using both PRUs might work.