On 10/08/2020 03:33 PM, David Taylor (manx.net) via USRP-users wrote:
Point taken. - I didn’t actually check the original default values of
the VID and PID, but they were reset according to the table provided,
so that they could be tested as arguments in the make statement below.
“About the Motherboard and Daughtercard EEPROM on USRP Devices (5th
August 2020)”
The aim is to be able to manipulate some GPIO bits in the block work
function and to align events using the 1PPS input.
Regards,
David GD4FMB
Ok, so presumably you're using Gnu Radio, since you're talking about
"block work functions".
So this issue straddles the two universes--UHD/USRP and Gnu Radio.
I'd encourage you to use the UHD test tools to confirm sanity of your
setup and then move on to a stupid-simple flow-graph with standard
blocks. Once THAT works, then one can think about grabbing the usrp
source/sink "object" and being able to use it in your own
processing "block". There used to be a way to do this even within
GRC but I fear that it was a custom block (perhaps from the old
gr-balint set of blocks) that would allow you to grab an object
handle and pass it as a variable into your own functions.
It's something I've wanted to do myself from time to time. Of course
if you're coding in "naked" GR, without using GRC, it's easy.
But GRC uses a "data flow" model, and is less "procedural", so it
gives an added layer of abstraction that makes it difficult to do
what you want to do. The gr-uhd module provides GPIO functions:
https://www.gnuradio.org/doc/doxygen-v3.7.9.1/classgr_1_1uhd_1_1usrp__block.html#ab09502e1c8c43a546616b9a998f137f1
But they aren't exposed in any meaningful way into GRC that I know of.
I'll note that in GR3.9, there is support for something called "code
snippets" which would let you "dip down into the lower layers" without
having to post-facto edit generated Python code.
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
