A feature we were excited to see in the SAMD51 microcontroller — the heart of all our “M4” boards — was the inclusion of a Parallel Capture Controller (PCC), a camera interface that can quickly (30 frames/second) pipe images straight into RAM with only negligible work from the CPU. Whenever possible, we’ve designed our M4 boards to make sure all the necessary pins are routed and accessible for this.

While not up to standards we’d demand from a current smartphone or laptop, it’s nicely balanced to the capabilities of recent 32-bit microcontrollers. A SAMD51 has enough RAM for a 320x240 pixel image. Many projects, like basic machine vision, need only a fraction of that resolution.

Now we have an Arduino library to tie these two together, with examples for the Adafruit M4 Grand Central board. But first we’ll show how to modify one of these inexpensive OV7670 carrier boards to interface with Grand Central’s pin headers…

Parts

Items Needed

• Adafruit Grand Central M4
• Adafruit TFT Touch Shield (resistive or capacitive) or 1.8" Color TFT shield.
• OV7670 camera module — pinout must match images above
• Two 2.2K resistors (color bands: red+red+red+gold)
• Wire
• Soldering iron and related paraphernalia
• Optional: microSD card

OV7670 camera modules with the 18 pin, 2-row header can be found on Amazon, eBay, etc. Make sure the pinout matches the camera shown above…occasionally there are incompatible variants. The cameras are sometimes sold in sets of two…which is a good idea, as they’re easily damaged with the wrong voltage or rough handling as we make some modifications…

Modifying the Camera

Power and Connections

Camera Orientation

Please note that with the camera installed this way — with the silkscreen on both the camera board and Grand Central in a readable orientation — the camera’s actually rotated 180°. Its idea of “up” is the other way ’round.

The examples compensate for this by also rotating the display output 180°. These are mostly just copying data straight from the camera to the screen and don’t care. But if you’re doing any actual image processing, anything requiring a specific orientation, keep that in mind, that you’ll want to hold the board the other way, with the silk upside-down.

If this is your first time using the Grand Central board, please begin with our Introducing the Adafruit Grand Central M4 Express guide. This will walk you through setting up the Arduino IDE for use with this board.

Do not continue until you have at least the basic “blink” sketch working on Grand Central.

Install Arduino Library

Our OV7670 library can be installed from the Arduino Library Manager:

Sketch→Include Library→Manage Libraries…

Enter “OV7670” in the search field. You’ll see more than one library returned…others are working on the idea too…but specifically install the Adafruit_OV7670 library because this one works with the SAMD51 Parallel Capture Controller.

Select Grand Central as the board type from the Tools menu:

Tools→Board→Adafruit Grand Central M4

Our example sketches can then be accessed from the File menu:

File→Examples→Adafruit OV7670

There are two examples to begin with:

• cameratest works with the 2.8" TFT Touch Shield (resistive or capacitive doesn’t matter — the example doesn’t use touch, just the display). This displays live video from the camera at 320x240 pixel resolution.
• selfie works with the 1.8" TFT Shield (V2). A live camera feed is displayed at 160x120 pixel resolution. With a FAT-formatted microSD card in Grand Central’s card slot (not the slot on the shield!), tap the “A” button to capture a still image at 320x240 pixels in BMP format.

Important notes about the “selfie” example

• Use the microSD card slot on Grand Central. Do not use the card slot on the TFT shield.
• Each time you run it and take stills, the code will sequentially overwrite any existing BMP images in the “selfies” folder on the card! Rude. This is a quick demo and not a Real Photography Tool™.
• The BMPs it writes are a lesser-seen variant that not everything can read. Photoshop, Preview on Mac and ImageMagick should all handle it.

The Arduino library is pretty minimal right now but handles the most important low-level ugly stuff.

The examples show all the vital steps, but it’s mixed in with a lot of weird TFT display-specific code. Let’s look at just the camera bits…

Sketches should begin by #including the Wire and Adafruit_OV7670 libraries:

The Wire library is used for camera control over I2C, while image data comes through the PCC data pins.

In the globals section of the sketch…outside the setup() and loop() functions…we set up some structures and call the OV7670 constructor.

The arch structure contains values specific to the SAMD51 hardware. In principle, in the future, there might be different arch structures for different hardware. If using Grand Central, you can just copy this line to your own code. For other M4 boards, you need to specify what timer/counter peripheral (PWM out) connects to the camera’s XCLK input, and, if the timer is a TCC peripheral, if special pin multiplexing is required for it (super esoteric, probably won’t need to change).

The pins structure specifies Arduino pin numbers where the camera’s enable, reset and XCLK pins are connected. On the SAMD51, the PCC pins are set in stone and can’t be assigned to other locations, but these few pins are OK being routed to other locations. The examples are set up for the Grand Central header.

Then the constructor is invoked…we’ll call our camera object “cam,” and it expects, in this order:

