Question: DIY Wiicam for 3.3V boards?

[ThatOneSeong]

Felt compelled to make a topic about this because I haven't seen much, if any information about this even with searching.

I have a Top Shot Elite in my hands right now that I'm planning to mod for my personal system for testing which you may have heard of before. While I don't currently have a DFRobot camera that I've used in my prior three builds, I do have a spare semi-working Wiimote with a working camera, that I'd figured I'd gut the sensor and adapt into a DIY camera.
Now, getting the parts isn't an issue, neither is the soldering--I'd done those plenty of times now. However, I could not find many... actually, any publicly available resources for how to actually do this.
The most that I can find about converting a Wiicam is this general schematic from what I think is an old revision of the GUN4IR PDF manual:

Now, my personal dilemma is, I'm not using GUN4IR (obviously), and the board I'm using is a Raspberry Pi Pico - a microcontroller which has a native 3.3V output. Aside from the quartz crystal (and decoupling cap), much of the schematic seems to be focused on pulling down the sole 5V output from this Arduino board to the camera.

So if that's the case, does that mean I can skip both the voltage conversion and the resistors and just connect everything from the camera directly to the Pico? Or if not, what other changes would be needed to facilitate this? Has anyone else tried something like this themselves? I'd love to hear the community's thoughts, since I'm definitely no electrical engineer.

[PL1]

Now, my personal dilemma is, I'm not using GUN4IR (obviously), and the board I'm using is a Raspberry Pi Pico - a microcontroller which has a native 3.3V output. Aside from the quartz crystal (and decoupling cap), much of the schematic seems to be focused on pulling down the sole 5V output from this Arduino board to the camera.

So if that's the case, does that mean I can skip both the voltage conversion and the resistors and just connect everything from the camera directly to the Pico? Or if not, what other changes would be needed to facilitate this?

There's no voltage conversion needed since you're using a 3.3v output from the board instead of a 5v output.

You will need "pull-up" resistors to keep the three inputs from "floating" between logic HIGH and LOW levels.
- The one on cam pin 8 (purple) will need to be an external resistor as shown.  The pull-up resistor keeps pin 8 at a logic HIGH so it doesn't unexpectedly reset.
- The Pico's input ports should have built-in pull-up resistors that can be enabled in the Arduino sketch code, but you can use external pull-ups as shown.  I assume the coder/circuit designer didn't use the built-in pull-ups for SCL (green) and SDA (yellow) to keep the built-in pull-ups from dragging SCL and SDA up to 5v which could damage the 3.3v cam circuits. (the Pro Micro is usually a 16MHz/5v board)   

https://learn.sparkfun.com/tutorials/pull-up-resistors/all

https://arduinogetstarted.com/faq/arduino-pull-up-pull-down-resistor


Scott

[ThatOneSeong]

Now, my personal dilemma is, I'm not using GUN4IR (obviously), and the board I'm using is a Raspberry Pi Pico - a microcontroller which has a native 3.3V output. Aside from the quartz crystal (and decoupling cap), much of the schematic seems to be focused on pulling down the sole 5V output from this Arduino board to the camera.

So if that's the case, does that mean I can skip both the voltage conversion and the resistors and just connect everything from the camera directly to the Pico? Or if not, what other changes would be needed to facilitate this?

There's no voltage conversion needed since you're using a 3.3v output from the board instead of a 5v output.

You will need "pull-up" resistors to keep the three inputs from "floating" between logic HIGH and LOW levels.
- The one on cam pin 8 (purple) will need to be an external resistor as shown.  The pull-up resistor keeps pin 8 at a logic HIGH so it doesn't unexpectedly reset.
- The Pico's input ports should have built-in pull-up resistors that can be enabled in the Arduino sketch code, but you can use external pull-ups as shown.  I assume the coder/circuit designer didn't use the built-in pull-ups for SCL (green) and SDA (yellow) to keep the built-in pull-ups from dragging SCL and SDA up to 5v which could damage the 3.3v cam circuits. (the Pro Micro is usually a 16MHz/5v board)   

https://learn.sparkfun.com/tutorials/pull-up-resistors/all

https://arduinogetstarted.com/faq/arduino-pull-up-pull-down-resistor


Scott

That sounds a bit like what I'd figured, but also good note about using the internal pullups for the data lines! Very useful.
I'm guessing then if someone isn't using external/physical resistors for their DIY cam's I2C lanes, I'll have to add a flag and/or distribute a separate build specifically for this case (which should be totally fine, given how niche of a scenario this is to begin with).
Thank you so much for the clarification! <3

