discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: USRP, GPIO toggling and Gnuradio


From: Jeff Long
Subject: Re: USRP, GPIO toggling and Gnuradio
Date: Fri, 10 Sep 2021 10:29:58 -0400

A sleep is implemented by the kernel, not the scheduler, so what you're seeing is that the kernel can not reschedule threads faster than 20kHz (which is pretty fast). For higher speed, you'll need some sort of driver that works closer to real time.

On Fri, Sep 10, 2021 at 10:21 AM Dobler, Anton <anton.dobler@unibw.de> wrote:

Dear all, 

I am currently trying to write an OOT block to switch a GPIO pin high or low depending on the input signal. So far it has worked with the configuration of the pins and I can also switch the pins according to the input signal in a relatively simple flowgraph consisting of a signal generator that produces a square wave signal. 

The block's work function looks like this:

int GPIO_IO_impl::work(int noutput_items,
            gr_vector_const_void_star &input_items,
            gr_vector_void_star &output_items)
    {        

        
        const float *in_signal = (const float *) input_items[0];
       

        for(int i=0; i < noutput_items; i++) {
           
            if(in_signal[i] >= d_threshold)
            {
                 _dev->set_gpio_attr(gpio, std::string("OUT"), "HIGH", 0xffffffff)                 
            }

            if(in_signal[i] < d_threshold)
            {
                 _dev->set_gpio_attr(gpio, std::string("OUT"), "LOW", 0xffffff);
            }
        boost::this_thread::sleep_for(boost::chrono::nanoseconds((unsigned long long)d_samp_period));

        }

        return noutput_items;
    }

The sleep function is important in that without it, regardless of the sampling rate of the square wave signal, the pin is switched with a period of 20us. If I use the sleep function, the whole thing works better, but only up to a sampling rate of about 20kHz. I have read a little bit about the function of the scheduler in GNURadio, but I did not find a solution.

Starting from the standing approach, I have tried using both Timed Commands and Boost Signals, with the result that the pins are switched completely asynchronously. Since I don't really know what to do at this point, I wanted to ask if any of you had experience with this kind of OOT block in GNURadio.


Best regards, 


Anton





reply via email to

[Prev in Thread] Current Thread [Next in Thread]