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

[Moritz Fischer]

Ciao Maurizio,

On Mon, Aug 31, 2015 at 9:03 AM, Crozzoli Maurizio
<address@hidden> wrote:
> Moritz,
> if you wanted to scare me, you succeeded!

That wasn't my intend, sorry. I merely tried to elaborate on different
factors that might play into the choice of solution that will work
best for your solution.
>
> 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?

I'm still not clear on how tight your latency requirements for that
trigger detection are. If you are ok to just poll with a 'slow'
software loop then using the get_gpio_attr() function will probably be
fast enough.
>
> 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."

What this means is that the GPIO6 will be controlled by the ATR's
logic, while the GPIO4 is user controlled via the set_gpio_attr()
functions, i.e. the state of GPIO6 is controlled by the radio state
{tx,rx,xx} while GPIO4 is controlled by API calls.
>
> 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?

See above. As you correctly observed you just want to set the mode to
manual control (so the FPGA's state machine will not interfere), and
control the GPIOs using {get,set}_gpio_attr, possibly in a separate
thread.

>
> 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.
>

I hope I could clarify this a bit

- Moritz