Just registered here so that I can ask a quick question regarding this cam. It’s not explicitly mentioned in the datash**t, but I assume in JPEG mode that DCLK is used to strobe the data. Can anyone confirm that this is correct?
Reading through the thread it looks like interesting times ahead. Seems to me that the only low-cost way to do this is to blat the data as quickly as possible into memory of some sort, and worry about decoding it all later.
edit>>
Another question: Has anyone tried the Full Mega output without JPEG mode? I know it’s a lot more data, but at least the timing is consistent - unlike JPEG mode, apparently. I should add that I only ordered my modules the other day, so they haven’t arrived yet :(.
Yes, the cam created a DCLK based on your input clock, a divider and it’s pll.
This means that max output clock without PLL is same as input clock.Minimum input is 6 MHz.
You can get the cam to divide down EXTCLK to DCLK by setting low rez outputs and reducing framespeed. 1/2, 1/4 and maby less.
When PLL is active, it tripples the speed. Lowest DCLK I have managed with PLL on is about 8.5 MHz.
PLL must be ON for JPEG mode.
DCLK runns all the time, and data is valid during the high pulse of DCLK and a minimum of 10µs before and after. I recommend using rising edge to trigger if using software to capture data so as to have as much time as possible before data is invalid. If using hardware, latching on falling flank may be better as then the setup-time has been longer.
HBLK is used to tell you when there is valid data. (Only when HBLK is high.)
VBLK is used to tell you that a frame is being transmitted. (Image.) It remains high during the entire image and can be used to synch to start of frame.
Now, if someone could tell me what register to change to get the camera to output a nice image and not just obscure art, I’d be very happy…
So does that imply that for Full Mega output without JPEG you can turn off PLL - in which case you could also reduce the frame rate.
All* you need to do then (according to the data sh**t) is to watch for the VBLK low to high transition, and count 2,928,768 clock pulses (which you’re controlling) capturing bytes until the end of the image. 2.6mb of data later you should have a full-frame uncompressed image.
The problem isn’t synching. That part is very easy.
The problem is:
Where will you put 2.6 MB of data in a microcontroller that only has 8kbyte of memory?
How do you read, store, increment address, check for end of image or count bytes within the alotted time vs your cpu frequency… (My 8-bit avr’s run at 16 MHz or so, and with cam outputting at 6, 3 or 1.5 mbyte/s I then have 2, 4 or 8 instructions pr cycle to do it all in.)
That’s why I am going for a faster mcu with built in hardware for the DMA transfer of the data. Then I can focus on making the system for writing data to SD-cards for my camera project.
KreAture:
The problem isn’t synching. That part is very easy.
The problem is:
Where will you put 2.6 MB of data in a microcontroller that only has 8kbyte of memory?
How do you read, store, increment address, check for end of image or count bytes within the alotted time vs your cpu frequency… (My 8-bit avr’s run at 16 MHz or so, and with cam outputting at 6, 3 or 1.5 mbyte/s I then have 2, 4 or 8 instructions pr cycle to do it all in.)
That’s why I am going for a faster mcu with built in hardware for the DMA transfer of the data. Then I can focus on making the system for writing data to SD-cards for my camera project.
Oh sure, I agree. It just seems like JPEG mode is a bit dead in the water for 2 reasons:
The sporadic nature of the data.
The fact that you have to use PLL which means a massively fast data rate.
Of course, with a Silabs running at 50MHz and 1.5 mbyte/s output we’d have 33 instructions per cycle - perhaps more achievable, no?
I’ll let you know when I’ve run it with the AVR32 at 150 MHz.
I’ll utilize the dma too so I should be able to just trigger the storage for each DCLK. The AVR32 setup I have here has 32 MByte memory so I can easily buffer entire frames, even a short MJPEG clip.
KreAture:
I’ll let you know when I’ve run it with the AVR32 at 150 MHz.
I’ll utilize the dma too so I should be able to just trigger the storage for each DCLK. The AVR32 setup I have here has 32 MByte memory so I can easily buffer entire frames, even a short MJPEG clip.
I’m interested in capturing JPEG data from the camera at full resolution.
I’m now working with a PIC32 that can do 120MIPS at 80MHz (supposedly).
Since it only has 32KBytes of on-board memory, I’m hoping to buffer the image directly to flash memory.
KreAture:
This means that max output clock without PLL is same as input clock. Minimum input is 6 MHz.
…
When PLL is active, it triples the speed. Lowest DCLK I have managed with PLL on is about 8.5 MHz.
PLL must be ON for JPEG mode
So this 8.5MHz corresponds to a EXTCLK a little less than 3MHz. This is under the minimum spec of 6MHz that you referred to, but I guess it’s best to use a 3MHz clock until I can verify that the microcontroller can handle data at a faster rate.
My plan is to set up interrupts based on two sources: HBLK and DCLK
On rising edge of HBLK, enable interrupts on the rising edge of DCLK.
I intended to use a PIC uC together with the image sensor.
anyone have similar setup?
if possible, pse share the details, thanks.
why on earth would you post this message on a thread with 150 other messages explaining why its not possible to store a 640x480x16-bit image in 30k of RAM to people who have asked that exact same question multiple times?
I intended to use a PIC uC together with the image sensor.
anyone have similar setup?
if possible, pse share the details, thanks.
why on earth would you post this message on a thread with 150 other messages explaining why its not possible to store a 640x480x16-bit image in 30k of RAM to people who have asked that exact same question multiple times?
thanks for the reply … I am curious …
did I ever mention I going to store it in the PIC uC ?
i am just using it for processing … maybe sending to USB directly …
