SparkFun Forums

[brijesh]

The boards and all the components have arrived !!!!!

DSCN1609.JPG

I will be soldering the components this weekend. Meanwhile I have looked into software aspects of the project. Couple of things I would like to discuss

1) Compiler and IDE: The only full featured and free version of IDE that I have found is http://www.CooCox.com. I have downloaded it and poked around a bit, I looks good so far. Do you guys have any other suggestions?

2) RTOS or No RTOS: Should we use a RTOS or do bare metal programming?

3) Communication Protocol: What kind of communication protocol should be used between Vision Module and embedded device?
a) CMUCam 4 has ASCII based terminal like interface. It is easy to use in a interactive mode with a terminal, but not so good when it is used to used through a program or microcontroller.
b) PIXHAWK UAV project has a well defined protocol MAVLink. Looks interesting, but will require some work to port it for our use.http://qgroundcontrol.org/mavlink/start
c) Anything else out there??
d) Develop our own simple protocol tailored for our application.

Appreciate your thoughts and comments.
Cheers

[tomcat]

Hi,

Great that the boards are here. I'm looking forward to getting my hands on one of them to start playing around with it.
Here are my comments to your questions:

(1) I don't know CooCox (and I'm not likely going to use it since there seems to be no Linux version). I've successfully used Eclipse with the Code Sourcery Lite ARM Toolchain with my STM32F4 Discovery.

(2) I'm a bit undecided here. So far I've used the STM32F4 as bare metal only. But I do see the potential advantages of an RTOS. I noticed that the Olimex STM32F4 boards are supporeted by Chibios (http://chibios.org/). But I have no experience with that.

(3) MAVLink looks interesting. I do not think that porting would be too difficult. My understanding is that in the end you get a bunch of C structs that represent your messages plus some additional functions for data (de-)serialization (un-(packing)). Looks like a reasonable approach. And using Python on the PC side also looks like an attractive option.
Something similar would be the Google Protocol Buffers library (https://developers.google.com/protocol-buffers/). It also generates messages in (targeting different programming languages) from a language independent description. But as far as I saw it does not offer support for plain C (but only C++, Java and Python).
Overall I think that we probably should use something that is efficient. Human readability when on the wire (as the CMUCam ASCII approach) is not my primary target.

Just my thoughts...
Thomas

[brijesh]

Hello Thomas,

I am also pretty excited and can't wait to start playing around with the board.

1) CooCox is also based on Eclipse. Then again any IDE will work as long as you know how to setup project parameters and get the code to compile. This is more of an issue to people who are totally new to STM32F4 and want a solution that works without them having to worry about compiler settings etc.

2) My thoughts are similar to yours. My first instinct is to just go with bare metal programming and worry about RTOS when project becomes complicated enough to need one. This topic will invariably be brought by someone or the other, so good to have have everyone on the same page and have a clear direction.

3) I spent sometime trying to find what is the effort in porting MAVLink, I did not make much headway. I MAVLink has lots of features we don't need like multiple devices etc. It will probably take some time to really understand the MAVLink implementation and port it to your needs.
The other option is to use something simple. I have a super simple protocol that I use for SimPlot. http://www.negtronics.com/simplot
We could adapt that protocol since I will be using SimPlot of display images and as GUI to setup and debug the vision module.

The main design issue I am struggling with is what type of protocol.
1) Message based protocol like MAVLink, where reading/writing to each parameter will have unique message. Ex. MSG_SET_PARAM_FOO1, MSG_SET_PARAM_FOO2. We will end up having lots of messages and these messages will be unique to a project. They are not portable.
2) Index based protocol, where you read/write to a index in table. The table holds the parameters. Ex. write(index,value). Very potable. The definition of table changes from project to project. The table may hold mixed data types, like char, int, float etc. There no wastage of memory cause, memory is allocated to datatype and not the table.
3) Address based protocol, where you read/write to an address. Have to take care of word boundaries and data length. Ex. write(addr,value). This kind of protocol is used by Bioloid Humanoid robot.

I am leaning towards Index based protocol with ability to send/receive messages as well. I am thinking this with long term view. The message protocol has been a trouble in my other projects and would like to develop a simple, generic protocol that can be used in other projects as well.

I have played with STM32F4 board as well. The first thing I did was to work on interrupt driven and buffered serial communication. If it is useful to you let me know I will send you the code.

