Re: [Discuss-gnuradio] Front Panel GPIO on Ettus X310
Ciao Maurizio,
On Mon, Aug 31, 2015 at 9:03 AM, Crozzoli Maurizio
<maurizio.crozz...@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.
>
> 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:moritz.fisc...@ettus.com]
> Inviato: mercoledì 5 agosto 2015 23:56
> A: Crozzoli Maurizio
> Cc: discuss-gnuradio@gnu.org
> Oggetto: Re: [Discuss-gnuradio] Front Panel GPIO on Ettus X310
>
> Maurizio,
>
> On Wed, Aug 5, 2015 at 7:49 AM, Maurizio Crozzoli
> <maurizio.crozz...@telecomitalia.it> 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
Re: [Discuss-gnuradio] Front Panel GPIO on Ettus X310
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. 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. 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. 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... -- View this message in context: http://gnuradio.4.n7.nabble.com/Front-Panel-GPIO-on-Ettus-X310-tp53979p55274.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Front Panel GPIO on Ettus X310
Maurizio, On Wed, Aug 5, 2015 at 7:49 AM, Maurizio Crozzoli maurizio.crozz...@telecomitalia.it 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-tp53979p55274.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Happy hacking, Moritz ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Front Panel GPIO on Ettus X310
Hi Martin, Thanks for the response. It looks like we'll have to go the C++ route then. Thanks for your assistance. Best Regards, Frank From: Martin Braun-2 [via GnuRadio] [mailto:ml-node+s4n53983...@n7.nabble.com] Sent: Monday, June 01, 2015 7:50 PM To: Falessan Subject: Re: Front Panel GPIO on Ettus X310 Hey Frank, multi_usrp is exactly what the GNU Radio blocks use under the hood. However, multi_usrp is *not* SWIGged -- which means you can't access multi_usrp from Python. I believe that's what's triggering your error message. get_device() can only be called on your USRP blocks using C++. Now, if you *were* to use C++, I'd recommend having a look at the 'gpio' example in UHD. It shows how to map ATRs to GPIOs, which sounds like what you're trying to do. I can see how these GPIO functions would be useful in a swigged fashion, though, and maybe even available by command tag. We should get them onto master. M On 01.06.2015 14:23, Falessan wrote: Hi, I would like to command the Front Panel GPIO pins for use as a trigger signal to another piece of equipment under gnuradio and python (I'm not a C++ programmer). I've been trying unsuccessfully to use the UHD multi_usrp get_gpio_banks and the set_gpio_attr commands to control the I/O pins. I receive an Attribute error: 'usrp_sink_sptr' Object has no attribute . My questions are: 1)Has the UHD multi_source class been incorporated into the GNU Radio API ? 2) Is it currently possible to interface to the GPIO pins without under Gnuradio without going the C++ route ? Best Regards, Frank Alessandro ___ Discuss-gnuradio mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio _ If you reply to this email, your message will be added to the discussion below: http://gnuradio.4.n7.nabble.com/Front-Panel-GPIO-on-Ettus-X310-tp53979p53983 .html To unsubscribe from Front Panel GPIO on Ettus X310, click here http://gnuradio.4.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_ by_codenode=53979code=ZnJhbmsuYWxlc3NhbmRyb0Bjb21jYXN0Lm5ldHw1Mzk3OXwtMTY1 OTUzNjIwMQ== . http://gnuradio.4.n7.nabble.com/template/NamlServlet.jtp?macro=macro_viewer id=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicName space-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.Node Namespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_email s%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml NAML -- View this message in context: http://gnuradio.4.n7.nabble.com/Front-Panel-GPIO-on-Ettus-X310-tp53979p53990.html Sent from the GnuRadio mailing list archive at Nabble.com.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Front Panel GPIO on Ettus X310
On 02.06.2015 06:42, Falessan wrote: Hi Martin, Thanks for the response. It looks like we’ll have to go the C++ route then. Thanks for your assistance. Happy to help, if you run into more issues, just ask. As I mentioned, I recommend reading the gpio example in UHD for more help. Cheers, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Front Panel GPIO on Ettus X310
Hi, I would like to command the Front Panel GPIO pins for use as a trigger signal to another piece of equipment under gnuradio and python (I'm not a C++ programmer). I've been trying unsuccessfully to use the UHD multi_usrp get_gpio_banks and the set_gpio_attr commands to control the I/O pins. I receive an Attribute error: 'usrp_sink_sptr' Object has no attribute . My questions are: 1)Has the UHD multi_source class been incorporated into the GNU Radio API ? 2) Is it currently possible to interface to the GPIO pins without under Gnuradio without going the C++ route ? Best Regards, Frank Alessandro -- View this message in context: http://gnuradio.4.n7.nabble.com/Front-Panel-GPIO-on-Ettus-X310-tp53979.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Front Panel GPIO on Ettus X310
Hey Frank, multi_usrp is exactly what the GNU Radio blocks use under the hood. However, multi_usrp is *not* SWIGged -- which means you can't access multi_usrp from Python. I believe that's what's triggering your error message. get_device() can only be called on your USRP blocks using C++. Now, if you *were* to use C++, I'd recommend having a look at the 'gpio' example in UHD. It shows how to map ATRs to GPIOs, which sounds like what you're trying to do. I can see how these GPIO functions would be useful in a swigged fashion, though, and maybe even available by command tag. We should get them onto master. M On 01.06.2015 14:23, Falessan wrote: Hi, I would like to command the Front Panel GPIO pins for use as a trigger signal to another piece of equipment under gnuradio and python (I'm not a C++ programmer). I've been trying unsuccessfully to use the UHD multi_usrp get_gpio_banks and the set_gpio_attr commands to control the I/O pins. I receive an Attribute error: 'usrp_sink_sptr' Object has no attribute . My questions are: 1)Has the UHD multi_source class been incorporated into the GNU Radio API ? 2) Is it currently possible to interface to the GPIO pins without under Gnuradio without going the C++ route ? Best Regards, Frank Alessandro ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
