The question of openmv version

169 views
Skip to first unread message

TO ROBOT

unread,
Feb 26, 2015, 9:14:08 AM2/26/15
to open...@googlegroups.com
Hi

In https://github.com/iabdalkader/openmv/tree/master/eagle , I found openmv1, openmv2, openmv3 three versions.
1.openmv1 using STM32F407 chips.
2.openmv2 using STM32F429 chip and use SDRAM.
3.openmv3 using STM32F407 chips.
4. In your kickstarter website, the hardware is used STM32F429, do not use SDRAM.

But you have only one source code, I see there are a makefile choice (49 lines to 53 lines), there openmv1 parameter is DSTM32F407xx, default is DSTM32F429xx.

My question is:
1.Above four hardware versions can use your source code (https://github.com/iabdalkader/openmv)?
2.In openmv2 ,SDRAM without any use?(makefile no choice SDRAM)

I'm sorry ,my English is so bad.

Ibrahim Abdelkader

unread,
Feb 26, 2015, 9:56:32 AM2/26/15
to open...@googlegroups.com
I replied to you on github, will copy my reply here too:
"

Hi, to confirm we will use openmv3 and an STM32F429/180MHz (they are pin compatible) OMV3-code is Not in the repo yet, I've been working locally, until I figure out what to do with all the mess of different versions.

With some hacking you can get the code to work on OMV3 (if you build one)

SDRAM code will build when BOARD=OPENMV2 is passed on the command line"

David Jun

unread,
Mar 8, 2015, 4:14:58 PM3/8/15
to open...@googlegroups.com
Hi, awesome project! looking forward to watching your progress. i don't know if you explained this somewhere already, but what was the reason for taking off the sdram on version 3? seems like having the extra memory would be useful for developers.

Ibrahim Abdelkader

unread,
Mar 8, 2015, 4:49:53 PM3/8/15
to open...@googlegroups.com
Adding the SDRAM is actually a big deal, it might not look like it at first look, but keep in mind that it's only available on the LQFP176 and bigger packages, so we'll need to upgrade to a more costly MCU, and it will need  more room, which means a bigger/ more expensive PCB, and it also has to go on the back side, so double sided assembly, when you add up all those costs the cam might end up costing close to 2x.

Plus there's enough routing space and I/O to connect only 8-bits of the data bus, I could (and should) cache stuff in SRAM but just saying it's not even making the best use of the bus.

nick shrake

unread,
Mar 15, 2015, 9:57:31 PM3/15/15
to open...@googlegroups.com
Hi Ibrahim,

Looking at your Eagle schematic for OpenMV2 it looks like you are using STM32F429 with LQFP144 part.  

Kind of figured you based this on the stm32f29i-disco board which uses the STM32F429ZIT6, a LQFP144 part that has the IS42S16400J instead of the IS42S16800E you were using.  A  

Maybe a recommendation for future but why not just make room for a SDRAM part on backside and a do-not-populate in assembly so people could manually solder the SSOP part on.  Alternatively, you could offer two version.

Is there a document or posting you could make on how you are able to put all this image data coming in using DMA into the small 256 kB SRAM buffer.  I realize you are setting the OV2640 to a JPEG mode but I don't understand how I can write an OpenMV script to capture higher resolution mode without overflowing buffer ... yet OpenMV is able to capture to SD card these large images.  I just thought DRAM would be required if operating camera in normal RGB565 mode.

Keep up good working, my beta camera is working great and looking forward to Kickstarter release!

Thanks,
Nick

Ibrahim Abdelkader

unread,
Mar 15, 2015, 10:12:07 PM3/15/15
to open...@googlegroups.com
Nick, that's right it's actually LQFP144 I said LQFP176 before I was wrong, but the point is SDRAM will need more than LQFP100, and it's not based on Disco board, see my comment above, basically just 8-bits of data are connected, also I can't just add the footprint because it will still need bigger PCBs and an upgrade to QFP144 etc..

JPEG images don't take that much RAM (at least all res lower than 2MP) the highest resolution still fits though, but you may need to lower the quality if it overflows, RGB takes a lot more so it's limited to the RAM on the MCU.
Reply all
Reply to author
Forward
0 new messages