Case Overview
The project focuses on embedded image acquisition, display and basic image processing. STM32H743 is used as the controller platform, and OV9281 is used as a monochrome global shutter image sensor. Image data is output through DVP RAW8, received by DCMI, transferred by DMA and displayed on a 5-inch 800×480 RGB LCD. The delivery scope includes hardware design, camera interface planning, display hardware, low-level drivers, image acquisition, image display, quality tuning, light spot detection, serial diagnostics and version handover. This public case does not disclose the client name, commercial information or unconfirmed operating data. It explains the technical route and reusable engineering experience.
Project Background
Industrial inspection devices, light spot localization terminals, motion observation equipment, edge processing modules and portable vision products often need image acquisition and display under limited computing resources, limited memory and strict timing constraints. Compared with PC-based vision systems, a microcontroller-based solution places more emphasis on interface timing, buffer organization, DMA transfer, display refresh and diagnostic visibility. OV9281 is a monochrome global shutter image sensor suitable for scenarios that are sensitive to motion distortion. STM32H743 provides DCMI, DMA, cache and peripheral resources, making it suitable for embedded vision prototypes and customized devices. The project target was to build a complete path from sensor to LCD display and then add basic image processing and light spot detection.
Responsible Scope
Our work covered hardware design and all embedded software development. Hardware work included the interface between OV9281 and STM32H743, power and reset control, MCLK output, DVP data lines, a 5-inch RGB LCD interface and debugging connections. Software work included OV9281 register initialization, image size and output format configuration, DCMI acquisition setup, DMA transfer management, frame buffer design, cache coherency handling, LCD frame buffer display, RAW8 to RGB565 display conversion, brightness and contrast tuning, light spot detection, coordinate overlay, red cross marker display, serial diagnostic logs and stable version backup. The delivery focused not only on functional implementation, but also on code structure, traceable debugging and maintainability.
Technical Architecture
The acquisition path uses OV9281 to output DVP RAW8 grayscale images. STM32H743 receives pixel data through DCMI and writes image data into the frame buffer through DMA. The project uses 480×480 as the core validation size. Each frame is 230400 bytes, and the DMA length is organized as 57600 32-bit words. The display path converts RAW8 grayscale data to RGB565 and outputs it to a 5-inch 800×480 RGB LCD. The image is displayed in an adapted region. To reduce tearing and freezing risks, continuous acquisition uses a double-buffer strategy with cache clean, cache invalidation and frame state flags to keep DMA and CPU access consistent.
The image processing flow follows an engineering-first order: reliable acquisition and display come before image enhancement and target detection. Brightness, contrast, dark-scene behavior, stripe artifacts, repeated frames and moving-object continuity were all included in debugging. The light spot detection module searches for high-brightness regions in the grayscale image, outputs the spot coordinate and overlays the coordinate and a red cross marker on the LCD display for on-site verification. The serial diagnostic module outputs sensor ID, frame rate, minimum value, maximum value, average value, error counts and acquisition status, helping locate DCMI overrun, DMA error and sync error conditions.
Key Parameters
| Item | Parameter and Description |
|---|---|
| Controller Platform | STM32H743 for acquisition, data transfer, display control and basic image processing. |
| Image Sensor | OV9281 monochrome global shutter sensor with DVP interface and RAW8 grayscale output. |
| Validation Size | 480×480, 230400 bytes per frame, with a target frame-rate configuration of 90 fps. Actual criteria should follow project test records. |
| Display Solution | 5-inch 800×480 RGB LCD with RGB565 frame buffer display. |
| Diagnostics | Monitoring DCMI overrun, DMA error and sync error counters for stability debugging. |
Software Modules
- ov9281.c / ov9281.h: sensor ID reading, register initialization, resolution configuration, output format setup, MCLK, reset and power-related control.
- camera_dcmi.c / camera_dcmi.h: DCMI parameters, DMA start, snapshot acquisition, continuous acquisition, frame callbacks and error status handling.
- frame_buffer.c / frame_buffer.h: frame buffer allocation, double-buffer state, cache coherency, frame validity flags and data access interfaces.
- camera_lcd.c / camera_lcd.h: RAW8 to RGB565 conversion, LCD region refresh, overlay rendering and debug information display.
- camera_diag.c / camera_diag.h: frame rate, grayscale statistics, error counters, runtime state and serial log output.
- ltdc.c and User/main.c: display controller initialization, main process scheduling, mode switching and system-level debug entry points.
Debugging Issues and Handling
The debugging process covered both image quality and acquisition stability. When line or stripe artifacts appeared, sensor registers, DVP timing, PCLK polarity, DMA data width and cache handling all needed to be checked together. When moving objects caused split images, the team needed to confirm whether the acquisition buffer and display buffer were being accessed at the same time, and reduce tearing through double buffering, frame synchronization flags and display timing control. When the image froze, DMA callbacks, DCMI state, error interrupts and frame completion flags were reviewed. When dark-scene display quality was not satisfactory, exposure, gain, grayscale mapping and LCD conversion were tuned together. Repeated frames or ST-LINK exported image artifacts required separating actual frame data issues from debugging tool readout behavior.
These issues show that embedded vision delivery cannot focus only on algorithm output. Sensor configuration, peripheral timing, DMA lifecycle, cache strategy, display refresh and diagnostic logs need to be treated as one engineering system. A staged test path helps confirm sensor ID, image output, snapshot acquisition, continuous acquisition, LCD display and serial logs before adding image processing and target detection.
Delivery Results
The delivery included a compilable STM32H743 project, OV9281 driver, DCMI and DMA image acquisition code, LCD real-time display, RAW8 display conversion, image quality tuning, light spot detection with coordinate overlay, serial diagnostic logs, stable version backups and reusable project documentation. The work can support later evaluation for embedded vision devices, industrial inspection prototypes, light spot localization, motion tracking, edge detection and threshold segmentation. Public parameters and functions are provided to explain the project content. Practical applications should confirm sensor version, board design, lighting, lens, display and acceptance criteria again.
Project Value
This case validates an engineering implementation path that combines STM32H743, OV9281, DCMI, DMA and RGB LCD for embedded vision acquisition and display. It provides a reusable foundation for vision acquisition terminals, portable inspection devices, light spot localization systems and edge image processing modules. The experience also shows that embedded vision projects should design hardware interfaces, drivers, cache management, display effects, algorithm modules and diagnostic tools together to make the system easier to debug, hand over and iterate.
FAQ
What projects can use this case as a reference?
It is relevant to embedded vision acquisition projects using STM32 controllers, global shutter sensors, DCMI, DMA, LCD real-time display and embedded image processing. Final boundaries should be confirmed according to sensor timing, board design and site testing.
Are the public parameters equal to acceptance criteria?
No. The public case explains the technical route and delivery scope. Final criteria should be based on project samples, hardware configuration, operating environment, test records and the confirmed technical agreement.
What information is useful before project evaluation?
Useful information includes sensor datasheets, display parameters, interface constraints, target frame rate, processing workflow, sample images, operating conditions, power and structure limits, and host or peripheral interfaces.