Multiple AD9361 Devices Cause Multiple Connections Error
(plain text this time)
Brian,
The general model of sub-devices for things like SPI and I2c and
potentially other hardware pins that are somehow shared between multiple
devices, is that there must be a platform-specific sub-device worker
created for the platform since the exact collection of devices sharing
the SPI or I2C is indeed very platform specific.
This subdevice worker should generally live in the ""devices"
subdirectory of the hdl/platform/<platform>, making it clear that it is
specific to that platform.
An example of this is the subdevice worker for the fmcomms2/3 card.
That card has an i2c bus that is used for two different devices on that
card: ad7291 and stm_mc24c02.
projects/assets/hdl/cards/fmcomms_2_3_i2c.hdl
Another example is the the i2c subdevice for the Epic Matchstiq_z1
radio. That radio has an i2c bus for si5338, tmp100, pca9534, pca9535,
avr microcontroller.
projects/assets/hdl/platforms/matchstiq_z1/devices/matchstiq_z1_i2c.hdl
So you would not use the ad9361_spi since that is specialized for a
non-shared SPI.
If your two SPIs are dealing with separate sets of devices, then you
could have two SPI subdevices. But you could also create a single
subdevice that controlled both SPI buses.
The ad9361_spi - could have been named:
ad9361_spi_when_spi_is_dedicated_to_a_single_9361
When a device worker is supporting a device with a SPI or I2C control
interface, that (portable) device worker uses the "rawprop" interface to
delegate SPI/I2C accesses to a platform-specific subdevice.
I wish we had lots of better diagrams to show the various cases.
Jim
On 1/20/20 9:52 AM, Brian Padalino wrote:
Hey James,
On Sun, Jan 19, 2020 at 5:56 PM James Kulp <jek@parera.com
mailto:jek@parera.com> wrote:
Brian/Davis,
I am assuming that both ad9361s share the same SPI bus?
Actually, in my application, I have two separate SPI buses. But,
those SPI buses have more than just the AD9361 hanging off of them, so
I will somehow have to share the clock, and data lines while having a
different chip select for a different device. Do you have any
suggestions on supporting that?
Thanks,
Brian
On Fri, Jan 17, 2020 at 4:58 PM Davis Hoover dhoover@geontech.com wrote:
Some debugging help: I often use make -n in these scenarios, which will
print to the screen the ocpigen commands being run - except in this case
where -n doesn't work, so I mod'd ocpigen to print out its arguments - then
stepped through the ocpigen command with gdb. The ocpigen command can also
be called w/ OCPI_LOG_LEVEL set to 8 or 10, which gives useful logging
info.
There are lots of ordinals being handled here, in part to facilitate the
multi device<->subdevice worker scenario. One problem I have identified is
an incorrect ordinal inspection - I think this is the fix:
diff --git a/tools/ocpigen/src/hdl-config.cxx
b/tools/ocpigen/src/hdl-config.cxx
index bc0cfa5..d3412ff 100644
--- a/tools/ocpigen/src/hdl-config.cxx
+++ b/tools/ocpigen/src/hdl-config.cxx
@@ -327,7 +327,8 @@ emitSubdeviceConnections(std::string &assy,
DevInstances *baseInstances) {
// If there are no mapping entries, then we use the implicit
ordinal of the
// supports element among supports elements for that device type
if (s.m_supportsMap.empty()) {
-
if (si->m_ordinal != d.m_ordinal)
-
//if (si->m_ordinal != d.m_ordinal) -
if (s.m_ordinal != d.m_ordinal) continue; } else { auto it =
This suspected fix causes other problems that I'm still looking into.
Just curious if you've been able to look into the other issues mentioned
here from this fix?
Thanks,
Brian
Brian, I am actively working on this when I find the time. The
hdl-config.cxx fix gets past the code generation step, but there are HDL
build errors I'm still investigating.
---------- Forwarded message ---------
From: Brian Padalino bpadalino@gmail.com
Date: Thu, Jan 23, 2020 at 11:22 AM
Subject: Re: [Discuss OpenCPI] Fwd: Fwd: Fwd: Multiple AD9361 Devices Cause
Multiple Connections Error
To: Davis Hoover dhoover@geontech.com
Cc: discuss@lists.opencpi.org
On Fri, Jan 17, 2020 at 4:58 PM Davis Hoover dhoover@geontech.com wrote:
Some debugging help: I often use make -n in these scenarios, which will
print to the screen the ocpigen commands being run - except in this case
where -n doesn't work, so I mod'd ocpigen to print out its arguments - then
stepped through the ocpigen command with gdb. The ocpigen command can also
be called w/ OCPI_LOG_LEVEL set to 8 or 10, which gives useful logging
info.
There are lots of ordinals being handled here, in part to facilitate the
multi device<->subdevice worker scenario. One problem I have identified is
an incorrect ordinal inspection - I think this is the fix:
diff --git a/tools/ocpigen/src/hdl-config.cxx
b/tools/ocpigen/src/hdl-config.cxx
index bc0cfa5..d3412ff 100644
--- a/tools/ocpigen/src/hdl-config.cxx
+++ b/tools/ocpigen/src/hdl-config.cxx
@@ -327,7 +327,8 @@ emitSubdeviceConnections(std::string &assy,
DevInstances *baseInstances) {
// If there are no mapping entries, then we use the implicit
ordinal of the
// supports element among supports elements for that device type
if (s.m_supportsMap.empty()) {
-
if (si->m_ordinal != d.m_ordinal)
-
//if (si->m_ordinal != d.m_ordinal) -
if (s.m_ordinal != d.m_ordinal) continue; } else { auto it =
This suspected fix causes other problems that I'm still looking into.
Just curious if you've been able to look into the other issues mentioned
here from this fix?
Thanks,
Brian
On Thu, Jan 23, 2020 at 11:43 AM Davis Hoover dhoover@geontech.com wrote:
Brian, I am actively working on this when I find the time. The
hdl-config.cxx fix gets past the code generation step, but there are HDL
build errors I'm still investigating.
Just wondering if you've been able to work on this a bit more, or have a
better understanding you could share for what causes the issue?
Thanks,
Brian
The build errors I experienced were in the platform config build. I
did make progress to the point where I confirmed that those errors
should not affect your scenario. Have you tried building using the
hdl-config.cxx hack to see how far a build gets?
---------- Forwarded message ---------
From: Brian Padalino bpadalino@gmail.com
Date: Tue, Feb 11, 2020 at 12:19 PM
Subject: Re: [Discuss OpenCPI] Fwd: Fwd: Fwd: Fwd: Multiple AD9361
Devices Cause Multiple Connections Error
To: Davis Hoover dhoover@geontech.com
Cc: discuss@lists.opencpi.org
On Thu, Jan 23, 2020 at 11:43 AM Davis Hoover dhoover@geontech.com wrote:
Brian, I am actively working on this when I find the time. The
hdl-config.cxx fix gets past the code generation step, but there are HDL
build errors I'm still investigating.
Just wondering if you've been able to work on this a bit more, or have
a better understanding you could share for what causes the issue?
Thanks,
Brian
On Tue, Feb 18, 2020 at 10:29 AM Davis Hoover dhoover@geontech.com wrote:
The build errors I experienced were in the platform config build. I
did make progress to the point where I confirmed that those errors
should not affect your scenario. Have you tried building using the
hdl-config.cxx hack to see how far a build gets?
I haven't since you said there was something else you were investigating.
I'll try the hack and see how far I get and report back.
Thanks,
Brian
On Tue, Feb 18, 2020 at 11:16 AM Brian Padalino bpadalino@gmail.com wrote:
On Tue, Feb 18, 2020 at 10:29 AM Davis Hoover dhoover@geontech.com
wrote:
The build errors I experienced were in the platform config build. I
did make progress to the point where I confirmed that those errors
should not affect your scenario. Have you tried building using the
hdl-config.cxx hack to see how far a build gets?
I haven't since you said there was something else you were investigating.
I'll try the hack and see how far I get and report back.
I can confirm that the hack does seem to allow me to build my other
configurations without issue.
I can now instantiate both my AD9361 devices and see them.
Thanks!
Brian
Glad you got the config build working. Let us know if you have any
bitstream build issues.
Please keep in mind this fix is intended as a temporary "hack". We will
continue to investigate proper resolution of the issue, likely via new XML
attributes for providing device/subdevice connection disambiguation, and
let you know of any further updates.
---------- Forwarded message ---------
From: Brian Padalino bpadalino@gmail.com
Date: Tue, Feb 18, 2020 at 7:35 PM
Subject: Re: [Discuss OpenCPI] Fwd: Fwd: Fwd: Fwd: Multiple AD9361 Devices
Cause Multiple Connections Error
To: Davis Hoover dhoover@geontech.com
Cc: discuss@lists.opencpi.org
On Tue, Feb 18, 2020 at 11:16 AM Brian Padalino bpadalino@gmail.com wrote:
On Tue, Feb 18, 2020 at 10:29 AM Davis Hoover dhoover@geontech.com
wrote:
The build errors I experienced were in the platform config build. I
did make progress to the point where I confirmed that those errors
should not affect your scenario. Have you tried building using the
hdl-config.cxx hack to see how far a build gets?
I haven't since you said there was something else you were investigating.
I'll try the hack and see how far I get and report back.
I can confirm that the hack does seem to allow me to build my other
configurations without issue.
I can now instantiate both my AD9361 devices and see them.
Thanks!
Brian
On Wed, Feb 19, 2020 at 11:33 AM Davis Hoover dhoover@geontech.com wrote:
Glad you got the config build working. Let us know if you have any
bitstream build issues.
Please keep in mind this fix is intended as a temporary "hack". We will
continue to investigate proper resolution of the issue, likely via new XML
attributes for providing device/subdevice connection disambiguation, and
let you know of any further updates.
Roger that. I will keep it as a set of my patches to apply to v1.5.1.
Again, thanks for the quick diagnosis and help.
Brian
Wondering is this should be fixed for the v1.7.0 release.
If not, is there an issue I can track?
Thanks,
Brian
On Wed, Feb 19, 2020 at 12:45 PM Brian Padalino bpadalino@gmail.com wrote:
On Wed, Feb 19, 2020 at 11:33 AM Davis Hoover dhoover@geontech.com
wrote:
Glad you got the config build working. Let us know if you have any
bitstream build issues.
Please keep in mind this fix is intended as a temporary "hack". We will
continue to investigate proper resolution of the issue, likely via new XML
attributes for providing device/subdevice connection disambiguation, and
let you know of any further updates.
Roger that. I will keep it as a set of my patches to apply to v1.5.1.
Again, thanks for the quick diagnosis and help.
Brian