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
So you have a PIC and you have decided to interface ANYTHING to it. Waht is the rest of the board going to have on it OTHER THAN the PIC, which is the WRONG device for this type of application.
First what memory do you have on your PIC?
If less than 80K bytes do not even bother attempting this. The picture comes out of the camera as a set speed data stream that a PIC will have trouble keeping up with, and if you do not have enough memory to store the image size you want then you will LOSE the picture information.
Oh look the pic16f876A has 368 bytes of RAM.
Second what image size do you want?
Third have you done the BASIC MATHs of working out how many bytes of data a camera produces?
Do this simple calculation
Width x Height of image is number of greyscale BYTEs for 8 bit data
If you want colour information
Take the size above and multiply the answer above by TWO or THREE to give image size in BYTEs in memory that will be needed depending on colour format.
Fourth, you do have access to a web camera or digital camera look at the size of a COMPRESSED image as a file then realise to compress the image this has to use RAW data as 24bit data (three bytes per pixel) and realise you do not have enough memory to save the image BEFORE writing to flash.
Fifth have you seen what speed you can write to Flash memory?
if you expected to take data from camera direct and store it to Flash, please inform us of the Flash part number that can write at the speed needed as to my knowledge no one has made one yet!
For a comparison see how long a digital camera takes to store an image before you can take another picture.
If you are not going to compress an image before storing you need more data storage area (Flash) and longer time to save image.
Please understand what you are trying to interface to BEFORE deciding which microcontroller you are going to use.
Yet another example of Video to PIC, akin to squeezing the Atlantic Ocean into a Pint Pot.
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
PC Services
GNU H8 & mailing list info
For those web sites you hate
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
-- "it's the network..." "The Journey is the reward" speff@interlog.com Info for manufacturers: http://www.trexon.com Embedded software/hardware/analog Info for designers: http://www.speff.com
The best he could do with that PIC is trigger a Digital Camera that has its own Flash storage.
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
PC Services
GNU H8 & mailing list info
For those web sites you hate
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:
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.
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.
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.
For taking images of STILL objects that do not move for a LONG time.
The PIC especially the PC16F is NOT the right device for the job.
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
PC Services
GNU H8 & mailing list info
For those web sites you hate
Uzytkownik "peres" napisal w wiadomosci news: snipped-for-privacy@h48g2000cwc.googlegroups.com...
Hi!
Maybe this will be usefull for you
best regards
-- Pelos http://www.pelos.pl
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
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.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
PC Services
GNU H8 & mailing list info
For those web sites you hate
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.
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.have you looked at the CMU cam?
-howy
peres wrote:
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.