Arduin nano 33 ble sense with ov7670 module

Hardware Nano Family Nano 33 BLE Sense
1

Hey guys!

Recently I 've started a project with ov7670 camera module, but I encountered a problem..

I follow this tutorial Machine vision with low-cost camera modules | Arduino Blog and I've checked the connection many times, so there shouldn't be any problem with it,
and I've been using the code directly from the examples of the official library so the code should be ok too..

it suppose look like this

22.PNG

but the reality is....
捕获.PNG

I've been searching for answers all day but just could not find it.....
Does anybody know something about it ? why it turned out like I do? A million thanks ahead!!

22.PNG

捕获.PNG

2

zhupinqi:
I've been searching for answers all day but just could not find it.....
Does anybody know something about it ?

I have the same thing. I have tried a few different pin combinations, but either they don't work or it is the same result. I have looked at the library and it has some interesting things and looks like it has been built specifically for the Nano 33 BLE. I am not sure about the bottom 2 connections RESET and PowerDown, but they don't seem to have any effect.

I assume I have done something wrong or a new library has made a change.

//
// Optimized Data Reading Explanation:
//
// In order to keep up with the data rate of 5 FPS, the inner loop that reads
// data from the camera board needs to be as quick as possible. The 64Mhz ARM
// Cortex-M4 in the Nano 33 would not be able to keep up if we read each bit
// one at a time from the various GPIO pins and combined them into a byte.
// Instead, we chose specific GPIO pins which all occupy a single GPIO "PORT"
// In this case, P1 (The Nano 33 exposes some bits of P0 and some of P1).
// The bits on P1 are not connected to sequential GPIO pins, so the order
// chosen may look a bit odd. Below is a map showing the GPIO pin numbers
// and the bit position they correspond with on P1 (bit 0 is on the right)
//
// 20-19-18-17-16-15-14-13-12-11-10-09-08-07-06-05-04-03-02-01-00 (bit)
// ~ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
// ~ |xx|xx|xx|xx|xx|04|06|05|03|02|01|xx|12|xx|xx|xx|xx|00|10|11|xx| (pin)
// ~ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
//
// The most efficient way to read 8-bits of data with the arrangement above
// is to wire the pins for P1 bits 2,3,10,11,12,13,14,15. This allows other
// features such as SPI to still work and gives us 2 groups of contiguous
// bits (0-1, 10-15). With 2 groups of bits, we can read, mask, shift and
// OR them together to form an 8-bit byte with the minimum number of operations.

3

Just found out it was my windows processing speed with the program processing. Tried it on Ubuntu Linux and it worked fine.

I am going to test if shorter wires helps for using Windows.

4

I'm glad to hear it's working for you now @jerteach!

I'll link to the GitHub discussion in case it provides some additional information that might be helpful to others with this sort of problem:

It looks like a really fun thing to play around with. I have a couple of those cameras on hand, but haven't had the time to try them out yet.