EDIT: Since you mention that the reset pin needs to be held at a logical HIGH, in theory couldn't that be attached to a pin on the Arduino that's set to output high by the sketch? Not an ideal workaround but could work in a pinch if needed.

[PL1]

I'm guessing then if someone isn't using external/physical resistors for their DIY cam's I2C lanes, I'll have to add a flag and/or distribute a separate build specifically for this case (which should be totally fine, given how niche of a scenario this is to begin with).

Just realized that I was thinking and posting a link about the Arduino Pico, not the Raspberry Pi Pico.   

Not sure if you'll need external pull-ups for the clock and data lines or if the cam circuit already has them.

Note that I2C relies on an open drain configuration for both clock and data lines. This requires pull-up resistors on both lines. However, many breakout and prototyping boards (such as the one we will use for this demo) already have the pull-up resistors included. As a result, you should not need to add your own resistors.

https://www.digikey.com/en/maker/projects/raspberry-pi-pico-rp2040-i2c-example-with-micropython-and-cc/47d0c922b79342779cdbd4b37b7eb7e2

A post 3/4ths of the way down this thread suggests using a voltmeter to test if external pull-ups are needed.
https://forums.raspberrypi.com/viewtopic.php?t=7664


Scott

[RandyT]

A couple of things to keep in mind:

1: The 24mhz (or 25mhz) "crystal" is NOT a garden variety crystal, rather a clock generator.  I.e. you give it power and it outputs a clock signal, which is something a standard crystal needs extra parts to do.  It's also possible, with a fast enough microcontroller, to use an interrupt and a spare pin to generate a suitable clock signal for the camera, negating the need for that part.

2: The need for pull-up resistors is very dependent on the microcontroller being used.  Most internal pullups are much higher resistance than is ideal for I2C communication, and will likely result in unreliable communication unless the camera is literally right next to the controller chip, if it works at all.  This is what I found with regard to the RP2040:

The values are stated ranging from 50k to 80k in the RP2040 data sheet (chapter 5.2.3.4.)"

This is typical for microcontrollers, so not good. If there are dedicated I2c pins on the Pico board, they may already be in place, so you would need to check the target PCB's documentation or look for the physical components on the lines.  A random example I found using a Pico shows the lines connected directly without pullups, so take that for what it's worth.  Also, as Scott indicated, some devices have them built in, but with the little official documentation available for the cameras it's hard to know without testing. 

Ideally, for hardware which doesn't have dedicated lines/circuits for I2c, one should make a final circuit using a middle of the road value for I2c and then monitor the communication with a scope to make sure the waveforms are sharp and well-defined.

[Prow]

I've directly connected a Wii camera module to an RP2040 and it works fine as they are both 3.3V devices.

For the I2C connection, I used 4.7K pull-up resistors and this worked fine up to 1MHz. I can't remember if I tested without the resistors but I doubt the I2C could run that fast with the weak internal pull-ups.

I used the RP2040 to generate a 25MHz clock for the Wii camera. There are two easy ways to do this. You can use the clock generator output or the PWM peripheral with a 50% duty cycle. Set the System Clock to 125 or 100 MHz to target 25MHz output.

When looking at the clock signal on a scope, there was large overshoot and undershoot. Perhaps it's severe ringing due to an impedance mismatch? Is it a potential issue? A 50 to 100 ohm resistor (in series) fixed this.

The RP2040 has a drive strength adjustment but I haven't yet tested if there's a setting that would help clean up the clock signal without requiring a resistor.

[RandyT]

I used the RP2040 to generate a 25MHz clock for the Wii camera. There are two easy ways to do this. You can use the clock generator output or the PWM peripheral with a 50% duty cycle. Set the System Clock to 125 or 100 MHz to target 25MHz output.

It's good to hear a confirmation that this is achievable.  The oscillators are available, but not the easiest to come by and add some expense and complexity.

*edit*

Here is a good explanation for using the PIO.  It looks as though the PIO can be on any GPIO pin and it essentially runs code separate from the main CPU.  Seems like a good approach for a clock output and there is even some sample code for generating a square wave output.

When looking at the clock signal on a scope, there was large overshoot and undershoot. Perhaps it's severe ringing due to an impedance mismatch? Is it a potential issue? A 50 to 100 ohm resistor (in series) fixed this.

The RP2040 has a drive strength adjustment but I haven't yet tested if there's a setting that would help clean up the clock signal without requiring a resistor.

I think you are onto something with that.  Based on a paper I just read, there are multiple drive gates in parallel and using all of them can cause current spikes which may be overdriving the signal.  It's certainly something worth exploring.  If the BOM to interface the camera to the RP2040 ends up being just a few resistors, that would be pretty nice!