Digital I/O Direct Access

[igttgit]

Amateur question:
I am trying to connect a 12 bit ADC through the digital IO of the RP board. The question is, does one have to wire up the ADC through the FPGA and mem map it like I do for the 125MS on board ADC, or does the CPU have direct access to the digital pins ? If so, how does one call them from C ?

This amateur Q also extends to all the other I/O on the headers, are they connected directly to the CPU ? In which case how does one access the slow ADC, I2C, UART etc directly from C?

Thank you in advance for your patience.

[Nils Roos]

[...] does the CPU have direct access to the digital pins ? [...] This amateur Q also extends to all the other I/O on the headers, are they connected directly to the CPU ? In which case how does one access the slow ADC, I2C, UART etc directly from C?

Some are, some are not.
The 16 GPIOs and the 4 slow DACs can only be accessed through the FPGA registers. The slow ADC, I2C, SPI, and UART are available as linux devices and can be controlled with the standard OS functions. There are some examples on redpitaya.com .

[igttgit]

Thank you for your reply. I have used the examples to access linux IO functions and have found them to be mercifully simple to access SPI UART and I2C.

The analogue slow read example however is not as good. I cannot find the original function to which rp_ApinGetValue refers to and thus the name of the linux handle.

Going through Pavel's notes, I have found an IP to read digital pins in "adc_recorder_trigger" through the "AXI-Stream GPIO Reader" block.
Is there a similar 'write' function ? I will write my own Verilog if not, but its always best to ask to save time.

P.S. how is the progress on the logic analyzer project ? I just got a BitScope, thinking of making a similar utility when I have some free time, just need to master the I/O first.

[Nils Roos]

I cannot find the original function to which rp_ApinGetValue refers to and thus the name of the linux handle.

See this post for the devicenames.

Going through Pavel's notes, I have found an IP to read digital pins in "adc_recorder_trigger" through the "AXI-Stream GPIO Reader" block.
Is there a similar 'write' function ? I will write my own Verilog if not, but its always best to ask to save time.

It is probably even simpler than that. Xilinx already provides a driver that can address pins as GPIOs (via their configuration registers, I believe) - see the red heartbeat LED for example. With the right entries in the devicetree all you need to do is to remove the existing IOBUFs. (I'm not absolutely sure it will work this way, never tried it)
edit:
Maybe it's not quite as easy, because all MIO slots are already occupied. Activating EMIO GPIOs and routing them to the IOBUFs will probably be required in order to use the stock driver.

how is the progress on the logic analyzer project ?

I wouldn't know, I never heard any details of nor participated in such a project.

[igttgit]

Successful solved !

The whole point is that I want to write my own drivers for everything, my acquisition and proc program is 800 lines of C and growing.
To clarify, I have tested the utility buffer IP and was unable to interface with GPIO.

The "Select IO Interface Wizard" link below, however works beautifully to interface the GPIO
http://www.xilinx.com/support/documenta ... io-wiz.pdf

Thank you Xilinx and Nils

[igttgit]

P.S.
A follow up query.
I'm trying to drive the GPIO pin with a 50 Ohm output chip, and to my horror
I found that the high voltage on the pin is about 2V, making the input impedance of GPIO pin of about 100 Ohm,
and consequently not reading as a high

I have measured the driving current from 3.3 V pin to GPIO pin, and it drives it with 36mA, this seems unusually high.

Can the input impedance of the GPIO pin be controlled ?
i.e. am I making a mistake while configuring it through the Select IO Interface Wizard

[Nils Roos]

Are you certain the GPIO is configured as an input ?

To me this looks like you are outputting 0V on the GPIO and your external circuit drives 3.3V, so the GPIO sinks as much current as it is programmed to with a voltage drop of 1.3V (you can program the drive strength in output mode, which affects both sourcing and sinking current).

In input mode, the GPIO should have a very high impedance.

[igttgit]

I configure it as a bidirectional IO because I need 12 ports for input, 4 for out.
In retrospect I should have configured the inputs and outputs discretely through the XDC constraint file, however I have found that 100 Ohm pull-up resistors on my device trigger the inputs reliably and thus I will continue using bidirectional IO because of the general purpose reassignment ease.
As a side effect, this has greatly minimized ringing on the pins.

As to why this happens, I think this is for the purpose of impedance matching, if the FPGA pin is connected as 50 Ohm res from pin to vdd/2, this would make a perfect match for 50 Ohm lines. This is also equivalent to two 100 ohm res, pin to gnd and pin to vdd.
Feeling so ignorant of high speed digital design right about now.

[igttgit]

An Update, I was wrong

The pins were indeed configured as outputs and I was sinking current into the output.
I have remedied the problem by re-writing the SelecIoWizard to include bitmasking to select in/out mode

The git link for the IP below:
https://github.com/igttgit/Red_Pitaya_GPIO.git