Driver encapsulation #10
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
No more dobule inheritance! New VideoCapture and VideoDisplay classes to more clsoely match standard OpenCV. New "abstract" base classes for camera and display drivers. All camera and display drivers now encapsulate an interface object for better expandability to other platforms. New utils subpackage with common color modes and memory helper functions. Update rv_init package after refactor. Update DVI exampels to no longer use private members. Add header comments files that were previously missing it. Add full file path to header comments.
…pixel. Fixes a regression with the HM01B0 driver, where the DMA is unable to transfer fast enough to keep up with the PIO when only 1 byte per transfer is performed. It's also just more efficient in general.
On RedBoard RP2350, the D0 pin ends up connecting to the HSTX connector. When an HDMI cable is plugged in, D0 connects to the CEC pin, which has the effect of dramatically increasing the capacitance on the D0 pin, resulting in a terrible eye pattern. Increasing the drive strength helps clean it up a lot. Also probably beneficial to do this to the PCLK pin, and on all boards when using 1-bit mode (highest PCLK frequency, same as MCLK pin) to help maintain good signal quality.
Too high seems to maybe cause oscillations or something. Hard to know for certain, because a scope probe changes the behavior.
gigapod
approved these changes
Dec 9, 2025
Member
gigapod
left a comment
gigapod
left a comment
There was a problem hiding this comment.
I marked a few nits, but overall this looks very solid.
Bonus points for the awesome comments and ASCII diagrams.
Similar to the HM01B0, too high drive strength seems to result in degraded signal integrity, which is not visible with an oscilloscope due to the additional capacitance on the line. The default drive strength was set to the max (4x), which was causing bytes to sometimes be missed with the OV5640. Reducing to 2x seems to be much more stable now, and still sufficiently strong to get a clean eye pattern on the D0 pin while an HDMI cable is connected with the RP2350 RedBoard.
Further testing revealed 2x was still too much. 1x seems much more stable. Also fix erroneous extra bit getting set (not documented in datasheet, so probably shouldn't be changing it).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Resolves #5
The previous camera and display drivers were implemented using double inheritance. One parent was for the device driver (eg. HM01B0 or OV5640), and the other was for the interface driver (eg. SPI or PIO). This meant that to create each combination of m devices and n interfaces, a total of m+n+m*n classes were required, which would get unwieldy quickly.
This changes the implementation so each device driver encapsulates the interface driver (which all implement the same methods), so a total of only m+n classes are required. This also has the benefit of separating interface parameters (eg. pin numbers) from device parameters (eg. resolution) when calling the constructors. Then the user can (theoretically) freely mix and match whatever device and interface drivers they need/want for their setup, which is emphasized in the updated example
rv_initmodule.Other changes:
VideoCaptureclass to more closely match standard OpenCV'sVideoCaptureclass. The constructor takes an object that implements theVideoCaptureDriverabstract base class (which itself, inherits the newVideoDriverabstract base class).VideoDisplayclass to mirror theVideoCaptureclass. This is not a feature of standard OpenCV (cv.imshow()takes a string for the name of a window to display in, instead of an object that represents the window), but IMO it makes sense to keep the display driver structures as similar as possible to the camera drivers, and this is backwards compatible with the existing API difference in MicroPython-OpenCV. The constructor takes an object that implements theVideoDisplayDriverabstract base class (which itself, inherits the newVideoDriverabstract base class).utilssubpackage with modules:colors- Provides standard color mode constants intended for use across all Red Vision drivers, and color-related utility functions.memory- Provides utility functions related to device memory, such as checking whether an object/address is located in internal or external memory (the slower speed of external memory has proven to require different implementations for best performance).pins- Provides utility functions that drivers can leverage to check and modifymachine.Pinbehavior on the fly.rv_initpackage now encourages importing the entire Red Vision package (eg.import red_vision as rv) rather than wildcard imports from submodules (eg.from red_vision.cameras import *) to improve readability and parity with OpenCV (eg.import cv2 as cv).