• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 99 subscribers
  • Views 1248 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.

New binning or skipping mode.

JamesS
Prodigy 190 points

Hi,

 I would like to change the binning or skipping modes available.  At the moment I see in  drivers/media/video/mt9p031.c that in static int mt9p031_setBinning_Skip(int arg) {} there are bits set and cleared that affect the sensor row and column settings at the same time.

  I need to add options to skip or bin rows but not columns.  That is to leave the image width the same, but reduce the height by a factor of 2.

 Also I need to add variable frame rates, so the frame rate can be adjusted from about 80 FPS to 200 FPS.  The 200 FPS can only occur with binning or skipping, so the data throughput is not too high.

 What do I need to modify in the kernel?  Will this affect the DVSDK?  If so how, and will it cope?

 Is this even possible with the current mvl kernel and Ti dvsdk?

James. 

 

  • 0
    TI__Mastermind 37340 points

    I am not too familiar with micron sensor driver (or hardware capabilities yet), so I cannot comment much on binning or skipping rows, but if you are going to be changing frame rates, you need to take pixel clock (aka video clock) into account.

    pixel clock = resolution x refresh rate

    By default, the video input clock to DaVinci is 27MHz (enough for NTSC D1 @ 30fps), if you do not change the resolution and change the refresh rate, then your pixel clock needs to change.  Many of our DaVinci parts (DM355, DM644x,...) can take input video clocks up to 75Mhz.  The question is, do you have the hardware in place to provide such a pixel clock.

    The beautiful thing about Linux is that is open source and you have all the software driver source code at your disposal; therefore, as long as the hardware capability is present, you can certainly achieve this via the kernel provided in the DVSDK. 

  • 0
    TI__Mastermind 41665 points

    Looking in the LSP included with the last couple of DM355 DVSDK releases (1.30.00.40 and 1.30.00.23) I am not seeing the /drivers/media/video/mt9p031.c file, rather there looks to be a mt9t001.c file that does not have the binning function you mention, so I am curious what kernel source tree you are using?

    As long as the drivers are modified properly I do not see any reason to modify anything else in the kernel for something like this, as everything that would be changing would be at the driver level. Of course the application would also have to agree on the image size (the DVSDK demos may get confused by this), as well as be able to handle the frames at the rate you want, but the real work would be getting the settings right in the sensor and adjusting the buffers in the driver to handle the proper sizes.

  • 0 in reply to Bernie Thompson TI
    Prodigy 190 points

    We have an IP Net Cam from Appro.  It has this extra source file in it's kernel sources.

     I see some code in the application, that shoves a binning set function pointer into a structure, that seems to be passed to an Appro closed source AEW library.  The code path has been a little hard to follow.  But this is why I wonder what else is going on behind the scenes, and possibly in the DVSDK.

     In the kernel, some of the binning funtions are called from a dm355_vpfe.c (or similar - I don't have the code at home ;-).

    I guess part of my problem is that I don't know where the DVSDK components begin and end, and what they affect and how.  Can you guys recommend some good reading?

    I also wonder what else a change of resolution would affect, when the resolutions and frame rates are given as fixed enumerated constants, like VGA_30FPS.  If I wanted 640x496 for example, what else needs to know besides the sensor - via i2c?  I presume the iPipe, and probably the MPEG engine.  Ah - I've spent too long looing at code, my mind is a mess.

  • 0 in reply to JamesS
    TI__Mastermind 37340 points

    DVSDK software is what is available from TI via our software update site; this software is primarily written and controlled by TI.  In addition, we have teamed up with many 3rd parties in order to provide more readily available solutions to our customers.  Appro is an example of one such third party.

    Unfortunately, 3rd parties often branch off one of our DVSDK software releases and end up providing their own software implementation which closely resembles and often overlaps our DVSDK software.  I am not familiar with Appro's software deliverables, but it sounds like they have branched off one of our DVSDK Linux kernels and changed portions of the Linux kernel and deliver their own kernel version to customers.  Latest DVSDK has drivers (including source code) for AEW (as opposed to libraries provided by Appro) and supports a couple of Micron sensor daughter cards (off-the-shelf).  TI has more control over this more generic solution as a starting point for customers that need to interface to CCD sensors.  The Appro offering is a more complete IP Net Cam solution, but it also depends on software written and supported by Appro which TI does not always have insight into.  Therefore is hard to judge how much of the original DVSDK is kept by Appro solution and how much is replaced by their own implementation (or even what DVSDK version they based their solution on and do they plan on upgrading to newer DVSDKs as they become available).

    As far as making changes to resolution or refresh rate; please keep the formula pixel clock = resolution x refresh rate in mind.  With a fixed hardware clock of 27 MHz, as you change your resolution (includes blanking), the refresh rate will be affected as well.  You can always play with the horizontal and blanking areas to achieve a visual resolution (valid video area) at a desired refresh rate as long as your display knows how to handle the blanking areas correctly.  This pixel clock, resolution, and refresh rate relationship is key.

    Aside from the above, when you change resolution, you need to change
    - driver level registers defining video frame (new resolution, including blanking areas)
    - application level buffer management to account for new buffer sizes
    - application level calls to any encoding/decoding codec to provide it the correct video resolution.I hope this helps!

     

  • 0 in reply to Juan Gonzales
    Prodigy 190 points

    Appro has deviated a little from what software was delivered with our DVEM.  They have their own AEW library, that remains closed source, and TI have added the kernel source for this micron sensor.  They use and specify standard TI dvsdk_1_30_00_40.

    I am aware that the hardware from Appro won't do the required frame rates we are after.  Thanks for pointing out the formula.  Thanks for the tips on what needs to change to support various resolutions.

    Is there a single document that shows the flow of data through the system, from application right through to a sensor, and back again, for example?  I have found bits of information, but nothing that really ties it all together.  I've found the whole thing very frustrating so far.  I realise it is quite complex, but surely a breakdown from top level components into smaller parts would lay the whole thing out and make the task of comprehending how things fit and cooperate would be feasible. 

  • 0 in reply to JamesS
    TI__Mastermind 37340 points

    I agree this can be quite complex.  Like most complex software architectures, there are various defined APIs (V4L2 driver, FBDev driver, codec engine...) which applications use to make all the various software components function together.  In my opinion, the key is to understand these APIs as well as where they fit in the software architecture (kernel space, user space,...).

    There are App Notes which describe this from the point of view of the demos provided in the DVSDK; for example http://focus.ti.com/lit/an/spraah0a/spraah0a.pdf

    As far as APIs go, Please keep in mind that most of the driver APIs are defined by Linux standards and hence we do not provide documentation for those (not defined by TI), but there should be plenty of documentation and example application online.  We do provide documentation for non-standard Linux drivers defined by TI and our codec engine APIs.