1 Reply Latest reply on Apr 7, 2017 8:01 AM by Carlos_A

    BayTrail-I E3845 MIPI CSI2 interface receiving latency

    Sung-hyuk_Choi Community Member

      Hi,

      I'm Choi.

       

      I use E3845's MIPI interface for camera interface.

      I measured the receiving latency of E3845 MIPI Interface.

      The measure step is as follows,

       

      1. With FPGA via D-PHY IC, I send image frame(640 x 480 x 16bit, with 2 lane D-Phy)

      2. I set a GPIO pin high at FPGA side just after completion of each image frame transmission.

          (The GPIO pin return to low state after tens of micro seconds.)

      3. CPU's ISP receives the frame successfully and saves the frame on DDR memory.

      4. CPU set a GPIO pin high, (One of CPU's GPIO pin)

      5. I check the interval FPGA GPIO pin's rising point to CPU GPIO pin's rising point.

       

      The received frame was perfect. There was no Checksum error or sequence Number error.

      And with viewer program, the received image look same as the source image.

      D-PHY IC has just small size buffer.

      CPU's application was developed with WindRiver Linux 7.x.

      I know WR Linux didn't support pre-emptive RT for MIPI ISP.

      So, we raised the task's priority to the highest level as high as possible to reduce the latency.

       

      Now, my question is this,

      I expected the the latency is below 1 msec,

      But, the latency was over 3 msec.

      The latency is disappointingly long.

      Why the latency is so long ?

      Does the ISP use PCIe bus internally ?

      Or there are 2 step buffering ?

      Isn't there any know-how to reduce the latency dramatically under 1 msec ?

       

      Regard,

      Choi

        • Re: BayTrail-I E3845 MIPI CSI2 interface receiving latency
          Carlos_A Brown Belt

          Hello, Sung-hyuk_Choi:

           

          Thank you for contacting Intel Embedded Community.

           

          In order to better understand this situation, we would like to address the following questions:

           

          Could please try to reproduce this situation using any of following the Operating System (OS) and let us know the results?

           

          Wind River VxWorks*

          Microsoft Windows* 8

          Windows Embedded Standard 8 (non-connected standby)

          Microsoft Windows 7

          Windows Embedded Standard 7

          Linux* Tizen (select in-vehicle infotainment (IVI) customers only)

          Linux based on Yocto Project*

          Linux based on Fedora*

          Microsoft Embedded Compact 7 and 2013

          Android* (JB MR2 4.3)

           

          Could you please clarify if it is a third party design or your design? In case that it is a third party one, please give us all the information related to it. On the other hand, in case that it is your design, could you please let us know in a detailed way how did you implement it?

           

          Please let us know this information to have a better idea of this situation.

           

          Best regards,

          Carlos_A.