Even if you can get exactly the rate you want, you still won't be able to control exactly when the GPIO switches at those rates. You can calibrate the delay so that, on average, your clock happens at the right time. Let us know if you find a way to make the timing reliable. You'll want to use C++ timers rather than any kind of sleep, since the sleep call has (random) overhead.
In the Options block, there is a control for Realtime Scheduling (for the entire process). Good luck! On Sat, Sep 11, 2021 at 9:38 AM Dobler, Anton <[email protected]> wrote: > Dear all, > > I tried a UHD C++ application for testing GPIO switching times and I get > at a toggle period of roughly 17us using the following code: > > while(stop_signal_called==false) > { > tx_radio_ctrl->set_gpio_attr(gpio, std::string("OUT"), "HIGH", > GPIO_BIT(4)); > > tx_radio_ctrl->set_gpio_attr(gpio, std::string("OUT"), "LOW", > GPIO_BIT(4)); > > } > > It seems like this is the upper limit concerning toggling period possible. > > Toggling the GPIOs with a period of 100us should thus be feasible... > > Does anyone has an advice how to write a low latency OOT block for > GNURadio? > > Is there a GR-API call to priorize a block? > > > Thank you for any hints! > > > ------------------------------ > *Von:* Marcus D. Leech <[email protected]> > *Gesendet:* Freitag, 10. September 2021 19:47 > *An:* Dobler, Anton; [email protected]; [email protected] > *Betreff:* Re: AW: AW: AW: USRP, GPIO toggling and Gnuradio > > On 2021-09-10 1:37 p.m., Dobler, Anton wrote: > > Thank you for that explanation! Does the transaction regarding the GPIO > states use the SFP+ ports or the management connection? > > > I will go for the raw c++ application and come back to the list ASAP. > > > Thank you all for your answers! > > That's a good question, and one for which I don't have an answer I'm > certain of. Copying the usrp-users mailing list. > > Your device is an "MPM" device, which is a server on the Linux CPU on your > device that handles "management of the radio" via > RPC calls. Browsing (very cursory) the code, it seems that it "gets" > things like I2C and SPI, so it probably also handles GPIO > transactions, it most definitely "lives" on the management interface. > > > > > ------------------------------ > *Von:* Marcus D. Leech <[email protected]> <[email protected]> > *Gesendet:* Freitag, 10. September 2021 18:59 > *An:* Dobler, Anton; [email protected] > *Betreff:* Re: AW: AW: USRP, GPIO toggling and Gnuradio > > On 2021-09-10 12:08 p.m., Dobler, Anton wrote: > > Is there any alternative to the standard GPIO UHD interface, that allows > me the desired speed and is this issue I see related to gnuradio and its > scheduler or rather to the UHD API for the GPIOs? > > > BR, > > > Anton > > Every GPIO state transition requires a transaction across your network > interface, and then into the FPGA GPIO logic. That's the absolute upper > limit on > toggling the GPIOs from the host. > > You can test how fast you can make this go with a "raw" UHD C++ program. > Once you've established how fast it can potentially go, then you start > evaluating how to approach this latency with GR. Right now, the waters > are very muddy, and I am not the one to comment on GR latencies, etc. > > > > ------------------------------ > *Von:* Marcus D. Leech <[email protected]> <[email protected]> > *Gesendet:* Freitag, 10. September 2021 18:04 > *An:* Dobler, Anton; [email protected] > *Betreff:* Re: AW: USRP, GPIO toggling and Gnuradio > > On 2021-09-10 11:54 a.m., Dobler, Anton wrote: > > I am extracting the package rate of a receive signal using a rather > complex GRC flowgraph, i.e. I am detecting the preamble of a receive signal > and generate a clock from here. This clock signal period is within the > range of 100us - 1ms. > > Toggling GPIOs using the standard GPIO interface for signals this fast is > likely not going to be very speedy. > > The GR experts will have to answer your other questions. > > > >
