SparkFun Forums

[Twingy]

If you are using the AT91SAM7S then I'm afraid you are out of luck on the DMA. The PDC (DMA) circuitry is only in devices that have a RHR/THR (receive hold register) / (transmit hold register). I think I've got an FIQ based ASM routine that will work with the camera generating a 1.5-2.0 MHz DCLK

[Twingy]

KreAture, hook your scope up to the VD line and tell me what frequency you read.... I've been toying with the external clock and the external clock seems to be driving the VD signal (frame rate) and my testing reveals that changing between 15fps and 30fps in the register settings does nothing. Recall I am using the TCM8230MD and you are using the TCM8240MD. For me the fps setting is in register address 0x2. If operating the external clock at about 2MHz I see roughly 2.6Hz on VD (2.6 fps)... please verify... If this is true then I'm afraid I might not be able to get about 5-6fps after this code is fully optimized using the AT91SAM7S64 without any external hardware. I'm fairly certain we're going to have to bolt on a 64k-512k SRAM module and counter if we're at all interested in supporting the full 30+ fps this camera can deliver. Keep in mind however that at these data rates you're going to want to use the USB or networking peripheral to transfer the data at these rates.

[pellepl]

By the way, normally how big are the jpgs from the tcm8230 and 40 respectively?

[KreAture]

Twingy
You need to read the documentation. It clearly states that the dout, vblk and hblk are functions of system clock and image settigs.
You can manage to get 1/2 1/4 and even 1/16 sysclk as dclk.
This is in RGB mode and is not very practical.

The camera reduces it's output clock when it has very little data to send in RGB mode, but who wants 128x96 ?

In jpeg mode it does not do this.
When PLL is active, it runns at pll/x all the time.

[Twingy]

Kreature you keep forgetting I have a different camera than you. I have the TCM8230MD and there is no PLL hardware. What register on your camera controls DCLK=EXTCLK/2 DCLK=EXTCLK/4 and DCLK=EXTCLK/16?

[KreAture]

You misunderstand.
I am talking about RGB mode just as you.

Based on your selection for image size, the camera will adjust it's divisor for the output clock. In addition, it will deliver the data in bursts and take pauses that will be longer, the less data there is to transmit.

[Twingy]

Unfortunately my camera only operates DCLK at EXTCLK or EXTCLK/2 for all of the modes... So as for right now I must live with DCLK as EXTCLK/2... will keep you posted of my progress.

[rgbphil]

Hi,
I'm tossing some ideas around for a circuit, eventually I'll post it or if anyone knows of a site where a collaborative effort can be done it'll be added there for comment and improvement.

Just need some sanity checking. Can anyone check their interpretation of the datasheet on my assumptions please?

1) The device clock is via the EXTCLK pin, and the internal clock rate can be set with the PLL to various settings via I2C commands

2) When the device outputs a JPEG file (or other image formats) data is presented to the D0..D7 pins and is valid on the rising edge of the DCLK pin which is an output of the device. A data frame or jpeg frame is indicated by a high on the VBLK pin. The HBLK pin indicates the device pausing while it is doing JPEG compression.

3) The DCLK pin is actively clocking along, even when the device isn't doing anything, data is only valid when the VBLK pin is high.

4) We can just take the JPEG output of the imager chip as a valid JPEG file without further processing (assuming we can get the data to a memory card).

So from these assumptions we could build a circuit that takes the VBLK pin and enables a SRAM chip. The DCLK pin can then be used to perform a write enable operation and also clock a binary counter chip (or chips depending on the address space needed). This would automatically clock the data into the ram chip for later retrieval by the micro.

To complete the circuit we need a way to disengage output operations from the imaging chip so the micro can look at the ram. The micro could control the reset of the binary counter chip to reset to the start of the frame, then take over (possibly by a little extra logic) the clocking of the counter, reading it and writing to the SD card as needed.

I can't see a pin to disable output from the imager....so I presume there is an I2C command to do it...does anyone have an idea where the command set for the chip is? I can see a list of registers, but no list of what the register values should be for different operations.

Also any suggestions on a suitable oscillator frequency to clock the imaging chip with?

If the assumptions are wrong, please indicate this and any suggestions you might have.

Phil

[KreAture]

rgbphil
All your assumtions are correct. I think I mentioned using a latch to enable the clocking system on such a design before, maby not on this forum though. Anyway, yes it would work, but would in my opinion add way too much logic/electronics to the system for my taste.

My goal is to make this very small as I will be carrying it on stuff with lifting capabilities of less than 10 grams.

I've finally gotten the docs I needed for the at91sam7 chips now so I will see if I can get them to do the work. The AT91's can be had down to $5 so it would be a neat solution.

[rgbphil]

I just had a quick look at the AT91SAMXXX series of devices....they look pretty high end. It would be a good solution if you can get it to work (a little over my head, I'm just dipping my toes into dsPICs).

One question, the AT91 devices seem to have SRAM capacities of around 32K-160K....which device are you intending to use, given the camera chip will squirt out about 1M of data per frame? Or are you intending to put an external SRAM on the device? If so, can the AT91 handle automatically addressing the data? I'm not familiar with DMA so when you've got a design reasonably solid, a description of the workings would be very educational.

My app is a bit simpler, I'm after something like the lipstick camera like the ATC2000, weight is important (I'll be wearing it on my head)...but a little less important than trying to lift it off the ground with a balloon or small aircraft.

[KreAture]

I want to work in jpeg mode so 1.3 mpix should become 800-900k.
I have no intention to store a complete frame in memory.

The MCU is fast enough to both receive data from the cam and relay it to a MMC or SD card at 20/25 Mbit/s and I am hoping this will be enough.
If not, I'll see if using external ram may be an option but I really wish to avoid it.

[lamont]

I found this AL440B 4 mbit fifo with 8 bit wide inputs and outputs:

http://www.semiconductorstore.com/cart/ ... duct=10565

Getting the DS was a pain, but the sheet seems to claim that the FIFO could take 2.8V as an input from the camera's DOUT, and use DCLK to time the writes to the FIFO. And maybe HBLK (in jpeg mode) could be tied to the write-enable of the FIFO.

Then a microcontroller could read the FIFO at whatever speed you like to pull off at least one frame. Hopefully with enough compression (settable via a magic register) I can fit a frame in 4 mbits.

[KreAture]

The HBLK is used both in JPEG and RGB mode. The camera uses it to maks off the portions of the datastream not containing data in both cases.

In any case one would have to make sure the fifo was not overflowing nor to read when no data was present. With the Fifo delaying the data the VBLK signal is irrelevant so one has no idea when start/end of frame arrives. More logic would thus be needed.

[westhoff]

KreAture,
Just reading these posts for the first time, and only read the data sheet twice so far, so I could be way off base...

Have you thought about running the AVR at 20MHz and using the same clock for the camera? Then you would be synchronous with the camera and could possibly read data quicker.

Otherwise, I like the FIFO idea...

Thanks for all of the hard work you are putting into it!

Where in Norway are you?
Tom

[henryhallam]

Untested Eagle 5.0 footprint and symbol for the TCM8240MD (and some other parts) here: http://www.pericynthion.org-a.googlepag ... _parts.lbr