[Discuss-gnuradio] R: Front Panel GPIO on Ettus X310

[Crozzoli Maurizio]

Moritz,
if you wanted to scare me, you succeeded!

What you propose goes far beyond my current skills and it also looks 
excessively complicated compared to my needs: really no easier way to detect an 
external trigger?

Furthermore I cannot understand the meaning of the example in "The E3x0/X3x0 
Front Panel GPIO" manual:

"We are also using GPIO4, which we want to control manually, as an output.
[...]
// set up our values for ATR control: 1 for ATR, 0 for manual
[...]
After the above code is run, the ATR in the FPGA will automatically control 
GPIO6, as we have described, based on the radio state, and we have direct 
manual control over GPIO4."

So, what does it mean "After the above code is run, [...] we have direct manual 
control over GPIO4."? It thought it could be the solution to my need (a GPIO 
port to read an external trigger - except for the GPIO direction, a detail) but 
according to what you write (which is coherent with the introduction of the 
cited manual page: "These GPIO pins are controlled directly by the FPGA, where 
they are controlled by an ATR (Automatic Transmit / Receive).") it looks it is 
not: could you please explain the point?

TIA!

BR,
Maurizio.

-----Messaggio originale-----
Da: Moritz Fischer [mailto:address@hidden
Inviato: mercoledì 5 agosto 2015 23:56
A: Crozzoli Maurizio
Cc: address@hidden
Oggetto: Re: [Discuss-gnuradio] Front Panel GPIO on Ettus X310

Maurizio,

On Wed, Aug 5, 2015 at 7:49 AM, Maurizio Crozzoli <address@hidden> wrote:
> Hi Martin or others who can support me, I have a problem which is
> similar as Frank's: I have an E310 and I want to receive a and
> external trigger on a pin which starts an acquisition process of a
> burst of samples from the radio source.

In the default FPGA image the GPIO pins are wired up to ATR pins that are 
connected to the radio0.

https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300.v#L112
https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300.v#L375
https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300.v#L659
https://github.com/EttusResearch/fpga/blob/master/usrp3/top/e300/e300_core.v#L304

would be your places to start.

If you want to use our GPIO API take a look at:

http://files.ettus.com/manual/page_gpio_api.html

>
> Stated that I have to remove the box around the E310 to have access to
> the GPIO ports (not a problem!), according to what I have read so far
> in this thread, no way to reach my goal but using C++ (no GRC!). Not
> an easy task for me but I do hope I can do it.
>
> What I need you support about is related to the right approach I
> should follow. I would think that I should write a "while" loop which
> runs in ARM processors where one on the available GPIO port is constantly 
> monitored:
> when the trigger is detected the acquisition process of a burst of
> samples from the radio source is started and, once it has been
> completed, the flow goes back to the GPIO port monitoring.

You could either fork of a thread to monitor the ports through the UHD API, or 
rewire stuff in the FPGA (as pointed out above) to use the Zynq's GPIO_I 
signals in the FPGA.
You could then use the default kernel sysfs GPIO API to use GPIO interrupts.

places to start investigating are:

https://www.kernel.org/doc/Documentation/gpio/sysfs.txt
http://elinux.org/GPIO#GPIO_interrupts_from_user_space

maybe there are python bindings available?

>
> Is there any example code I be inspired from? OF course I have to
> study what can be found in the manual page "The E3x0/X3x0 Front Panel
> GPIO", but, together with the suggested gpio.cpp example under UHD, it
> looks like there is more emphasis on the ATR mechanism, which - I
> think - has nothing to do with the problem I have to solve.

That is true, see the above links. Depending on latency requirements, and your 
input signal, the ATR API might not be what you need.
>
> Martin or others, could you please comment on my problem?
>
> TIA!
>
> BR,
> Maurizio.
>
> PS If you think that, according to what I have understood so far, I
> will need to use RFNoC in order to cope with the sampling speed
> constraints of the acquisition process of a burst of samples from the
> radio source, you might well understand how much I need your help, and
> not just for this post...

Just for the GPIO part no requirement of using RFNOC.
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/Front-Panel-GPIO-on-Ettus-X310-tp53979
> p55274.html Sent from the GnuRadio mailing list archive at Nabble.com.
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Happy hacking,

Moritz

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone 
indicate. La diffusione, copia o qualsiasi altra azione derivante dalla 
conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate 
ricevuto questo documento per errore siete cortesemente pregati di darne 
immediata comunicazione al mittente e di provvedere alla sua distruzione, 
Grazie.

This e-mail and any attachments is confidential and may contain privileged 
information intended for the addressee(s) only. Dissemination, copying, 
printing or use by anybody else is unauthorised. If you are not the intended 
recipient, please delete this message and any attachments and advise the sender 
by return e-mail, Thanks.