Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.arch.embedded > #27018

Re: Camera I/F's

From Dimiter_Popoff <dp@tgi-sci.com>
Newsgroups comp.arch.embedded
Subject Re: Camera I/F's
Date 2017-07-09 01:53 +0300
Organization TGI
Message-ID <ojrnif$n60$1@dont-email.me> (permalink)
References <ojr6lv$188$1@dont-email.me> <ojr85a$64m$1@dont-email.me> <ojrfqb$t70$1@dont-email.me>

Show all headers | View raw


On 08.7.2017 г. 23:41, Don Y wrote:
> Hi Dimiter,
>
> [Still 40+C every day.  18 consecutive days with a high temperature
> above 40C.  Those huge icicles sure would be nice right about now!  :> ]

We had 2-3 hot days (up to 38C) and then a cold wave came, now we are
below 30. Pretty good during the day but the nights get below 20C,
pretty unusual for July here. All that with the very long winter we had,
average annual temperatures will likely be way below the norm.

>
> On 7/8/2017 11:30 AM, Dimiter_Popoff wrote:
>> On 08.7.2017 г. 21:05, Don Y wrote:
>>> I hacked together my "IP cameras" using some web cams for which I was
>>> able to track down some FOSS i/f implementation documentation.  This
>>> was OK for a proof of concept.  But, I now have to settle on
>>> "production"
>>> hardware.
>>>
>>> There seem to be a variety of i/f's for cameras:
>>> - RS170 (requires hardware to digitize the signal; inflexible)
>>> - parallel (video is digized, just needs to be captured at pixel rate)
>>> - USB (digitized but packed in proprietary transport protocols over USB)
>>> - CSI (digitized with specialty hardware required in host)
>>> - IP (digitized but packed in protocols over IP)
>>>
>>> The USB option is the easiest from the host's *hardware* point of view.
>>> But, seems to limit the devices that could be supported as camera
>>> vendors are loathe to publish details that only *their* driver
>>> implementers
>>> should need.
>>>
>>> RS170 is... "passe"
>>>
>>> Parallel requires lots of signals to/from the host/camera.
>>>
>>> CSI seems to be primarily supported on hosts intended to address the
>>> mobile market.
>>>
>>> As USB is essentially "free" (hardware-wise), adding support for it as
>>> an *alternative* interface seems prudent.
>>>
>>> Relying on CSI seems like it will restrict my choice of processor(s)
>>> going forward (I'd like to standardize on *a* host platform and not
>>> have to support a variety) -- though that's where the volume lies
>>> (think camera in cell phones).  OTOH, it may make getting components
>>> difficult (small fish, etc.)
>>>
>>> IP seems to have more costs than USB with little/no gain.
>>>
>>> Anyone been down this road who can share experiences?  Probably
>>> only looking at 10K/yr...
>>
>> The obvious choice would be the MIPI cameras - like in every phone.
>
> Yes, MIPI being the backers of the CSI approach.  Its great appeal
> is so few conductors to the camera and megapixel support!
>
>> A few years ago I looked into that; I found out they (MIPI) had some
>> special (politburo) membership fee if you were a "small enterprise",
>> "small" meant if you had < $100M annual revenue IIRC...
>
> I'd be more worried about actually getting *parts* than "specs"
> (which is what the "membership fee" provides).  There's a point
> (sales volume) below which folks addressing markets with HUGE
> customers simply don't want to be bothered.
>
> Or, you worry about the part being "on allocation", etc.

I don't see how I can get to these worries. The CSI specification is
"members only".
Then this market is so huge there will always be some stock unless
you are after the latest versions. Or if you want to go into the
volumes of say Samsung but in this case you'd have allocation
issues whatever type you go for, probably worse than with mipi.

Dimiter

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Camera I/F's Don Y <blockedofcourse@foo.invalid> - 2017-07-08 11:05 -0700
  Re: Camera I/F's Dimiter_Popoff <dp@tgi-sci.com> - 2017-07-08 21:30 +0300
    Re: Camera I/F's Don Y <blockedofcourse@foo.invalid> - 2017-07-08 13:41 -0700
      Re: Camera I/F's Dimiter_Popoff <dp@tgi-sci.com> - 2017-07-09 01:53 +0300
        Re: Camera I/F's Don Y <blockedofcourse@foo.invalid> - 2017-07-09 09:21 -0700
  Re: Camera I/F's Joe Chisolm <jchisolm6@earthlink.net> - 2017-07-08 17:06 -0500
    Re: Camera I/F's Don Y <blockedofcourse@foo.invalid> - 2017-07-09 09:46 -0700
  Re: Camera I/F's Paul <paul@pcserviceselectronics.co.uk> - 2017-07-09 11:58 +0100
    Re: Camera I/F's Don Y <blockedofcourse@foo.invalid> - 2017-07-09 09:55 -0700
      Re: Camera I/F's Theo Markettos <theom+news@chiark.greenend.org.uk> - 2017-07-10 10:09 +0100
        Re: Camera I/F's Paul <paul@pcserviceselectronics.co.uk> - 2017-07-10 12:27 +0100
          Re: Camera I/F's Theo Markettos <theom+news@chiark.greenend.org.uk> - 2017-07-10 19:36 +0100
        Re: Camera I/F's Don Y <blockedofcourse@foo.invalid> - 2017-07-10 12:56 -0700

csiph-web