Does this work for the Pico W?

[sgbaird]

I verified that this doesn't work (out-of-the-box at least) with the Pico W. Following the instructions at https://www.arducam.com/docs/pico/arducam-camera-module-for-raspberry-pi-pico/spi-camera-for-raspberry-pi-pico/, I get the following while running ArduCAM_Mini_2MP_Plus_VideoStreaming.py:

Traceback (most recent call last):
  File "<stdin>", line 17, in <module>
  File "/lib/Arducam.py", line 176, in __init__
TimeoutError: Clock stretch too long

Maybe related? adafruit/circuitpython#4221 adafruit/circuitpython#4082 micropython/micropython#8167

[sgbaird]

Not sure if the polarity and phase issues from Xraydylan/Arducam-OV2640-Pico-Package#3 (comment) are an issue.

[sgbaird]

Bump

[alexarch21]

Not sure about micropython, but I can confirm that their C/C++ SDK works fine on the Pico W (tested on an ArduCam Mini 2MP+).

Their code is a huge mess, but after picking what I needed, it works as expected.

[alexarch21]

I have to correct myself slightly here. Their C++ code works fine most of the time. Until sometimes it doesn't.

It hangs during setup in ArdumCam::InitCAM(), on an i2c register write during the OV2640_JPEG_INIT blob write. The write (which is blocking in their SDK) never completes and hangs indefinitely. This is entirely random. Sometimes it works, the cam initializes and then picture capture works fine. Sometimes init fails because of this hang. When this happens the entire SoC on the ArduCam module hangs, it doesn't even react to reset anymore. The only way to get it back is to power cycle it.

Very annoying, it makes the module extremely unreliable. I will start looking for alternatives.

Not sure if this is specific to the Pico W (probably not), if it is a bug in their SDK (which is messy, feels hacked together, and is very far from something I'd consider production code) or if it's a bug in their SoC firmware.

Edit:
For those who have found this and are experiencing a similar issue. I did some more in depth debugging. It turned out to be a write to device control register 0xE5 (on register bank 0) that (sometimes) locks up the camera ASIC. This write is part of the whole blob of writes in OV2640_JPEG_INIT performed by InitCAM() from within their SDK. According to the OV2640 datasheet, this register is reserved/undocumented, so I have no clue what it does. Removing the write to it seems to resolve the hanging issue and does not seem to impact camera operation in any visible way (at least for my use case).

[sgbaird]

I didn't consider using the C++ SDK on the Pico W. Enviro Camera (Pico W aboard) seems like a nice alternative, but it's still "coming soon". For the register write, do you remove/comment out this line?

PICO_SPI_CAM/C/ArduCAM/ov2640_regs.h

Line 284 in 47cd7f6

{ 0xe5, 0x7f },

[alexarch21]

No, the one a little lower:

PICO_SPI_CAM/C/ArduCAM/ov2640_regs.h

Line 389 in 47cd7f6

{ 0xe5, 0x1f },

I didn't have a problem with the first occurrence of the write, the second one triggered the hang. It looks like the first one enables some mode (setting all lower 7 bits of the register), then comes a huge amount of config data, then the second one clears the upper bits again. It's then shortly followed by a noop-reset (register 0xE0). But this is purely empirical evidence without knowing what all of these registers actually do. Most of the control registers used by their SDK are undocumented. I have been running an automated stress test since and it looks to be reliable so far.

I also replaced all i2c write calls in their SDK by their timeout'ed counterparts (i2c_write_timeout_us) to make them fail gracefully without locking up the entire MCU core. So in the worst case the MCU can hard power cycle the camera and try again.

I'm probably going to switch to another camera altogether. This is for a commercial project and this all looks far too sketchy and poorly documented to me. The OV2640 is way past its end of life anyway.

[sgbaird]

@alexarch21 thanks for clarifying. Curious to hear what alternative you settle on!