<< return to Pixycam.com

getBlocks I2C API

Hello. I am trying to write an I2C API for communicating with the pixycam2. Specifically, I’m trying to figure out the best way to call getBlocks().

In the libpixyusb API, getBlocks() returns up to maxBlocks detected blocks. According to the porting guide, I can also request up to maxBlocks number of blocks over I2C. However, the response packet described in the porting guide is just for 1 block. Is the I2C interface only capable of returning 1 detected block even if I request more? Or would I need to send maxBlocks number of requests over I2C and then read maxBlocks responses? The documentation isn’t clear on this.

1 Like

Hello,
Sorry for the confusion. The response will include multiple blocks, if detected, and if the number is less than or equal to the indicated maximum blocks.

Hope this helps.

Edward

So if I request getBlocks(maxBlocks) with an I2C write, I should then immediately execute an I2C read of (maxBlocks*blockSize) bytes? Where is it indicated if the number of detected blocks is less than the desired maximum blocks?

Hello,
You need to read the header first, which contains the length. You can then infer the correct number of blocks based on the length and read the correct number of bytes. See recvPacket here:

Edward

Thanks. One more follow up question:

Does the packet structure for a block repeat in the response data if multiple blocks were detected? For example, suppose I requested getBlocks(maxBlocks=5) and the pixycam detected/returned 3 blocks. After the initial 6 byte response header, would I receive 14*3 payload bytes, where immediately following the “Age” byte of the first block, the next byte is the 16-bit signature of the second block and so on until reaching the “Age” byte of the third block? Is there still only one checksum which is a sum of all payload bytes over all blocks?

Yes, that is correct. The checksum is the sum of all of the payload bytes.