have you looked at the CMU cam?
http://www.cs.cmu.edu/~cmucam/home.html
there is another one like this out there but I cant remember what its
called.
-howy
peres wrote:
> Hi, i need only to store a picture when an event happens, i want to do
> it with a pic16f876A, i dont need to do any kind of image processing i
Reply by ●July 25, 20062006-07-25
peres wrote:
> Hi, i need only to store a picture when an event happens, i want to do
> it with a pic16f876A, i dont need to do any kind of image processing i
> think, just take a picture and store it into a flash, so my question is
> what cmos camera do you recomend for this?
A number of years ago I used a black and white (well, 8 bit grayscale
actually) module with a PIC. The module (sorry, can't find a link) had
8 data bits out and a pixel clock which I was able to use to clock a
binary address counter. The address counter was interfaced with a
static RAM so the data was copied into the RAM in real time. The PIC
then read the data out of the RAM at it's much slower speed and
compressed and sent the data over a serial port at up to 56Kbaud. I
would think that with the 18 series PIC's you could do better.
Reply by techie_alison●July 25, 20062006-07-25
"peres" <beto.barba@gmail.com> wrote in message
news:1153590062.042147.200630@h48g2000cwc.googlegroups.com...
> Hi, i need only to store a picture when an event happens, i want to do
> it with a pic16f876A, i dont need to do any kind of image processing i
> think, just take a picture and store it into a flash, so my question is
> what cmos camera do you recomend for this?
>
> thank you in advance
>
Erm, think dsPIC and dumping the image straight into SRAM. Aside from that,
a 16f pic can do 20Mhz tops which is 4,000,000 single cycle instructions per
second. Definitely would need a dsPIC to handle this, and then you have to
put the data somewhere. Some of the top end pics 'could' store this
internally as they have enough RAM, and also you can write to the program
ROM, although the problem there is EEPROMing into that ROM.
dsPIC and SRAM. Might just be possible with one of the 18f's overclocked at
60Mhz, that'd give u.... 60,000,000 / 4 = 15,000,000 single cycles
instructions per second. For a 5MIPS stream as has been already mentioned
that only gives you 3 cycles per chunk of data coming from the camera.
yep, dsPIC and SRAM, using the dsPIC to simply oversee the control lines of
the SRAM as the data is being dumped into it. Then you're in a position to
chug that data out over a 9,600 RS232 line if you really wanted. 16f's will
barely keep up with anything data intensive, a 16f628a can barely manage a
PS2 mouse.
Reply by ●July 25, 20062006-07-25
On 24 Jul, in article
<1153788222.114025.278700@b28g2000cwb.googlegroups.com>
beto.barba@gmail.com "peres" wrote:
>which microcontroller will be good for the job?, just need to store a
>320*240 8-bit grayscale still image ... thats 76,800 bytes. which
>controller do you recommend?
How the problem is approached depends on MANY factors
1/ pixel resolution and depth (bits per pixel)
2/ Is the object moving or not (not = rock solid still)
3/ how many images are to be captured (update rate)
4/ How fast does the individual images have to be captured
bearing in mind lighting levels, exposure time, lenses
and object characteristics.
5/ How the image is transferred and to what device or comms link
is another issue determining system configuration and hence
controller.
>im seeing the rabbits which had lots of RAM but i dont have any
>experience in them... what do you recommend for the job?
Most 8/16 bit controllers do not have a bus or ports fast enough to
capture continuous data at 5MB/s and greater so the choices are
a) use external frame grabber/field memory to grab whole frame
into fast memory and readout slowly. Can be done with CPLD
and SRAM chip.
b) Use some form of successive capture using fifos for n lines
at a time, often needs CPLD or similar to accurately time
acquisition of line starts to fifo.
c) Use some form of successive capture to grab specific pixels
in multiple lines which requires accurrate timing to grab the
pixels on each frame from different portions of a line.
The controller really must have the ability to address memory either as a
large window of the memory of the external stored frame or the whole frame.
Considering the delays and complexities of dealing with windowed frame stores
or successive frame capture it is generally easier and overall cheaper in time
and money to use an external whole frame store.
It is usually easier to use a controller that has an address bus larger than
16 bits and be able to access the memory via a CPLD from the controller or
by the CPLD writing to the memory when acquiring the image. It does not
require a large device to do this. The amount of special registers that have
to be created to control the grabber/dual port frame store is miniscule and
adding an interupt o/p to signify end of frame capture is useful.
By using bidirectional buffer chips (e.g. 74xx245) between the SRAM and the
controller and the camera interface only a few enable signals are required
from the CPLD to control data flow if size of CPLD is an issue.
The controller really needs to have 4KB or more of internal RAM for your
system and buffering or conversions of data prior to transmission
The main thing is keep the Video data memory as external to the controller
chip for most small controllers. If you have some fancy large chip with
a camera controller ensure its bus can transfer the data and will not
cause other issues like watchdog or similar problems. The other issue
with larger controllers is which memory is being written to (internal/external)
and does it require to go through special memory controllers (e.g.SDRAM)
and what effects that will have.
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.gnuh8.org.uk/> GNU H8 & mailing list info
<http://www.badweb.org.uk/> For those web sites you hate
Reply by Meindert Sprang●July 25, 20062006-07-25
"peres" <beto.barba@gmail.com> wrote in message
news:1153788222.114025.278700@b28g2000cwb.googlegroups.com...
> which microcontroller will be good for the job?, just need to store a
> 320*240 8-bit grayscale still image ... thats 76,800 bytes. which
> controller do you recommend?
> im seeing the rabbits which had lots of RAM but i dont have any
> experience in them... what do you recommend for the job?
I once designed a board with a CPLD providing addresses for a 128kbyte SRAM.
Clocked by the pixel clock and reset by the frame sync, the CPLD constantly
stored an image in the SRAM. An 8051 was connected to the same databus as
the camera/SRAM and could read out the image sequentially, the CPLD also
contained sync logic to honor a "busrequest" from the 8051 at the next
framesync. So my making the framegrabber a separate entity, any micro could
do this trick..
Meindert
Reply by peres●July 24, 20062006-07-24
which microcontroller will be good for the job?, just need to store a
320*240 8-bit grayscale still image ... thats 76,800 bytes. which
controller do you recommend?
im seeing the rabbits which had lots of RAM but i dont have any
experience in them... what do you recommend for the job?
Reply by Pelos●July 24, 20062006-07-24
Uzytkownik "peres" <beto.barba@gmail.com> napisal w wiadomosci
news:1153590062.042147.200630@h48g2000cwc.googlegroups.com...
> Hi, i need only to store a picture when an event happens, i want to do
> it with a pic16f876A, i dont need to do any kind of image processing i
> think, just take a picture and store it into a flash, so my question is
> what cmos camera do you recomend for this?
On Sunday, in article
<sMMwg.47109$Uy1.32559@read1.cgocable.net> news12@ziak.com
"Roman Ziak" wrote:
>Spehro Pefhany wrote:
>> On 22 Jul 2006 10:41:02 -0700, the renowned "peres"
>> <beto.barba@gmail.com> wrote:
>>
>>> Hi, i need only to store a picture when an event happens, i want to do
>>> it with a pic16f876A, i dont need to do any kind of image processing i
>>> think, just take a picture and store it into a flash, so my question is
>>> what cmos camera do you recomend for this?
>>>
>>> thank you in advance
>>
>> That's a bit high bandwidth (say 4MHz for pretty good resolution) for
>> a 5MIPS (max) PIC to sit between the camera and an external flash. If
>> you sampled one pixel per line per frame, it would be very slow (5 or
>> 10 seconds to capture a frame). You probably need something around an
>> order of magnitude faster to capture an entire (relatively)
>> high-resolution image in real time.
>>
>>
>> Best regards,
>> Spehro Pefhany
>
>For academic reasons let's try different calculation:
>
>Say we do not need color (a security camera) and we have a 320x240
>sensor resolution (75k image). Maximum speed of data stream from/to
>PIC16F876 over SPI is 5Mbps, which may be achievable.
When doing nothing else.
It is not getting the data OUT of the PIC that is your main problem, getting
the data IN and being sure you can build up an image over several frames!
The data for a frame of 75k BYTES normally output as clocked parallel
data stream at upto 60fps (dependent on camera chips used). Most camera
devices clock this data out using a clock of between 10 and 30 MHz, so you have
to accurately grab EVERY byte in sequence or specific bytes on particular
lines over succesive frames.
This particular PIC only has 384 bytes of RAM so even if you could get
the data in correctly (WITHOUT external acquisition hardware), you could
get ONE pixel per line per frame so you will have to acquire 320 frames
to get the full frame. ===
320 frames at 60fps is 6 seconds, at 30fps it is 12 seconds, assuming
nothing went wrong.
The PIC is not fast enough to acquire 320 pixels in one line without
external stores and hardware.
You would need an external frame store to capture the whole frame to read out
the frame VERY SLOWLY.
>So we *could* download an image in 125ms, but we have to send it to
>another SPI device and we have only one SPI on our micro. Another 125ms
>and we are at theoretical 250ms shutter speed but it will get slightly
>higher with SPI protocols overhead and sectoring.
Even if the shutter time was 250ms (which is not possible on a lot of
camera chips), that means the 'event' better be STATIONARY. You have NOT
factored in the 'how to capture the data' in the first place. Let alone
that even if the data rate from the camera was 5MHz BYTES, you are suggesting
serialising to 5MBITSper second, which means you will fall behind the input
data rate VERY quickly. Therefore you will have to take the data as
specific bytes from repeated frames.
>Although this does not answer the OP question about the camera or sensor
>selection, it would have been nice challenge for Microchip contest some
>5-10 years ago, when 16F was cool.
> On 22 Jul 2006 10:41:02 -0700, the renowned "peres"
> <beto.barba@gmail.com> wrote:
>
>> Hi, i need only to store a picture when an event happens, i want to do
>> it with a pic16f876A, i dont need to do any kind of image processing i
>> think, just take a picture and store it into a flash, so my question is
>> what cmos camera do you recomend for this?
>>
>> thank you in advance
>
> That's a bit high bandwidth (say 4MHz for pretty good resolution) for
> a 5MIPS (max) PIC to sit between the camera and an external flash. If
> you sampled one pixel per line per frame, it would be very slow (5 or
> 10 seconds to capture a frame). You probably need something around an
> order of magnitude faster to capture an entire (relatively)
> high-resolution image in real time.
>
>
> Best regards,
> Spehro Pefhany
For academic reasons let's try different calculation:
Say we do not need color (a security camera) and we have a 320x240
sensor resolution (75k image). Maximum speed of data stream from/to
PIC16F876 over SPI is 5Mbps, which may be achievable.
So we *could* download an image in 125ms, but we have to send it to
another SPI device and we have only one SPI on our micro. Another 125ms
and we are at theoretical 250ms shutter speed but it will get slightly
higher with SPI protocols overhead and sectoring.
Although this does not answer the OP question about the camera or sensor
selection, it would have been nice challenge for Microchip contest some
5-10 years ago, when 16F was cool.
>On Saturday, in article
> <73c5c21m33a913i5ttqkqd4pv8er18vucu@4ax.com>
> speffSNIP@interlogDOTyou.knowwhat "Spehro Pefhany" wrote:
>
>>On 22 Jul 2006 10:41:02 -0700, the renowned "peres"
>><beto.barba@gmail.com> wrote:
>>
>>>Hi, i need only to store a picture when an event happens, i want to do
>>>it with a pic16f876A, i dont need to do any kind of image processing i
>>>think, just take a picture and store it into a flash, so my question is
>>>what cmos camera do you recomend for this?
>>>
>>>thank you in advance
>>
>>That's a bit high bandwidth (say 4MHz for pretty good resolution) for
>>a 5MIPS (max) PIC to sit between the camera and an external flash. If
>>you sampled one pixel per line per frame, it would be very slow (5 or
>>10 seconds to capture a frame). You probably need something around an
>>order of magnitude faster to capture an entire (relatively)
>>high-resolution image in real time.
>
>The best he could do with that PIC is trigger a Digital Camera that has
>its own Flash storage.
Especially the older models that have a serial interface might be
interesting. It should be possible to find them second hand.
Resolution is usually limited though on older models. The Nikon
Coolpix ones might be the exception.
Have a look here:
http://photopc.sourceforge.net/