Cheers
brijesh

[brijesh]

I assembled one board and booted it up. No sparks and no smoke.

http://youtu.be/WMmOL1dPSx4

[tomcat]

Very Cool! I'm looking forward to getting my hands on this!
BTW: The code for the USART would be very interesting for me. My implementation is not yet using interrupts. Additionally I have an issue with the baud rate on my Olimex P407 board. The baud rate seems to be off by a factor of 3 which I confirmed also with a scope. When dividing the baud rate that I set by 3 (e.g., 115200/3) I receive correct data with my terminal application that is set to 115200. I thought that maybe the clock and PLL settings are wrong but I re-generated the system_stmf4xx.c using the Excel sheet from STM (and making sure that the HSE value is set to 25MHz (the p407 board uses and external 25MHz crystal)). Still no luck.

my system_stm32f4xx.c: http://pastebin.com/6HgVRR2k
my simple USART init and test code: http://pastebin.com/0vGCcz2n

Olimex board: https://www.olimex.com/dev/stm32-p407.html

Do you have any idea what the reason for this could be?

Bye,
Thomas

[brijesh]

Check the definition of HSE_VALUE in stm32f4xx.h. That is what I can think of so far. If that value is correct then I guess I would print out the clock configuration values. See the function RCC_GetClocksFreq() from stm32f4xx_rcc.c.

[brijesh]

More progress, I am now able to talk to the camera module via I2C and read/write to registers. I had some issues trying to get I2C to work properly. The culprit ended up being the residual flux. I had used old flux and lots of it while soldering. There was flux residue left over around camera connector. Since the connector is very fine pitch and the flux residue between pins had enough conductivity to mess up the interface. It was puzzling issue and took some time to nail it down.

Now moving forward with getting the STM32F4 DCMI peripheral and capturing the a image. For this have to deal with DCMI and DMA peripherals, both of which are new to me. Has anyone worked with these peripherals before?

The example code from ST shows how to transfer image from sensor to LCD directly. It does not store the image in memory. Have not found any sample code that stored the image in memory, if you guys know of any please share.

Cheers

[brijesh]

Finally, after a lot of head scratching and hair pulling, I managed to capture a decent image. Have not yet been able to capture/display a color image properly. I modified, my SimPlot program to display images.





Some of the troubles I faced
1) Could not get I2C peripheral to work with camera. Ended up implementing I2C protocol using bit-bang.
2) There is no good data sheet for camera module or a good app note. Basically had to find things by trail and error.
3) The camera module sends the 8bits on bits[9:2] and not on bits[7:0]. Because of this image capture ends up using twice as much memory. PCB needs to be modified to fix this issue. :doh:
4) I have weird interrupt issue with USART. (Will send code if someone wants to take a shot at this.)

At this point I guess the core hardware is functional, not it is matter of finding out proper register settings for the camera module and developing rest of the software framework. If anyone is feeling brave and wants the module at this early stage, let me know.

By the way if anyone has any insight on setting up the registers for OV7670, please share. Figuring out the camera module registers has been a torture.

Cheers

[mule]

Have been trying to get something similar working with STM32F4Discovery and OV7670 (also a ebay camera, but not the one you are using). With regards to your queries - Follow this link for a better datasheet for the OV7670:

http://www.trulydisplays.com/ccm/specs/ ... OV7670.pdf

Also see that if you look at v4l linux drivers there are some register configurations that may help in setting these things up for the OV7670. Do a google search for "ov7670.c" and you should get some source code...

Would also like to share learning experiences - think that the STM32F4Discovery is a much easier entry into trying to get something going initially without custom PCB. So far I have been able to get basic I2C and DCMI appears to be working (testing with colour bars) but the colour bars don't seem to be aligning correctly - need to investigate further the reason for this...

[brijesh]

Mule,

Thanks for the link to the data sheet, I did come across that datasheet and have used it. But it is still incomplete and has big holes in explanation on how to use the registers.

I have also managed to get a image of color bar, but colors are not quite right and there is some weird thing going at the boundary between two colors, see the image below


There is that weird green bar between yellow and light blue.

I have come across the file OV7670.h, I have used parts of register setup from the file.

