STM32F2/4 design with camera, external SRAM and some USB host capabilities

[Palauqui.Georges]

Posted on January 12, 2014 at 05:14

Dear All,

We are designing a new product with some specifics needs :- camera interface to a OV2643 sensor- SPI to a CC3000 from TI for streaming MJPEG over Wifi, and doing some other socket light communications- 2 USB Hosts to make Android Open Accessory protocol to an external device, and printing to an externel USB printer (both USB Full Speed).Our first research lead us to the STM32F217, because mainly of its camera interface, that should fit our OV2643 sensor. Specially reading this other

/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/STM3220G_EVAL%20with%20OV2640%20camera&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=1840

 from your forum. The MJPEG stream will be 640x480 only at an estimated framerate of 7-12 fps.The  STM32F217 present also another advantage is the FSMC interface in order to add an external 1MB or so SRAM in order to make DMA transfer from Camera to be sent over SPI/CC3000/wifi/socket (1 JPEG frame will be around 30KB), but also from SPI/CC3000/wifi/socket to be sent over USB to an external Printer (1 PCL file will be around 400KB).For USB Host AOA and Printer class, they are both in AVR LUFA library (successfully ported to NXP ARM Cortex M3 chip), so I hope there is enough ressource in there to make a partial port for the STM32F217. Neither Atmel or NXP chip with LUFA support have Camera interface, that's why I plan to port code from LUFA to STM32. In second option, I will use a Atmel 32bit chip that have LUFA support, but also external SRAM interface and use a dual port SRAM between the AVR32 and the STM32 to exchange the PCL files to be printed (STM32 will still be the SPI master of the CC3000 so it will receive the PCL from socket connection).We post our thoughts here because we are experienceless with STM32 processors, so I hope some experienced people here can advise us on some points.Thanks for all #camera-sram-stm32-wifi-socket

[Tesla DeLorean]

Posted on January 12, 2014 at 13:45

You might want to do some analysis using an

http://www.st.com/web/en/catalog/tools/FM116/SC959/SS1532/PF252216

or

http://www.ebay.com/itm/RedDragon407-STM32F4-Cortex-M4-Ethernet-wireless-2-4G-SDIO-Serial-camera-/121087293812

Download and review the firmware library, USB library, and associated app notes.

[Palauqui.Georges]

Posted on January 14, 2014 at 02:21

Yes Clive1, 

it is exactly what we are goind to do, but during the process of buying these develpment platform, we would like to have some feedback from experienced user about camera capabilities for exemple...

[Palauqui.Georges]

Posted on January 14, 2014 at 08:44Some more informations about design change :First we will use the STM32F417 instead of STM32F217 becaus we may need its power (doing may heavy task in parrallel).Then we will use the OV2640 sensor instead of the OV2643 (currently used sensor) as :- it is the one in the STM32F4xx_StdPeriph_Examples- it has JPEG compression (no need to imprement it on the STM32)STM32F4xx_StdPeriph_Examples / DCMI_CameraExample does a DMA transfer from DCMI to FSMC/mapped LCD. We will do the same but to a FSMC mapped external SRAM to receive the JPEG output of the sensor. Then need to encapsulate the JPEG in HTTP header and feed the CC3000 by SPI to make the MJPEG stream over Wifi. So the week point should be the 16MHz SPI for sending JPEG frame to CC3000 (DMA transfer should be flowless).Question : during these continous DMA access to SRAM for JPEG stream from DCMI, can the Processor still access SRAM for :- reading a JPEG frame to be sent to CC3000 over SPI- writing (elsewhere) some PCL file coming from CC3000 over SPI- reading this same PCL file to be sent to external printer over USBThanks for your review / comments.

[John F.]

Posted on January 14, 2014 at 09:39

Although some STM32 include a camera interface, beware that camera modules are continually increasing in resolution (pixel count) and that the simple parallel interface has largely been abandoned in favour of a serial one.

See

http://www.mipi.org/specifications/camera-interface

for details. Although you can ''glue'' devices together with CPLD / FPGA logic, you may find that the camera module you base your design on ceases to be available in the near future - or only at very high volumes. I suspect that the 32 bit microcontroller families will be rather underpowered for the current and newer camera modules ... alternatively, if we are lucky, the market may shake out so that a simple common module emerges.

[Palauqui.Georges]

Posted on January 14, 2014 at 10:08Dear John F.,your remark about MIPI and DVP is very welcome, specially true for long term project. In our case, our product will be short term life, as it will be upgraded continually with new technologies (like MIPI camera). More, we are based in Hong Kong and in direct contact with camera sensor module manufacturer, it will not be a problem to purchase them (at the beginning at least).Thanks for your thoughts.