1. An I2C address (pass OV7670_ADDR, the standard address for an OV7670).
2. A pointer (&) to a pins structure (previously declared).
3. A pointer (&) to a Wire (I2C) instance. Grand Central has several…one of those, Wire1, is conveniently on pins 24 (SCL) and 25 (SDA), which aligns with the camera board, almost like it was planned this way.
4. A pointer (&) to an arch structure (previously declared).

Later, inside the setup() function, we initialize the camera by calling its begin() function. This expects at least three arguments:

1. A color mode, either OV7670_COLOR_RGB or OV7670_COLOR_YUV. RGB is best for showing color images on TFTs, but some applications such as object tracking may want grayscale data, which is more easily extracted from YUV.
2. An initial image size, from one of the values #defined in Adafruit_OV7670.h. In most situations the library will attempt to allocate a buffer large enough for an image this size. Possible values include:
   • OV7670_SIZE_DIV1 — 640x480 pixels, don’t bother using this right now because there’s not enough RAM to buffer a full image this size on current SAMD51 chips.
   • OV7670_SIZE_DIV2 — 320x240 pixels (a division-by-two of 640x480). This is the largest size that most M4s can handle.
   • OV7670_SIZE_DIV4 — 160x120 pixels (division by 4 of 640x480).
   • OV7670_SIZE_DIV8 — 80x60 pixels (ditto, 8).
   • OV7670_SIZE_DIV16 — 40x30 pixels (16).
3. A desired frame rate, as a floating-point value. The actual frame rate may be different from this, but it will do its best to match. The maximum supported by this camera is 30.0 frames/second.

It is IMPORTANT to check the return value from the begin() function — this tells you whether it initialized successfully and the camera is working. Possible return values include:

• OV7670_STATUS_OK on success.
• OV7670_STATUS_ERR_MALLOC if image buffer couldn’t be allocated (insufficient or fragmented RAM).
• OV7670_STATUS_ERR_PERIPHERAL if an invalid timer peripheral was passed to the constructor earlier.

An optional fourth argument to begin() takes an image buffer size, in bytes. There are some situations (as in the “selfie” example) where the camera might change between small and large image resolutions. It’s best in these cases to pre-allocate the image buffer to the largest anticipated image size, because it might not be possible to change later. Here we’re initially using a DIV4 (160x120 pixel) image…but allocating enough for a DIV2 (320x240) image (each pixel is 2 bytes, whether RGB or YUV):

After begin() returns an OK status, the camera is now continuously dumping frames into a section of RAM. We can query the address of the image buffer, and the image dimensions in pixels, using:

However…because the camera is continually dumping data, it’s possible you or the camera might overtake one another when accessing this, resulting in a visible “tear” across the image.

So, before accessing the image, it’s recommended to first pause the camera:

(This is not a sleep mode, it just pauses the data spigot.)

Read what you need from the image buffer, then resume camera streaming with:

You can also keep the camera paused and read individual frames with:

The image data will then be in the same location as returned by getBuffer().

suspend() has slightly less latency than capture(), since it returns as soon as the current in-flight frame is received, rather than starting on the next frame.

Pixel Format

The OV7670 is “big endian” — for each 16-bit pixel, the most significant byte is at the lower address in memory.

This is the opposite of the SAMD51 and most other 32-bit microcontrollers, which are “little-endian.” If you need to dismantle and process individual pixels, a byte swap is often necessary:

Most TFT displays are also big-endian, so the examples don’t need to do this byte swapping…they can just move data directly from the camera to the display, it’s super smooth and buttery.

In OV7670_COLOR_RGB mode, each 16-bit pixel has 5 bits of red, 6 bits green and 5 bits blue. In OV7670_COLOR_YUV mode, 8 bits are brightness and 8 for color… you can work with just the brightness byte for higher-quality grayscale than in RGB mode.

The Adafruit_OV7670 library provides a number of special image effects. Some of these are “in-camera” effects — every frame from the camera continuously comes out this way in real time, with no processing required on the host microcontroller. Others are “postprocessing” effects, requiring that the camera be paused while the host microcontroller does a number on the last-received image in memory.

In-Camera Effects

Postprocessing Effects

The following effects are generated in code, not by the camera. It’s therefore necessary to pause the camera output before performing any of these operations, else the next incoming frame will overwrite the interim results in RAM.

All of the postprocessing function names begin with image_

You can chain multiple processing functions, each will modify the output of the prior function. For example, image_median() then image_edges(). The order of operations will affect the outcome; they are not interchangeable.

Remember that these only process the last-captured image in memory. They are not continuously applied while the camera is “live.” You must suspend, process, do something with the image data, then resume.

Some of these functions only work in RGB mode, YUV is not always supported.

The following work with RGB images only, YUV is not handled.

Manual Focus

The OV7670 is a fixed-focus camera — it can’t automatically compensate for near or far subjects. From the factory, it seems to work best about 1 meter (3 feet) from a subject. Anything farther or closer (especially closer) will be progressively more blurry. But we can manually tweak that.

Pinhole Version