available() reports whether a sensor driver was linked, instead of True - #5
Merged
Merged
Conversation
It was `return mp_const_true`, so the one question it exists to answer could not come back no. Reaching that branch already means a MIPI-CSI target, so what is left to ask is whether any esp_cam_sensor driver was compiled in: the drivers register themselves in the detect section the open path walks, and with no CONFIG_CAMERA_<chip> that section is empty and no camera can be found on a perfectly good bus. That is the state a P4 image lands in when the option is missed, and this module reports it as "no camera sensor answered on SCCB" -- a wiring-shaped error for a build-configuration cause. Verified both ways on a Waveshare P4 panel: false on an image with no driver linked, true on the same image with CONFIG_CAMERA_OV5647 restored. It deliberately does not touch the bus. available() is asked before any pins are known, so it could not probe honestly; whether a sensor is plugged in is already answered by constructing a Camera.
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
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.
Closes #1.
cameraif_available()on the P4 path wasreturn mp_const_true, so the one question it exists to answer could not come back no.Reaching that branch already means the firmware was built for a target with a MIPI-CSI controller, so what is left to ask is whether any sensor driver was linked in.
esp_cam_sensordrivers register themselves in the detect section the open path already walks (mod_cameraif.c:392), and with noCONFIG_CAMERA_<chip>that section is empty — no camera can be found on a perfectly good bus.That is not hypothetical. It is the state a P4 image lands in when the option is missed, and this module reports it as
no camera sensor answered on SCCB— a wiring-shaped error for a build-configuration cause.micropython.cmakealready carries a note about exactly this trap;available()is what should end it.What it answers, and what it does not
It answers "can this firmware open a camera at all", not "is a sensor plugged in", and the difference is forced by the call site rather than chosen:
board_peripherals.camera()callsavailable()before it passessda/scl, so at that moment there are no pins to probe a bus with. Making it a presence probe would need a different signature and a different call site. "Is a sensor plugged in" is already answered, with a message, by constructing aCamera— which is what issue #1 says too ("board_config.cameraalready raises usefully").So on a board with the driver linked and no sensor attached, this still returns True. That is correct for what it means, and it is worth being explicit about because it is the natural thing to expect otherwise.
Proved both ways on hardware
Waveshare ESP32-P4-WIFI6-Touch-LCD-4B, two images differing only in whether the sensor driver was compiled in:
CONFIG_CAMERA_OV5647cameraif.available()6d12b3b1e72c72bc18f96183e54a7a401d38f359e014f2db972a21d23e2ae133fa0f71d9e5bae0d8dc9a191b5d216f0555bc914b28338a728e817665567b1e2a=yThe False half is the point — it is the answer the old code could never give, on a board where it used to say True. It also made
board_config.camerafail honestly (NotImplementedErrorabout the firmware) instead of blaming the bus.The missing option was a real defect in its own right and is fixed separately in
cmods(517ed3a): nothing in the MicroPython tree set it, so the only P4 image that ever had a working camera was one build directory configured by hand in September.Still owed
Verification with a sensor attached. The OV5647 was not on the bench on 2026-09-22 (confirmed by Brad), so the path where a driver is linked and a sensor answers has not been exercised by this change. With the driver linked and probing, nothing answers at
0x36while the ES8311 (0x18), ES7210 (0x40) and GT911 (0x5d) all answer on the same bus — which is consistent, but it is not the same as watching a camera come up.Built from cmods
517ed3a, micropythonv1.29.0+ micropython-pydevicesb08a978.