[USRP-users] Trying to understand multi_usrp::set_command_time

Marcus Müller marcus.mueller at ettus.com
Thu Oct 29 07:52:51 EDT 2015


Hi Carel,
> 1. This works correctly, but I am wondering how many commands can be
> queued like this?
Generally, infinitely; but at the point the device's internal FIFO is
full, issueing commands will simply take as long as it takes to make
room in that FIFO.
So: how deep is your FIFO?
20. I was too lazy to figure that one out by reading Verilog, so I
measured it empirically (X310, current git), my code [1].
> 2. Do I need the clear_command_time call between the first set_gpio
> and the seconds set_command_time?
No. That's just a convenience function for set_command_time(time_spec_t(0));
> So it seems like somewhere the software gets blocked and waits for the
> command to be executed before it continues. 
get_time_now is if I remember correctly amongst the commands that end up
in that queue, as it's just a register read.

Best regards,
Marcus

[1] https://github.com/marcusmueller/timed_cmd_fifo_test



On 29.10.2015 07:20, Carel Combrink via USRP-users wrote:
> Hi,
>
> I am trying to set timed commands using multi_usrp::set_command_time()
> but it is not behaving as I am expecting and the documentation is not
> very clear around this command.
>
> What I want to achieve:
> While transmitting bursts, I want to schedule a GPIO pin to go high
> and then low after a small time.
> Pseudo code:
> set_command_time(timeHigh)
> set_gpio_attr(pin high)
> clear_command_time()
> set_command_time(timeLow)
> clear_command_time)
> set_gpio_attr(pin low)
>
> 1. This works correctly, but I am wondering how many commands can be
> queued like this?
> 2. Do I need the clear_command_time call between the first set_gpio
> and the seconds set_command_time?
>
> Now the part that I do not understand: I added a printout of
> get_time_now() before and after the above code and get the following
> output (code not given since from the output it should be clear):
> Start Time:  1446018188.316676090000000
> High      :  1446018193.004600000000000
> Low       :  1446018193.004602000000000
> End Time  :  1446018193.004602140000000
>
> So it seems like somewhere the software gets blocked and waits for the
> command to be executed before it continues.
>
> So after some investigation and tests I added a timer to the code to
> time the execution of the different commands with the following output:
> Start Time    :  1446018640.315072090000000
> T now() 1 (ns):  68523
> High          :  1446018645.004600000000000
> Low           :  1446018645.004602000000000
> T cmds    (ns):  139416
> End Time      :  1446018645.004602140000000
> T now() 2 (ns):  4689572696
>
> I first time the get_time_now() command, followed by the time for all
> of the code described above, then time the call to the last
> get_time_now(). From this it seems like the last get_time_now() only
> returns after the time elapsed for the last timed command.
>
> Is this expected, is there a bug or is my test logic wrong?
>
> My code works correctly, but I had to remove a few calls
> to get_time_now(). 
>
> Device: X310 over GigE
> UHD version: UHD_003.009.000-7-g8adefb1d
> OS: Ubuntu Linux
>
> Regards,
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151029/69012b19/attachment-0002.html>


More information about the USRP-users mailing list