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

-----Messaggio originale-----
Da: Moritz Fischer [mailto:moritz.fischer@ettus.com]
Inviato: lunedì 31 agosto 2015 19:35
A: Crozzoli Maurizio
Cc: discuss-gnuradio@gnu.org; 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 <maurizio.crozzoli@telecomitalia.it> 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.

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