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

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:moritz.fischer@ettus.com]
Inviato: mercoledì 5 agosto 2015 23:56
A: Crozzoli Maurizio
Cc: discuss-gnuradio@gnu.org
Oggetto: Re: [Discuss-gnuradio] Front Panel GPIO on Ettus X310

Maurizio,

On Wed, Aug 5, 2015 at 7:49 AM, Maurizio Crozzoli <maurizio.crozzoli@telecomitalia.it> 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
> Discuss-gnuradio@gnu.org
> 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.

_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio