Specifically for an XScale based processor:
http://www.arcom.com/pc104-xscale-viper.htm
So a PC104, USB, or TCP/IP solution would be great, provided either
drivers already exist, or useful source is available, or a decent
specification is available from which I could write my own driver (I am
comfy with TCP/IP & USB, writing my own PC104 driver might be a stretch).
The hardware also needs to be smallish (PC104-sized is good; rackmount
frameserver is bad).
TIA,
5thWheel
> Does anyone know of any framegrabber/ video capture hardware that
> can be used with CE.Net (4.2, but I can upgrade I guess). We have
> a standard composite/s-video camera and we only need to be able to
> capture (preferably colour) stills (say, 1 every 5 minutes or
> whatever, there is no requirement for movie-like capture).
>
> Specifically for an XScale based processor:
> http://www.arcom.com/pc104-xscale-viper.htm
>
> So a PC104, USB, or TCP/IP solution would be great, provided
> either drivers already exist, or useful source is available, or a
> decent specification is available from which I could write my own
> driver (I am comfy with TCP/IP & USB, writing my own PC104 driver
> might be a stretch).
>
If you want to use an X-scale based solution, the PXA70 has a video
capture interface (QCI) that can grab images directly from a CCD or,
using an appropriate interface (ex: ADV7181 or other chips from
philips) from a composite or s-video input signal (up to 6 input for
the above chip, IIRC).
I used it for video-capture and it works well.
Using the PXA27X native YUV overlay you may "redirect" the captured
data to the display via DMA and this will lead to a full-frame rate
at PAL (704x576 or 720x576) resolution. The frame rate is fine (15-20
fps also with the image scaled to CIF or QCIF resolution).
Don't expect very high frame rates if you need to scale and compress
the image, but if 6-7 QCIF frames per second are ok for you, that
would be a reasonable solution.
If you need to capture still images using a CCD, the PXA can reach
2048x2048 pixels as its highest resolution (non much for a digital
camera, more than enough for surveillance applications...).
Other ARM-based processor (from freescale and other manufactures)
have similar interfaces.
Using USB could be a problem if the camera must be more than 2 meter
from the board and I think that you'll have to code your driver to be
compatible with a single model (or family) of cameras.
Using a TCP/IP camera gives you more freedom about placement of the
cameras (you may even use wireless networking), but the cameras would
be more expensive than regular closed circuit video cameras or
consumer USB webcams.
The TCP/IP and USB solutions may be more portable and less dependent
on the hardware solution you choose but, the USB solution, at least,
could be tied to a specific camera or camera manufacturer.
--
Valter Minute
vmi...@inwind.it (the reply address of this message is invalid)
Thanks for the info, I've noted it all down for future reference but for
right now I guess I wasn't clear enough that we've already bought lots
of "Viper" boards (http://www.arcom.com/pc104-xscale-viper.htm) and need
something that is specifically compatible with that.
Our camera is going to be in the same box as our processor board, so
there is no problem with cable lengths. I suggested USB/TCPIP as I am
more confident of being able to write my own drivers for these
interfaces, but so far I've been unable to find any hardware with enough
specification documentation to allow me to do so (I am right now looking
at USB protocol analysers, ugh).
Thanks again,
5thWheel
-------x
[...]
> Thanks for the info, I've noted it all down for future reference
> but for right now I guess I wasn't clear enough that we've already
> bought lots of "Viper" boards
You talked about generic XScale processor and not about the pxa255, so
I thought that you still haven't bought the boards.
> (http://www.arcom.com/pc104-xscale-viper.htm) and need something
> that is specifically compatible with that. Our camera is going to
> be in the same box as our processor board, so there is no problem
> with cable lengths. I suggested USB/TCPIP as I am more confident
> of being able to write my own drivers for these interfaces, but so
> far I've been unable to find any hardware with enough
> specification documentation to allow me to do so (I am right now
> looking at USB protocol analysers, ugh).
>
AFAIK there's no standard protocol to control web-cams. Most digital
cameras provide a USB-mass storage interface to allow the downloading
of pictures without the need for drivers on the PC, but you need to
control the camera (taking pictures when needed) and this could not be
accomplished using mass-storage interface.
You may try to check if there are web-cams driver provided for linuxx
or other operating systems and check if you can find some useful
documentation about the protocol (using the code may be restricted by
the licence).
Many TCP/IP cams come with an embedded web server that allows you to
configure the camera and download the pictures. Interfacing with the
web-server from a CE application is not very difficult and the images
are usually provided in a standard format (jpeg), so you don't need to
decode them (you may have to do that for USB cameras).
But usually TCP/IP cams come at an higher price.
I have since found that the flygrabber_cf has a problem with the driver under CE.Net 4.2 (presumably
under all 4.x) whereby the preview & capture buffers go completely green requiring a power-cycle to
fix (I am anyway 90% certain the problem is with the driver, as LifeView list a fix for an analogous
problem with an analogous product). Lifeview don't seem to have any interest in fixing the -CF
driver, however (I would categorise the level of support they provided as "useless").
The grabber works fine unless something makes the system "Busy", so if all you are doing is grabbing
you are probably going to be ok (I suspect that a shared IRQ is going off too often or something and
the flygrabber driver is getting confused by it, but that is a total guess).
We're perhaps going to develop our own tiny USB/IP capture solution, will post if that ever happens:)