Menu
▾
▴
Re: [Gumstix-users] OMAP, Camera, DSP and MPU speeds
|
From: Jason C. M. <jas...@am...> - 2012-11-12 18:33:20
|
I don't think a discussion of camera interfaces is complete without the cost of the solution, and distance you can have the camera sensor away from the ISP input without running into problems. The other important element is what each subsystem does. For example you don't have to use the ISP interface to use the resizer. As far as I know the resizer will work on data in memory. In fact even the previewer (that has all the debayer goodies) can technically have its input data coming from memory. The last time I checked the ISP drivers don't support that, but I believe it's possible. The discussion is also not complete without all the gotcha's of the OMAP ISP interface. It is a very valuable resource, but it has it's quirks. At first we had issues because we didn't realize you had to do things in a very specific order regarding the pipeline. We also didn't realize that any interruption in the VSYNC/HSYNC would throw off the ISP. Sure sometimes it can handle it, but most times it throws the entire bayer filter off. You also can't just reset it because now the ISP interface is in a bad state and will just lock up when you try turning it off. If you have the sensor close to the OMAP than I doubt you'll have any serious issues. All you need to test it is to have a +/- 8KV ESD discharge to something nearby. If it keeps going for 100 hits or so than you're fine. If it throws off the debayer or the vsync/hsync then you either have to use better shielding or digitally filter the VSYNC/HSYNC lines. I use a Xilinx CPLD to do digital filtering, and to do level shifting. The other frustrating element is TI absolutely refuses to disclose what's actually in the DM37x chips. In section 1.5 of the Technical reference manual (Rev N) they claim that the chip doesn't have a CSI inputs, or even any Preview module. I know it has a preview module because I use it. I asked them to fix it, but I think they just ignored everyone asking for it to be fixed or clarified. This was in the TI forum for the OMAP chips (this was originally about the OMAP3503). -----Original Message----- From: Gerardo Richarte [mailto:ge...@di...] Sent: Monday, November 12, 2012 5:12 AM To: General mailing list for gumstix users. Subject: [Gumstix-users] OMAP, Camera, DSP and MPU speeds Hi, we are trying to figure out whether the camera interfaces in the Overos (and OMAPs) have any benefit in terms of speed when compared to, for example, a GigE camera connected via a memory mapped external gigabit ethernet controller. Any and all comments will be very much welcome, and I think we can all together leave this email discussion as some sort of future reference for others trying to deal with similar issues. So just add your 2 cents where you can. :) Our concerns go in two or maybe three directions: 1. The different hardware speed possibilities (available data transfer throughput in the different interfaces: memory for GigE, via Camera Interface, CSI1, CSI1, MIPI, etc). 2. The possibilities of using the camera ISP to do image pre-processing, such as pixel format conversion, dead pixel corrections, resizing, previewing, etc. 3. The number of total memory transfers required for image processing. In the first line of thought, we are looking at what clocks speeds, bus widths, dead clock cycles (wait states, etc) and connectivity options (direct to DSP or not) each bus offers. Our current option for gigabit ethernet controller (AX88180) allows 16 bit operations (as required by the OMAP and Overo), and can handle up to 500 Mbps at this bus width (other options are welcome). However, this must also be filtered via the available bus clock speeds in the Overo, and we are still trying to figure out the GPMC clocking options. However, even before this details, the camera ISP in the OMAPs can, apparently, handle higher throughput interfaces (such as 8 bits @ 150 MHz, and 12 bits @ 75 MHz). While apparently both interface have an equivalent internal connection to the IVA (DSP) module, in terms of speed. Is that right? In the second line of though, we found that many of the operations which can be done with the camera ISP can both be done in the raw input pipeline, or from memory to memory. However, we assume that memory to memory operation is slower because it requires more cycles to read and write to/from memory... or is it not the case because the processing has such clock timing that memory read and write operations can be pipelined so image stream processing can still be done with [virtually] no penalty for memory to memory operations? (like if processing of the next pixel can be done while writing the previous pixel to memory, for example). Also related to this is the third line of analysis. How many (extra) memory copy operations will we have to do in the whole processing pipeline. For example, GigE data will have extra packet headers interleaved with image data. Can the ISP operations deal with this in memory to memory operations? for example, for previewing and resizing. I can imaging the ISP to just munch the Ethernet header bits as if they were image data, and then a higher level algorithm discarding it, is it possible? are there any other possibilities? like using the inter-frame (vertical sync) or inter-line (horizontal sync) or regions, to leave the packet headers completely out of the processing pipeline? Apparently, the Camera ISP is a very valuable resource when it comes to streamlining the image processing pipeline, but we still need to have a more complete picture to decide whether the dedicated hardware interface is truly the only option we have. We also have the possibility of reimplementing some of the features in external FPGAs (that we already have in the image path), but it's adding more complexity to the system, and we'd rather avoid it (although I can foresee how complicated all the software would be to take full advantage of all the features available in the OMAPs. ok, enough said for one email, we'll really appreciate any comments. thanks! gera ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users |