• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 490 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:

AM6548: Image Interface with parallel Pixel lines

AM6442: Video-/image-Interface implementation for 16bpp Images with parallel Input

Stephan Karger
Intellectual 280 points

Part Number: AM6442
Other Parts Discussed in Thread: AM5726

Hello,

we have develloped a smart camera based on the AM5726 and our own camera module and for the future we would like to use an AM6xxx
processor to make use of a platform. As we spend a lot of development effort into the image interface for real time features we are
searching for a processor from the AM6xxx family which can be used with our existing camera module.

Our current smart camera consists of an AM5726 and our own camera module with an image sensor and an fpga.
The fpga converts the image so that we have a frame valid, line valid, pixel clock and 16 bits in parallel at the video input port.
On the AM5726 we use VIP3 to capture 16bpp grayscale images. The pixel clock is generated by the fpga and it is at a maximum of around 125MHz.

Our requirements for the new processor are:
1. Video-/Image- input port with 16bit parallel data input for 16bit per pixel, frame valid and pixel clock (line valid might be not necessary)
2. Pixel clock is generated by the fpga
3. Pixel clock up to 125HHz

In the future we would like to use an AM6xxx Processor. I saw that some AM64xx Processors have a MIPI CSI-2 Interface but using this
would mean that we have to spend a lot of effort to redesign our camera module. So my questions are:
1. Is it possible to implement an image interface on a PRU?
2. Are there examples for using a PRU for that in an SDK ore somewhere else?
3. I unsed the TI-Sysconfig tool an saw that there is a Pin Configuration for 16 bit parallel data input with the PRU. Is there an EVM
   with an AM64xx processor where these data lines are on a socket so that I can connect our camera module?

Thank you very much.

Regards,

Stephan

  • 0
    TI__Intellectual 2210 points

    Hi Stephan,

    ICSS_G on AM64 has two PRUs with IO connection. Parallel capture IO mode takes external clock to sample 16 bit data into PRU register with either rising or falling edge of clock. For 18 bit data + sync you need to run two PRUs in sync to also capture sync signals. A timing diagram with sample and hold time for data and control lines is needed to decide how to sync and store line data and frame data. 

    PRU core can run 333 MHz which is 2.66 PRU cycles per clock. PRU writes the data in linear code into PRU register and uses single cycle XFR2VBUS widget to store 32 samples into memory.

    Pseudo code:

       wbs new_sample

       mov r2.w0, r31.w0   // 1 st sample

       wbs  new_sample  

       mov r2.w2, r31.w0   // 2nd sample

       ...

       mov r17.w0, r31.w0  // 32nd sample

       xout  XFR2VBUS_ID, &r2, 64    // store to memory

       wbs  new_sample

    Each instruction takes 3 ns to execute including the 64 byte memory save with xfr2vbus. The wait bit set (wbs) instruction can be delayed by one clock to add additional instruction for loops and eof condition. The additional instruction can be distributed over a block of 32 sample. 32 is just an example and can be adjusted to the number of pixels per line.  

    In order to synchronize two PRUs you can use the task managers with single trigger.  

    You have 4 more PRUs to post process the captured data and sync signals.

    - Thomas 

  • 0 in reply to Thomas Leyrer
    Intellectual 280 points

    Hi Thomas, 

    thank you for the answer. 

    Maybe the information I gave about the line-valid and frame-valid signals was unclear. 

    The line valid and frame valid signals are synchronisation signals and the values need not to be transferred. I think for capturing images with the PRU we would need to configure interrupts for the PRU on the raising or falling edge and in the interrupt service routines the destination address has to be set to the beginning of the next line or frame. So we only have to transfer 16 bit on each clock pulse.

    Can this be implemented on a single PRU? 

    Thanks,

       Stephan

     

  • 0 in reply to Stephan Karger
    TI__Intellectual 2210 points

    Hi Stephen,

      I am not sure I can follow without seeing a timing diagram. I give it a try.

    Method 1: PRU1 triggers PRU0

    PRU1 samples sync line valid and frame valid with 3 ns resolution.

    Once a new line/frame is detected it will kick off PRU0 to capture 16 bit data using parallel capture mode.

    PRU0 trigger can be through task manager or PRU0 is polling scratch pad register. Task manager is more deterministic and has a 2 cycle latency.

    PRU1: detects end of line/frame and triggers PRU0 higher priority task to stop sampling.

    The min time from detecting edge on PRU1 and start capture on PRU0 is in the range of

    - 1 cycle to detect the edge

    - 1 cycle to generate interrupt via R31

    - 2 cycles to enter task on PRU

    - 1 cycle to poll for valid data based on rising or falling edge

    - some delay of event routing between INTC and task manager

    In total I expect ~25 ns delay between sync edge and start of sampling on PRU with this scheme.

    If this scheme is too slow then I propose:

    Method 2: PRU0 and PRU1 sample data and sync concurrently and we use more PRUs to detect edges and synchronize data.

    Best Regards,

       Thomas