<< return to Pixycam.com

Pixy2, FTC, and I2C registers

Pixy Software
#1

Hi - we’re trying to connect to the Pixy2 via I2C and the FTC SDK. The SDK, as far as we can tell, requires a register to read. A couple other people have asked about this. Apparently, there are other ways people worked around this: custom firmware (which is illegal, I believe) or (vaguely) Lego interface. But we can’t find any definitive answer from anyone who has actually used this code to connect to a Pixy2, nor can we find any quality documentation.

So, my question is, how do we connect?

  1. Is there some default register we can put into I2CDeviceSynch that will treat it as a serial bus?
  2. Which interface should we use? I2C or Lego I2C? Does the Lego allow for a read at a register? do we need the lego firmware to do it?

Thanks for any guidance.

#2

Hello,
We aren’t familiar with the FTC SDK. The LEGO interface does use a register-based implementation, but we haven’t documented the protocol (only LEGO users have used it, and they aren’t interested in these kinds of details.)

Here is the source code:

The LEGO protocol is handled in lego_getData().

Hope this helps!

Edward

#3

Thanks for this - I’ll check it out. The FTC SDK only implements I2c with reading from registers. It’s not well documented, so I’ve had a hard time figuring out how to just get data off the bus, and we get a lot of timeouts. I don’t know enough about the I2c protocol to know how registers are sent in, such that the PixyCam2 would ignore that data if one happened to be sent.

#4

Actually, now we’re getting somewhere. It appears that with lego_getData() the data comes in in a single buffer, and the first byte is extracted and treated as a register. Where is the parallel function for the I2c interface? Seeing how the code handles the buffer would probably answer the question.

#5

OK, I studied the source code, which was really helpful; It appears that:

  1. On command send (by the robot), you simply take the first byte and treat it as the type. Given that the lego code takes the first byte and treats it as a register, this implies that if I move the request type into the register spot and send the rest as data, the code will process my request. This is an assumption, of course, because the lego code is taking the first byte of the read request buffer (which is actually a write from the robot), and then filling what remains. But from what I’ve read about the i2c protocol, I think this will work.
  2. On receive (from the pixy), it appears that you don’t do anything at all with the register - it’s merely part of the read request buffer. If that’s true, I can send anything in and it would work. My concern is that with the lego code, you are actually reading the register byte and presumably sending an ack. My worry is that if the robot writes a register, you don’t send the ack - and indeed that may be why I’m getting the no ack timeout error! I hope not. It would be nice if your code looked for a register write and discarded it if it wasn’t the lego interface (it would also be nice if the FTC folks wrote an interface that didn’t send registers).

Let me know your thoughts.

#6

Hello,
I think you have the basic idea. The first byte is definitely like the register-based I2C communications, but I don’t know of a special ACK. I don’t have full understanding of the code, but I would create some tests and see if you get data back that makes sense. :slight_smile:

Edward