2012-10-31 11:56 PM
hi:
I have interfaced camera with STM32F4 discovery. currently I am capturing the frame and after the first capture is complete, I disable Camera capture and start sending data from memory over USART2. it sequential. and works fine. now , I want to send data over USART2 at the same time as after each DMA memory location filled by camera DATA. Or i want to send the first frame data from DMA0 buffer while at the same time the next frame data will be filling to DMA1 buffer.(in double buffer mode) is it possible. and how>? any hint.... #dcmi-dma-camera #dma #usart #dcmi #wait-for-you--clive1-!-!-!2012-11-05 01:47 AM
hi,
initially i was using 128x128 image(32768 bytes of data). first i stored that in RAM through DMA then transmit it over USART. it works fine. now i am shifted to 640x480 image. I have data stream of 614400 bytes coming from camera. the RAM did'nt support such a large buffer. image is comming at 60 FPS, i am taking only a snapshot at this rate. so it 614400 bytes data comes at very high rate to DMA. how can i manage such a large and fast stream of data through DMA? I want to transmit data over USART at 115200 bps. is it even possible or not? hope u understand my query! in short i want to transmit data coming from camera, over to USART at 115200 bps. how is that possible? Or i have to shift from usart to SPI for faster communication to avoid data over filling in DMA? thanks2012-11-05 02:02 AM
Doing just a rough estimate, that can't work.
You have input data at >30MByte per second, and an output channel (UART) with about 10kByte per second. It could have worked if you had the RAM to buffer at least one full image - which you haven't.2012-11-05 04:34 AM
2012-11-05 06:40 AM
i just want to transmit one frame of 640x480 yuv image.
The problem is, you don't have enough internal memory to store an image, to send it later on. And the UART is not fast enough to send the data on-the-fly, no matter how large your buffer is.
2012-11-06 12:04 AM
I dont have much experience with Discovery Board (how much ram it has,etc. but I know stm32f2 has enough space to store at least 1 image (640kb) with code, as it has 1MB of flash. You might as well use some compression before you store-send to get even better space efficiency) and apparently I read this thread a bit late, but my suggestion would be to use stack as somehow ''circular buffer'' where you would fill in data from CAMERA from one side, while reading and deleting it with USART on the other. Of course some control of ''camera filling stack'' should be applied (for example risk one integer to check if whole image was sent and then terminate the receiving - which you re-enable after buffer is empty) but you might just pull it off like that.
Otherwise next suggestion is to solder on some flash and use it as temporary storage. Flash is cheap and mostly big enough to easily hand solder.2012-11-06 12:41 AM
Sorry, but this suggestion is illusory.
With the required times for erasing/writing the Flash, it is even slower than the UART. And we don't talk about the limited number of erase/write cycles, nor other technical problems yet (no simultaneous write/code execution at one bank). The Flash and the UART are too slow to swallow about 600kB in 1/60fps = 17ms. And there is no way to circumvent this with a 64kB internal RAM, because they are far too slow. Either use external RAM, or keep the image sizes as small as you can handle.2012-11-06 05:30 AM
He wrote:
i just want to transmit one frame of 640x480 yuv image.
For me, that means he will send 2 to 3 fps in 640x480 and this can be done with flash/internal RAM as ''middle'' man to achieve it. Also a compression would be something to consider here as although it might use some CPU power it will speed up further connections. But as you noted there are some drawbacks of this possibility as usual.
2012-11-06 07:00 AM
And he also wrote:
I have data stream of 614400 bytes coming from camera. the RAM did'nt support such a large buffer. image is comming at 60 FPS, i am taking only a snapshot at this rate. so it 614400 bytes data comes at very high rate to DMA.2012-11-06 11:18 AM
2012-11-06 12:01 PM
The SDIO clock is deceptive, the cards access on a sector/block basis. On an STM32F4 the USB throughput (MSC to SDHC card) is on the order of 700 KBps for reads, and perhaps 460 KBps for writes to a Class 10 Ultra card. I haven't had cause to benchmark it directly, but I don't suppose it is very rapid. Streaming multiple sectors might also help.
Capturing a single frame really needs a buffer capable of holding the entire image. DMA permits transfers of 65535 units of 1, 2, or 4 bytes. Capturing portions will likely result in those portions coming from different frames, which is probably non-optimal.