Hi Andy,
On 04.02.2016 20:32, Andy Walls wrote:
> On Thu, 2016-02-04 at 17:53 +0000, Nowlan, Sean wrote:
>
>> Thanks, Andy. I haven't yet encountered any issues from initializing
>> USRP settings (freq/gain/antenna/etc.) from "main" thread and polling
>> PPS from another thread,
> Neither have I. (FWIW, I poll the GPSDO NMEA strings and USRP timestamp
> synchronized to the USRP PPS output pulse provided to the host's serial
> port DCD line at RS-232 levels.)
It's probably OK, but: There's no guarantees what will happen if thread
A (main) writes to a specific device register, e.g. to read back
something from the USRP in the next call, and then thread B (e.g. the
thread in which the usrp_sink block runs in) simultaneously reads
something from the device.
This is multithreading with external hardware; be vary, here be race
conditions.
>
>> since the polling thread doesn't actually start until the main thread
>> calls "start" on my OOT block until after it's finished configuring
>> the USRP at startup.
> Ah, smarter than what I did. My block's polling thread just waits 1
> second at startup, and then drops into a loop around a
> blocking ::time_pps_fetch() call.
>
>> Regarding the order of instantiation, I should update what I said
>> about the USRP block alias: Under the USRP Sink config settings in
>> GRC, the user can set the block alias under the Advanced tab.
> OK, I never noticed that.
:) forgot about that completely!
>
> -Andy
>
>> I set this to the same value as what I pass to my OOT block:
>>
>> // gr-my-oot/include/my-oot/clock_manager.h
>> class MY_OOT_API clock_manager : virtual public gr::block
>> {
>> …
>> public:
>> static sptr make(const std::string &usrp_alias);
>> …
>> }
>>
>>
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
