On Tue, Feb 18, 2025 at 7:13 PM <[email protected]> wrote:
> Hi Martin,
>
> I don’t fully understand you comment about it not being the block
> controller. (bear with as I am not super experienced)
>
> At the moment I have not trapped a timeout exception just yet (see snippet
> below). It could well be somewhere else in the application as you say.
>
If you're not catching an op_timeout, then the poke/peek is not the
problem. If your code below is timing out, then check the mutexes.
>
> ------------------------------
>
> try
>
> {
>
> lock_mutex();
>
> // Write to the calculated address
>
> siggen_block->regs().poke32(address, data->data[0]);
>
> unlock_mutex();
>
> lnx_uhd_status = true;
>
> }
>
> catch(const uhd::op_timeout& e)
>
> {
>
> std::cerr << "Write exception: " << e.what() << '\n';
>
> }
>
> catch(const std::exception& e)
>
> {
>
> std::cerr << "Write exception: " << e.what() << '\n';
>
> unlock_mutex();
>
> }
>
> ------------------------------
>
>
> If you don’t mind, regarding David’s email above (points 2 and 3) could
> you comment on these
>
> For point 2. this makes sense to me, would you also recommend the same?
>
Yes this make sense; make sure that span is not too small though.
> for point 3. After setting up the LO, I am checking the lock flags in a
> loop with a time-out, after which I clear the command time:-
> radio_ctrl[radio_id]->clear_command_time(0);
>
If you're polling on the lock state, make sure to call clear_command_time()
*before* you start doing that.
--M
_______________________________________________
USRP-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
