2009-05-22 01:44:04     LCD and Camera application

Document created by Aaronwu Employee on Aug 15, 2013
Version 1Show Document
  • View in full screen mode

2009-05-22 01:44:04     LCD and Camera application

V Hemanth Kumar (INDIA)

Message: 74433   


We have a OV9655 camera module interfaced to the BF526 EZKIT.


Since Camera and LCD share the same PPI port, are there any standard applications in uClinux


which captures image from Camera and displays it on the LCD? Like digital Camera viewer app?


Please suggest your views on how we can achieve this feature.




2009-05-22 15:27:54     Re: LCD and Camera application


Message: 74461   




This needs to be done in hardware - not software.


The camera needs to drive the LCD and the PPI when in "viewer" mode.


When in playback mode - the camera needs to be held in tri-state, and the PPI can drive the LCD.


That is the only way to do what you are wanting.






2009-05-25 04:29:10     Re: LCD and Camera application

V Hemanth Kumar (INDIA)

Message: 74528   


Hello Robin, thanks for the reply.


We have designed a custom hardware with BF527 core.


The Camera and LCD hardware architecture is as follows:-


The LCD is ADI LCD ez-extender and camera is OV9655 cmos sensor module.


The LCD is interfaced with 16 bit PPI and works at 5MHz clock frequency. The Camera is interfaced with 8bit PPI and works at 25MHz clock. Pixel CLK from the LCD and camera go into the CPLD where it is muxed to the PPICLK using some glue logic. The hardware glue logic is that when capturing from the Camera CPLD is provided with a logic to select the Camera pixel clk and by default LCD pixel clock is selected.


The PPI bus is connected to camera via buffers, the output enables of the buffers is controlled by the CPLD. The CPLD ensures that when LCD is used, outpus and inputs of buffers remain in tristate. similarly when camera is used it is ensured by the CPLD to avoid any PPI data going to the LCD. There is no data contention from hardware point of view.


Driver changes:-


The LCD and the camera driver should driver a common GPIO pin (1 for LCD and 0 for camera) to direct the CPLD to select LCD or Camera.


The proposed software architecture for image viewing application:-


If a user wants live images from camera on to the LCD, then application gets a frame from camera, copies this frame to the mmaped frame buffer given by the LCD frame buffer driver.


Can this feautre (Live view on LCD) be acheived with this kind of approach and hardware architecture?


Please provide your valuable suggestions.




2009-05-25 04:38:49     Re: LCD and Camera application

V Hemanth Kumar (INDIA)

Message: 74530   


Please find the attached document which has the LCD-Camera architecutre block diagram.






2009-05-25 05:25:29     Re: LCD and Camera application

Michael Hennerich (GERMANY)

Message: 74532    I doubt that such an approach will give you a 'Real LiveView'.

It should be possible to:


1)Load the Camera driver module.

2)Take a picture

3)Remove the Camera driver module

4)Load the /dev/fb driver

5)Display the picture


If you really need what I understand as live view then you should use a

Blackfin derivative featuring 2 PPIs, such as BF54x or BF561.

Alternatively use an external display controller.

Or some more enhanced logic that will drive the LCD directly from the

CMOS camera sensor while the PPI is owned by the Camera driver module.






2009-05-25 19:00:59     Re: LCD and Camera application


Message: 74550   




Like Michael said - the performance will suck. Imagine your lcd dropping out for a second, while you capture the frame from the camera. You can't flip back and forth in real time.


Like Michael said - solve the problem in hardware - use a part with 2 PPI.