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

[Crozzoli Maurizio]

-----Messaggio originale-----
Da: Moritz Fischer [mailto:address@hidden
Inviato: lunedì 31 agosto 2015 19:35
A: Crozzoli Maurizio
Cc: address@hidden; Disco Daniele
Oggetto: Re: [Discuss-gnuradio] Front Panel GPIO on Ettus X310

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.

To be honest, currently I do not really know anything about the latency 
requirement. I would say that in this proof-of-concept stage of the design, the 
"best-we-can-do" approach could be acceptable. Of course it would be very 
helpful for us in view of an estimate of the effect of the latency if you could 
suggest a reasonable estimate of the latency measured in a condition where we 
assume to operate with an E310 and just test every run for the state of a pin 
of the GPIO port with an instruction like 
'usrp_e300->get_gpio_attr("INT0","READBACK")'. That change of state should 
happen every tens to few hundreds of milliseconds and when it happens an 
acquisition of I&Q data through RFNo (if we are able to implement it...) should 
be performed.

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

So let's say that may be what manual says in the introduction of the section 
devoted to GPIO is too strong: " The E3x0/X3x0 are the first USRP devices to 
offer an auxiliary GPIO connection on the motherboard itself (independent of 
the daughterboards). These GPIO pins are controlled directly by the FPGA, where 
they are controlled by an ATR (Automatic Transmit / Receive). This allows them 
to be toggled simultaneously with other radio-level changes (e.g., enabling or 
disabling a TX or RX mixer)."

In fact, according to it, one would guess that the ATR functionality is the 
ONLY one implemented and available. On the contrary, as a matter fact, also the 
"classical" manual approach where things are controlled by sw 
{get,set}_gpio_attr functions is feasible. Interesting to know for... newbies 
like me.

Maurizio.


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.