[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss-gnuradio] R: Front Panel GPIO on Ettus X310
From: |
Crozzoli Maurizio |
Subject: |
[Discuss-gnuradio] R: Front Panel GPIO on Ettus X310 |
Date: |
Tue, 1 Sep 2015 14:43:00 +0000 |
-----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.
- [Discuss-gnuradio] R: Front Panel GPIO on Ettus X310,
Crozzoli Maurizio <=