Using a GPIO pin for both input and output.

[Shinigami2057]

Thanks a lot for the replies, Alan and oddjob. I had considered the use of two GPIO lines and tristate buffers to ensure that at least one of the lines was always disconnected, but as long as the single diode approach works without causing appreciable noise, I'll give it a shot.

Thanks for the code sample, oddjob! I'll report back on its success when it's implemented.

To the WPILib/FPGA guys:
I'd be nice to have the option bypass the FPGA completely and allow users to implement their own GPIO logic, for those willing to take the plunge.

[EricVanWyk]

Take a look at the I2C interface schematic for another implementation.

Originally Posted by Shinigami2057

To the WPILib/FPGA guys:
I'd be nice to have the option bypass the FPGA completely and allow users to implement their own GPIO logic, for those willing to take the plunge.

Can you explain what you mean by this? I am unsure as to what feature you want to add. The direction change timing is a function of the module, not of the FPGA image. The provided image doesn't get in the way unless you ask it to.

[oddjob]

We don't have a spare cRIO so I'm not doing any coding now. Often I2C is a special hardware module in the microcontroller and that module takes care of the I2C data line direction. Also, I2C data and clock are open drain connections.

For our robot, it would be great to have a direction controllable pin. Call it whatever, maybe DigitalPin, with a method to control the pin drive mode.

Get() to read the pin.
Set() to set the pin. (the pin needs to be set to drive for the pin to change).
DriveMode() to drive or float the pin.

If there is no FPGA constraint to changing drive mode at run time, the DigitalInput and DigitalOutput classes could be obsoleted by DigitalPin.

[Shinigami2057]

Originally Posted by EricVanWyk

Take a look at the I2C interface schematic for another implementation.



Can you explain what you mean by this? I am unsure as to what feature you want to add. The direction change timing is a function of the module, not of the FPGA image. The provided image doesn't get in the way unless you ask it to.

Thanks for the clarification; I was under the impression the FPGA was handling the digital I/O as well. If the digital I/O is left untouched, what is the expected delay of changing the direction? Is it enough to warrant using a custom circuit with two pins?

One more quick question: is there any more concrete documentation on what exactly the FPGA does and does not do, and perhaps documentation on how to interface directly with the cRIO functionality? Looking at the WPILib implementation, there's a lot of headers without corresponding source files in the DIO/ChipObject interfaces. If I'd like to work on my own interface/API, would it be possible to get more specific docs or would I have to use WPILib as a reference to how to use the hardware?