Hi Janos,
I assume that by 'device tree' you mean the property tree, and not the
actual device tree (e.g., on embedded N310).
1. You're correct that there's no functions in the C API to query the
property tree. That said, the vast majority of properties are queried by
via API calls that do nothing but go into the property tree.
uhd_usrp_set_master_clock_rate() for example, will interact with the
/mboard/0/tick_rate property. A lot of the C API calls, especially on
the `uhd_usrp_*` namespace, do nothing but that. So, question is, which
properties are you trying to access? Because that leads us to...
2. Accessing the property tree is always annoying because you need to
know the type. At least in C++ we can use template magic to specify the
type, which makes it somewhat manageable, as you can always do
```cpp
auto prop_value = tree->access<TYPE>("/path/to/prop").get();
```
for any type/property. In C, we could add a function for every
conceivable type, one for write, and one for read (maybe one for
update()), but that's a bit cumbersome and I'd like to know what the
application is.
Note that you still need to know the type ahead of time, like you do in
C++. So wouldn't it be nice if you had some abstraction which knows
which types to use? And yes, that's what the multi_usrp class does in
C++, and the uhd_usrp_* functions do in C.
For some of the simple types, adding setters/getters for prop tree paths
would be a simple addition. My question is, does this add functionality
that is not already available through other means.
3. The prop tree is not serializable. Well, you could maybe come up with
a way to do a dump of the tree values at a given time, but the
serialization code would be not only non-trivial, it would re-encode the
types again, and would also have to encode a bunch of exceptions for
properties that should be excluded from the serialization process (there
are even properties that encode binary objects and in some rare cases
pointers). It's a good idea, though. I probably won't be able to forget
about this anymore...
You can both ask us to implement something, and also contribute! For the
latter, we'll need a CLA [0] from you. For the former, we'll balance
feature requests with other outstanding issues and ongoing development.
Something like this might not get a high priority, though.
-- M
[0] http://files.ettus.com/licenses/Ettus_CLA.pdf
On 03/21/2018 08:31 AM, Janos Buttgereit via USRP-users wrote:
> Hello everybody,
>
> here at FH Münster University of Applied Sciences we are successfully using
> the UHD C++ API for SDR projects that require high performance.
> Now I’m about to write our own SDR interface framework that allows us a more
> modular approach, e.g. an abstract SDR Interface class with a range of
> derived classes encapsulating different I/O interfaces such as USRPs but also
> file sources and sinks for easy simulation and verification and maybe also
> drivers for some future custom I/O Hardware. This should help us to close the
> gap between the prototype and the final application that might run on an
> embedded platform.
>
> For that reason it’s desirable to not strictly depend on the UHD library at
> link time but have the option to detect if UHD is present on a platform at
> runtime and then dynamically load the library through dlopen. Obviously this
> only works for the C-API. First tests of this approach were successful, we
> are now able to interact with our USRPs without having any dependency to the
> original UHD headers in our codebase as well as having no need to link to UHD
> at build time. Quite nice!
>
> The only thing that’s missing at the moment is the ability to access the
> device tree through the C API. As our framework should also contain some
> functionality to check the exact hardware configuration and abilities at
> runtime to design a (graphical) user interface thats robust against applying
> invalid settings, this feature is really important.
> Now my first question is: Did I overlook some capability of the C API to get
> a full report about the device tree?
> If not, my second question would be: Is it either possible to contribute to
> the UHD project to develop such a feature or is it possible to ask Ettus to
> implement this feature in some way?
>
> There are various options I could think of, ranging from building a real C
> API for the device tree over to some extern "C“ declared functions that give
> access to the C++ based device tree (that would require to implement the
> device tree class and dependency into our code base, which would be okay for
> me) or to just parse the complete tree into a json or xml string that could
> be accessed through a simple C function and then could be read and parsed
> into a custom structure at my side.
>
> Any thoughts on this are highly appreciated!
> Best,
> Janos Buttgereit
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
