<< return to Pixycam.com

ColorCodes and SPI - SS -- am I correct

Pixy Software
#1

I am trying to program a robot to follow objects with color codes. The micro is a Parallax Propeller so I’m not using the Arduino libraries.

Currently, I have it following color signatures using the UART interface, but for CC I need a faster interface. I have programmed an SPI (not -SS), and it works, but the program spends a lot of time looking for sync bytes and word boundaries and frame starts. Note I am using a previous version of the firmware & pixymon.

If I am reading the wiki correctly, the new firmware with SPI-SS, should help a lot. Here’s my thinking –
If I select CC Mode 2 (CC only) whenever pixy sends $aa55, that will be a Frame Start (there should be no other aa55 sent since pixy is not sending color signature blocks.) (Correct?)

And when using SPI-SS, when the SS is made low, Pixy sends words (HIBYTE, LOWBYTE), so I will not have to program to find the start of a word. (Correct?)

If both are correct, then I have to try to understand when I have to send bytes back to pixy.

Tom

#2

Tom Montemarano wrote:

If I am reading the wiki correctly, the new firmware with SPI-SS, should help a lot. Here’s my thinking –
If I select CC Mode 2 (CC only) whenever pixy sends $aa55, that will be a Frame Start (there should be no other aa55 sent since pixy is not sending color signature blocks.) (Correct?)

That’s correct.

And when using SPI-SS, when the SS is made low, Pixy sends words (HIBYTE, LOWBYTE), so I will not have to program to find the start of a word. (Correct?)
If both are correct, then I have to try to understand when I have to send bytes back to pixy.

I believe you need to set the SS (like you have described) and you need to send sync data (described below, see “spi tries to confuse things”):
http://cmucam.org/projects/cmucam5/wiki/Porting_Guide

Hope this helps!

#3

Thanks for the info.
One thing I am not sure about is this-- Do I have to send a sync byte before each 8 bit read or can I send one sync byte and read a complete 16 bit word?

I’m also confused about the difference between PIXY_SYNC_BYTE (0x5a) and PIXY_SYNC_BYTE DATA (0x5b).
Which sync byte is used to just request pixy to send block data (0x5a or 0x5b)?
Is the other one used when sending or what does it do?

With my micro the way I use SPI is to

  1. enable the chip select

  2. Use a command like "void spi_out(vbits, value) where value is a command for the device to send data and vbits is the number of bits in “value”.
    I think that is where I would send the sync byte.

  3. Then read the sent data with "x = spi_in(xbits) where x bits is the number of bits in “x”.

  4. Disable chip select.

With the earlier version of pixy SPI which did not use syncs, once I found the start of a word, I would just read a full 16 bit word each time I did number 3 above. I’m not sure if that is still possible? If not what do I send to get the second byte?

Thanks
Tom

#4

Hi Tom,

This is the heart of it— and yes, lots of things are going on here:

int16_t getWord()
{
  // ordering is big endian because Pixy is sending 16 bits through SPI 
  uint16_t w;
  uint8_t c, cout = 0;

  if (g_outLen)
  {
    w = getByte(PIXY_SYNC_BYTE_DATA);
    cout = g_outBuf[g_outReadIndex++];
    g_outLen--;
    if (g_outReadIndex==PIXY_OUTBUF_SIZE)
      g_outReadIndex = 0; 
  }
  else
    w = getByte(PIXY_SYNC_BYTE); // send out sync byte
  w <<= 8;
  c = getByte(cout); // send out data byte
  w |= c;

  return w;
}

Everything in SPI with Pixy is sent/received on 16-bit exchanges. So you either send:

  1. 0x5a and 0x00 (here, 0x5a is just a sync byte so Pixy knows that it has the right byte framing and 0x00 is just a dummy byte)
  2. 0x5b and data (here, 0x5b is also a sync byte, but it also tells pixy that the next byte is legitimate data)

So in either case you are sending 2 bytes, or 16 bits and getting 16 bits back, and the 16 bits are always block data. You get 0’s if there is are no detected blocks.

#5

Thanks, that’s what I needed.
Tom