What to use the Cypress board for?

[AsianSensation]

So we got a Cypress IO board, but I was curious what to use it for. My initial thoughts are connecting buttons to the pins and use the buttons to do commands, but if that is what it is used for, how would I attach buttons and how would I program for it?

[Christopher149]

Code-wise, assuming you were using Java (they are all relatively similar) you would use the DriverStation class and the getDigitalIn(int channel) method to get the state of the buttons.

Our team has used it for a variety of buttons, switches, dials, and LEDs.

[AsianSensation]

Originally Posted by Christopher149

Code-wise, assuming you were using Java (they are all relatively similar) you would use the DriverStation class and the getDigitalIn(int channel) method to get the state of the buttons.

Our team has used it for a variety of buttons, switches, dials, and LEDs.

Thanks! How would I hook up the buttons tho? Where do I connect the button to the IO slot?

[Alan Anderson]

http://www.usfirst.org/uploadedFiles...t%20tables.pdf gives pinout information.

[BitTwiddler]

If I may take off on a slightly different tangent regarding the Cypress board I have a question.
It seems nobody on the team can seem to locate our old board. It looks to me like the board is available and as long as we update it with the FRC version of the PSoC programmer we should be able to use the new board.

Has anybody had any problems purchasing the board from Cypress and getting it to work with the FRC Driver Station after updating the FRC firmware?
Thanks.

[Mark McLeod]

I've had a problem getting some of the new boards to flash.
You may have to recompile the firmware for the newer revision.
The risk is if they've upgraded it somehow.

The only issues I've encountered while actually using the board have been that it needs a dedicated USB port on the Driver Station to be powered properly.
Sharing a hub with joysticks can brown out your controls, i.e., they will appear to be connected, but they won't respond to button pushes or axis tilts.
If your design causes it to heavily draw on power, then there is a risk it will fail when your laptop is running on low battery.

[apalrd]

Back when the Cypress board was new in 2010, we had a TON of issues with reliability of the drivers, and getting the drivers installed on non-classmate driver station laptops. In 2010, we HAD to boot up our laptop 3 matches ahead of time in the queue, since a driver failure would require us to reboot the classmate once or possibly twice to regain functionality after putting the classmate to sleep. We also had no operator (cypress-IO) control in two matches at our first event because we didn't understand the problem, and implemented a whole bunch of code to detect a Cypress failure and reroute button inputs to the driver's gamepad (Logitech DualAction) as a workaround. It was super ugly and we hated it and complained a ton and I have no idea what happened in later releases since we never used it again (and never will).

Since we stopped using the classmate as a driver station laptop, I haven't been able to get the 2010 bot's operator box to work since. We eventually wrote code to use the 2012 bot's operator box so we could use the robot for demonstration (since it looks cool).

We now use the Uhid, which acts like a native HID joystick device to the laptop and requires no drivers. It doesn't support outputs in our use (acting as a joystick to Driver Station), but it was very reliable and we had no issues. No big deal, we don't like on-DS LED's anyway since the driver has to look down to see them. Also, it doesn't auto zero the joystick inputs, so you can use potentiometers with the analog inputs without a problem.