[UK OFFICIAL] RE: Set Platform Properties from Application
Classification: UK OFFICIAL
Hi Brian,
The ACI can't be used on platform or device worker properties, either to set or get them.
I raised this on the email list in December 2019: http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/2019-December/000300.html.
There is an issue for this: https://gitlab.com/opencpi/opencpi/-/issues/485.
-----Original Message-----
From: discuss discuss-bounces@lists.opencpi.org On Behalf Of Brian Padalino
Sent: 16 January 2021 21:18
To: discuss@lists.opencpi.org
Subject: [Discuss OpenCPI] Set Platform Properties from Application
The FSK application I am running has to set some platform properties to work correctly. These properties, essentially, are hooked up to different RF switches in the FPGA logic. It was easy to expose them as properties.
With OpenCPI v2.0.1, I am getting an exception stating that there is an unknown application property. Note that these are platform properties, so maybe I am doing something wrong. In my application, I have:
OA::Application app(xml_name.c_str(), NULL) ;
app.initialize() ;
app.setProperty( "platform_name", "platform_property", "value" ) ;
I am able to use ocpihdl to query the platform property as expected:
ocpihdl get platform_name platform_property
28 platform_property: 0
I can set and get it as well, and it works just fine. Did the syntax change? Do I need to change how I call this?
Thanks,
Brian
On Sun, Jan 17, 2021 at 6:16 PM Walters Dominic A <
dawalters@mail.dstl.gov.uk> wrote:
Classification: UK OFFICIAL
Hi Brian,
The ACI can't be used on platform or device worker properties, either to
set or get them.
I raised this on the email list in December 2019:
http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/2019-December/000300.html
.
There is an issue for this:
https://gitlab.com/opencpi/opencpi/-/issues/485.
I see, so it's been an issue for some time. It used to work for me,
though. Thinking about it now, it seems like maybe I was able to do it
using a platform configuration and not an HdlContainer. Since I had to
switch to an HdlContainer due to the platform configuration bug, this makes
sense.
Thanks for submitting the issue when you did. Bummer it hasn't been
resolved yet.
Thanks for the insight!
Brian
Have you tried to add those workers into the application?
I'll try a quick test tomorrow (which is a US holiday).
On 1/17/21 6:16 PM, Walters Dominic A via discuss wrote:
Classification: UK OFFICIAL
Hi Brian,
The ACI can't be used on platform or device worker properties, either to set or get them.
I raised this on the email list in December 2019: http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/2019-December/000300.html.
There is an issue for this: https://gitlab.com/opencpi/opencpi/-/issues/485.
-----Original Message-----
From: discuss discuss-bounces@lists.opencpi.org On Behalf Of Brian Padalino
Sent: 16 January 2021 21:18
To: discuss@lists.opencpi.org
Subject: [Discuss OpenCPI] Set Platform Properties from Application
The FSK application I am running has to set some platform properties to work correctly. These properties, essentially, are hooked up to different RF switches in the FPGA logic. It was easy to expose them as properties.
With OpenCPI v2.0.1, I am getting an exception stating that there is an unknown application property. Note that these are platform properties, so maybe I am doing something wrong. In my application, I have:
OA::Application app(xml_name.c_str(), NULL) ;
app.initialize() ;
app.setProperty( "platform_name", "platform_property", "value" ) ;
I am able to use ocpihdl to query the platform property as expected:
# ocpihdl get platform_name platform_property
28 platform_property: 0
I can set and get it as well, and it works just fine. Did the syntax change? Do I need to change how I call this?
Thanks,
Brian
On Sun, Jan 17, 2021 at 10:07 PM James Kulp jek@parera.com wrote:
Have you tried to add those workers into the application?
I'm not sure what you mean by this. There's a property associated with the
platform that I want to set. I can set it from ocpihdl but I can't seem to
do it in my application the way I was able to do it before.
What do you recommend I need to change at the application level to get
access to setting those properties?
Brian
An HTML attachment was scrubbed...
URL: http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/attachments/20210117/7b786b1f/attachment.html
An HTML attachment was scrubbed...
URL: http://lists.opencpi.org/pipermail/discuss_lists.opencpi.org/attachments/20210118/da01e8ae/attachment.html
On 1/17/21 10:14 PM, Brian Padalino wrote:
On Sun, Jan 17, 2021 at 10:07 PM James Kulp <jek@parera.com
mailto:jek@parera.com> wrote:
Have you tried to add those workers into the application?
I'm not sure what you mean by this. There's a property associated
with the platform that I want to set. I can set it from ocpihdl but I
can't seem to do it in my application the way I was able to do it before.
What do you recommend I need to change at the application level to get
access to setting those properties?
Brian
I did some more poking around. It almost works in that any worker in
the bitstream with a control interface can be included in the
application, and it becomes available to the application for the
property API.
I.e. I added:
<instance component='ocpi.core.platform'/>To the application, and made sure that component was mapped to the
platform I cared about (-Pplatform=plutosdr). THe initial property
values were dumped as normal.
The problem seems to be that many such "infrastructure" workers get
inadvertently reinitialized by the application, which conflicts with
their behind-the scenes automatic initialization done by the OpenCPI
runtime.
So we're close.
Its possible that unconnected workers that are devices, but do not have
any other infrastructure role, would work ok.
Jim