So far I think I full understand the registers related to clock setup, frame setup (VGA, QVGA), image scaling. For some odd reason I get 156x120 pixels frame in YUV mode and 154x120 pixels in RGB mode, those numbers are without messing the capture window registers in OV7670(Vstart, Vstop etc). Did you see something similar?
Also do you know if default RGB mode is RGB 4:2:2? This information is missing in the datasheet.
What are you using to display the image on PC? I have been wondering if there is issue with my program that I use to display image.

[mule]

brijesh,

I am using a two line buffer at VGA resolution with colour bars and get the bars very similar to yours, but with an offset...as I said before trying to figure out why I am getting this offset and why it is not the same every time (have a feeling I may not be getting a clean VSYNC). I think the weird colours between transitions on the colour bars is maybe because the Cb and Cr are shared between two Y values (assuming you are using YUV mode)?

I have not yet applied register settings from the ov7670.c file, rather relying on powerup default configuration which appears to be VGA-YUV-30FPS, my next step is to use the register settings in ov7670.c and see if this improves the framing issues.

The various byte numbers appears to be dependant on the colour mode - i.e. YUV is multiple of 4 bytes and I am guessing that RGB would be a multiple of another, perhaps 2 ?

Not too sure about default RGB mode? Haven't used this mode yet...

I am actually doing picture all manually now - so sending data out and then using some python code (PIL library) to build up an image and then standard windows app to display. Will probably expand on the python app as I make progress with the hardware.

Was also thinking about maybe getting USB CDC to send data across...but still want to get a solid base working first - will update as progress is made.

Mule.

[starfire151]

Please excuse me if this has already been discussed. I just found this forum thread and this is interesting.

Has anyone looked at the FlyCamOne eco V2 as a vision solution? It is capable of still images and video recording directly to a uSD card. The unit is fairly inexpensive at around $40.

It is available from Sparkfun as SEN-11171.

[brijesh]

Finally success!! After a lot of trail and error, finally managed to get register setup that worked. Here are couple of good color images




With this capture, hardware is fully proven. Now have to concentrate on the software. If someone wants the board I still have couple of them that I can ship.

Mule,

Yes, default power-up mode is VGA-YUV{4:2:2]-30FPS. YUV is multiple of 2 bytes not sure what you mean multiple of 4 bytes. That is for a 640x480 image, you get 640x480x2 bytes, unless you are using 10bit DCMI mode. Are you using 10bit DCMI mode?

Using python code to build image and then see it in windows app is lot of work. I have a working program that displays image in real time, currently it is hardcoded for QQVGA-YUV format. If you want I will send you the program and register configuration that worked for me.


Cheers

[mule]

brijesh,

Well done! Those images look good!

With regards to YUV - 4 bytes are sent for every two pixels - (U Y V Y) - although the average is 2 bytes as you say - i.e. 4 bytes / 2 pixels = 2 average. So have to have a multiple of 4 bytes for YUV - i.e. can have U Y - this is not enough information - still need the V to make one pixel. I am using 8 bit DCMI mode.

Yes, python at the moment is a bit of work and adds time to testing code changes - Would really appreciate the working register settings and simplot with image support. Have you got details of the protocol you are using with simplot ?

I tried applying some of the register settings from ov7670.c yesterday and having colour bars switched on - looks like I get the smaller image, but offset still seems to move around, i.e., does not align on the start of memory boundary that DMA is writing to...mmm further experimentation is needed here. Also with smaller image - looks like get only part of the original colour bar sequence - looks like a windowing function rather than a scaling function.

Thanks - hopefully will make some progress soon...

[brijesh]

Mule,

You mentioned the image or rows are offset. What I observed is that with default power-up register settings, when I changed from VGA to QQVGA, instead of getting 160x120 pixels, I got 156x120 pixels. Probably the default VGA mode outputs less number than 640 pixels per line.

Here are four registers that you need to write to get QQVGA output with 24Mhz input clock, lower clock will mean lower FPS.
OV7670_WriteReg(0x0C,0x04); //enable down sampling
OV7670_WriteReg(0x72,0x22); //Down sample by 4
OV7670_WriteReg(0x73,0x02); //Clock div4
OV7670_WriteReg(0x3E,0x1A); //Clock div4

I got a stable and good black and white image with this, I displayed black & white image by just using Y value and assigning Y all the three colors, R=G=B=Y. After I had in a good shape, I played around with color registers.

I have sent you pm, will send you SimPlot and registers through email, do not have project hosting site yet.

Cheers