Cypress Board Configuration

[Geek 2.0]

Would it be possible to reconfigure the digital inputs/outputs so that I would have more inputs than outputs, or even use the analog inputs as digital inputs? I realize I can just read the analog inputs and then manually map it to digital, but that seems roundabout, and for the application I'm using it for, slow. I heard somewhere that we would be able to reconfigure the pins.

[EricVanWyk]

Have you tried using the extended I/O configuration for the Cypress Board? Doing so will get you half way there, in that you can manually set each of the digital pins direction (and if you set it to input, you can also set whether you have a pull up, a pull down, or leave it floating).

The way the communication is architected, the analog inputs are updated just as often as the digital inputs, so making them digital inputs won't make them any faster for your purposes.

Also, may I ask what you are doing that requires speed? The extended I/O has a few neat features that may help you out here.

*I assume you mean for use at the Driver Station. If you intend to use the board on the robot, ignore everything I said: You can do whatever you want (within the rules) on the robot.

[Geek 2.0]

Originally Posted by EricVanWyk

Have you tried using the extended I/O configuration for the Cypress Board? Doing so will get you half way there, in that you can manually set each of the digital pins direction (and if you set it to input, you can also set whether you have a pull up, a pull down, or leave it floating).

Where can I find the Extended I/O configuration? That sounds like exactly what I need.

Originally Posted by EricVanWyk

The way the communication is architected, the analog inputs are updated just as often as the digital inputs, so making them digital inputs won't make them any faster for your purposes.

Also, may I ask what you are doing that requires speed? The extended I/O has a few neat features that may help you out here.

I plan on bitbanging serial data though the pins. We've been designing a separate control system, the only problem being how to get data from it to the robot. The USB is pretty complex to program for, so we decided to bitbang data. The system actually runs on I2C, and the FirstTouch supports it, but unfortunately we are required to use the firmware provided by FIRST. Also, the FirstTouch board (or w/e it's called) doesn't break out the I2C pins.

[jhersh]

You might find it easier to integrate your other system with the IO in enhanced mode instead of trying to bit bang a communication protocol. It simply wasn't designed for this.

[Geek 2.0]

What is this extended/enhanced mode? I'm constantly looking for a better way to do this, so any idea helps.

[Mark McLeod]

Look under the Driver Station IO tab and click "Configure..."

[jhersh]

In the driver station, you can click on the I/O tab, and there is a configure button at the bottom. If you click that, you can switch it to enhanced mode and then configure the digital IO.

[Geek 2.0]

Originally Posted by jhersh

You might find it easier to integrate your other system with the IO in enhanced mode instead of trying to bit bang a communication protocol. It simply wasn't designed for this.

Unfortunately, the enhanced mode does not have any sort of serial data. However, in my opinion, it should work to bitbang, and pretty quickly at that. Anyone disagree?

[jhersh]

Originally Posted by Geek 2.0

Unfortunately, the enhanced mode does not have any sort of serial data. However, in my opinion, it should work to bitbang, and pretty quickly at that. Anyone disagree?

Depends on your definition of "pretty quickly" The driver station sends packets at 50Hz. That means you can update the state of a line at 50Hz. That means if you went with something simple and fast like SPI, you could run your clock at 25Hz. That means you can transfer 3.125 bytes per second. Depending on what you're trying to talk to, that may be enough, but I don't think I'd call it quick for any application we're considering.

What is the IO that you ultimately need to interact with? Knobs? Buttons? Switches? LEDs? Like I said before, perhaps using the available IO directly will work better for your application.

[Geek 2.0]

My current plan is to use ALL of the pins on the Cypress for bitbanging. I wrote my own protocol. I would have 8 digital inputs, 4 digital outputs, a pin for the interrupt on the board it's talking to (so it knows when there's new data), and some other pins for addressing and such. Essentially, the DS sends new data and an address, flips the interrupt, and then the other system reads it. It seems roundabout, I know, but the way the system is designed, it gives us a lot of advantages, such as virtually unlimited data pins, reusability (since we write the protocol, FIRST's design changes don't affect it), a modular design (modules w/ buttons, pots, etc. send data to the master over I2C, which in turn sends it to the DS), and a few other small things on top of that. At 50Hz (I would assume the packets send/receive data for ALL the pins at 50Hz) we're perfectly fine. that gives us 50 B/s, which is more than enough. SPI is a bottleneck really.

So it seems like it should be able to handle it.

[jhersh]

Excellent... I'm glad it will work for you.

[Geek 2.0]

Actually, I have one question that I didn't think about... What is a good data refresh rate? It might be a bit slow...

[jhersh]

Originally Posted by Geek 2.0

Actually, I have one question that I didn't think about... What is a good data refresh rate? It might be a bit slow...

It completely depends on your application. What are you trying to control and how much data do you have to send? You'll never get faster than 50Hz, cause that's as fast as the DS sends data. Clearly 50Hz is plenty fast for joysticks to directly control a robot's motors.