Using PixyI2C.h
blocks = pixy.getBlocks();
That will return 1 and not the block count (this works for SPI).
I am currently getting around this using a loop of:
while (pixy.blocks[j].height > 0)
Hi Peter,
What happens when you use the hello world program? Does it show the same behavior?
Also, if you can post more of your code, that would be great.
Thanks!
Scott
I experienced the same one block only problem with the SPI interface after I modified the SPI and Tpixy libraries to run independent of Arduino and then linked to my own code running on an ATMEGA644 chip. It only returned a singe block most of the time. Sometimes 2 but never 3. So, I replicated the Arduino hello pixy example as close as possible and it worked properly on my hardware. Originally I had a loop that called pixy.getBlocks() then printed the block count on every pass. I experimented with various delays in the loop to slow it down and disabling interrupts during the getBlocks call but nothing worked until I added the " if(i%50) { print data } " It makes the call to pixy.getBlocks() 50 times between each readout of the pixy.block[n] array. I really don’t understand this behavior at all.
Can someone explain exactly how to make the call to pixy.getBlocks() correctly? Are there critical timing issues? Does it need to be called 50 times to put all the blocks in the array?
This works:
while(1==1){
cli();
blocks = pixy.getBlocks();
sei();
if(blocks > 0){
i++;
if(i%50==0){
debug[0] = pixy.blocks[0].x / 2;
debug[1] = pixy.blocks[0].y / 2;
debug[2] = pixy.blocks[0].signature;
debug[3] = pixy.blocks[0].width / 2;
debug[4] = pixy.blocks[0].height / 2;
debug[5] = blocks;
refreshDebug(); //Sent to LCD display
}
}
}
This does not:
while(1==1){
cli();
blocks = pixy.getBlocks();
sei();
if(blocks > 0){
debug[0] = pixy.blocks[0].x / 2;
debug[1] = pixy.blocks[0].y / 2;
debug[2] = pixy.blocks[0].signature;
debug[3] = pixy.blocks[0].width / 2;
debug[4] = pixy.blocks[0].height / 2;
debug[5] = blocks;
refreshDebug(); //Sent to LCD display
}
delay(2) ; // wait 20 milliseconds
}
I did some experiments with the Arduino Hello_world pixy program. I added a delay(n) just before the getBlocks(). It works fine until I put in delays that exceed 4 ms. In effect, if we stop polling the pixy for more than 4 ms it only sends out 1, sometimes 2 blocks. Delays less than 4 ms sends all.
void loop()
{
static int i = 0;
int j;
uint16_t blocks;
char buf[32];
delay(4); // <---- 4 ms is the longest delay it can tolerate. Why?
blocks = pixy.getBlocks();
if (blocks)
{
i++;
if (i%50==0)
{
sprintf(buf, "Detected %d:\n", blocks);
Serial.print(buf);
for (j=0; j<blocks; j++)
{
sprintf(buf, " block %d: ", j);
Serial.print(buf);
pixy.blocks[j].print();
}
}
}
}
I played around with the code a little more and discovered that pixy will provide the correct block count regardless if you do 2 pixy.getBlocks() calls back to back. The first only returns 1 block, the second returns all of them. Seems like there is a pixy bug of some kind.
Modified hello_world pixy program with 1/2 second delay between readings:
void loop()
{
static int i = 0;
int j;
uint16_t blocks;
char buf[32];
delay(500); //Delay .5 sec between readings
blocks = pixy.getBlocks();
blocks = pixy.getBlocks();
if (blocks)
{
sprintf(buf, "Detected %d:\n", blocks);
Serial.print(buf);
for (j=0; j<blocks; j++)
{
sprintf(buf, " block %d: ", j);
Serial.print(buf);
pixy.blocks[j].print();
}
}
}
I would not call cli() and sei() before and after getBlocks() 
Let’s get back to the demos (Hello_world and i2c) — they are good starting points.
In both cases (SPI and I2C) a call to getBlocks() will wait for the next frame, parse and fill the block array (if there are blocks). So if you do something like:
while(1)
Pixy.getBlocks()
getBlocks will return 50 times per second. It’s designed to be as simple as possible.
Did this ever get fixed? Dale Heatherington is correct in that calling getBlocks() twice returns the correct block number. But it also seems to slown down the code somewhat.
Regardless, if I do one getBlocks() call and there are 2 color codes, blocks will only return 1 when it should be 2.
Hello Josh,
The code has changed quite a bit since then. Currently, getBlocks() should not block and will return 0 if there is no new data.
Edward
I understand that, slightly… When I have one object of one color code (for example, a pink and green cylinder), I use delay(20) and then getBlocks(), and it returns a constant steam of 1’s, which is correct. However,when I have two objects of two separate color code’s (for example, a pink and green cylinder AND a purple and blue cylinder), I use delay(20) and then getBlocks(), and it returns 2 for 2-3 times and then a constant stream of 1’s, which is incorrect. In this example, it should return a constant stream of 2’s. To get that constant stream of 2’s, I have to call getBlocks() twice, where the second call will return the correct “2.” I don’t know why we have to call it twice for it to return the correct number of blocks.
Hello Josh,
Hmm, I’m not sure either. We’ll get someone here to try to reproduce this and see what we find.
Edward