<< return to Pixycam.com

Remove init function out of class LinkSPI

Pixy Software
#1

I’am french, so sorry for my bad english hereunder.

The class LinkSPI define the SPI init function in Pixy.h :

  void init(uint8_t addr)
  {
    SPI.setClockDivider(SPI_CLOCK_DIV16);
    SPI.begin(); 
  }

I use a 1.8" TFT LCD screen with a SPI_CLOCK_DIV4 parameter for 4MHz clock. It differ with the init function of Pixy (SPI clock at 1Mhz).

I would suggest to do remove the init function from the LinkSPI class, in order to give the possibility to make one init function for mutliples SPI devices (Pixy and others devices).

Pixy could run at higher SPI clock speed like 8MHz (with Arduino) or 16MHz (with raspberry pi) ?

#2

Hi Phillippe,

Thanks for the suggestion! We will likely refactor much of our code over the next few months, as I’m sure many people will have a similar issue as yourself.

Feel free to submit a pull request if you ever have modifications/additions you think would be helpful.

Thanks!

Scott

#3

Hello again,

To address your question about setting the SPI clock higher on the Arduino, there is a problem with that. We have to generate our own slave select signal on the Pixy side – this limits things to a couple mbits/sec. Going higher can cause more errors. Nothing bad happens, just more errors. They are detected and dealt with.

So the spi we have is designed for Arduino ICSP connector with no slave-select signal. We need to create a separate SPI mode for non-Arduino-with-slave-select. We’re not entirely sure when this will happen, but hopefully soon. Support from the community would be great :slight_smile:

Scott

#4

Scott,

Regarding “support from the community” on writing code for Pixy’s NXP processor, do you have a tutorial or guide that will help someone set up a local development environment to work with this processor? If not, I would strongly suggest it since you will have a lot more people jumping in to help if it’s easy enough to set something up. Even if they are not coding experts they can help test code pull requests if given some guidance :wink:

#5

Hi.

So we cannot have multiple Pixies via spi? When I saw the spi pinout for slave select, I thought it was already available.

It would be great to have this feature, otherwise, we’ll need to use i2c.

Brian

#6

Hi Brian,

I2C would be a better option for you if you need to connect multiple Pixys. Unfortunately the ICSP connector on the Arduino does not have the SS pin, so we had to make a workaround on Pixy. With non-Arduino devices we can use SS, but we would need to create a separate SPI mode to support this. I’ll get back to you in a bit with a status update on that.

Scott

#7

Thanks. The problem is that i2c is often used by multiple devices and can get quite slow, especially when it’s limited to a low clock rate.

The support for a different SS would be great. Perhaps you could go into SS/CS SPI mode if pin 7 (SS) is HIGH for over a certain time limit at the start of the program. Just a thought.

I’ll use i2c for now.

Brian

#8

Hi Brian — this is on the list. Out of curiosity, which platform are you using (to talk to Pixy)?

#9

Hi Scott,

Currently I’m using teensy 3.1s/Arduino for convenience.

Brian

#10

So the teensy doesn’t have an ICMP connector (I don’t think), but you can still connect the SPI clk and data to Pixy and it will work just fine (you just don’t do anything with the SS signal). This applies to any platform. The only issue with SS is when you want to connect multiple devices to SPI…

#11

Correct. That’s exactly what we did this year with our robots. We compete in a robot soccer competition and have found the Pixy extremely useful this year at aiming towards the coloured goals. For next year, we’re hoping to get two Pixies (at the front and back) to allow us to play in a defensive mode (aligning the back of the robot to our own goals), hence the need for the SS pin should we use SPI. Now, it’s unlikely for us to use SPI, but instead we’re most likely to be using i2c, as we also have multiple other SPI devices (SD cards, IMU etc.).

Honestly, I don’t think this should be at the top of the priority list for features. Instead, I think it’d be great if there was some method of giving/writing and reading the pixy signatures. This year, we had to calibrate the signatures for each Pixy before every round since we had two robots. It would be much more ideal if we could just calibrate one, get the master robot to send the signatures to the other robot and get the other robot to set the signatures on the Pixy.

Brian

#12

In the head revision of github we have save and load parameters in PixyMon (official release in a couple weeks!) So you can get things working on one Pixy, save the parameters (includes signatures) and then load the same parameters into the other Pixys. So this might help y’all. (yes?)

Save and load parameters is possible right now in libpixyusb (but you need to be talking over USB). Saving and loading parameters over SPI/I2C isn’t on the to-do list (so the speak).

See
http://cmucam.org/projects/cmucam5/wiki/Building_the_libpixyusb_example_on_Linux