-----Messaggio originale-----
Da: Moritz Fischer [mailto:[email protected]]
Inviato: lunedì 31 agosto 2015 19:35
A: Crozzoli Maurizio
Cc: [email protected]; 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
[email protected] 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.