Library cannot support more than one sensor

[rah2501]

I'm using the SparkFun VR IMU BNO08X Arduino Library which imports this sh2 library. Unfortunately, the API in the BNO08x library cannot support more than one sensor as it uses global variables for sensor-specific data. I've been updating the library to enable its use with more than one sensor.

Unfortunately, I've come across a similar issue with your sh2 library. The BNO08x library calls sh2_service() which uses another global variable named _sh2 for sensor-specific state.

[rah2501]

Can I ask if there is a specific reason you used a global variable to store sensor state? Are you open to changing the API so that the library can be used with more than one sensor?

[rah2501]

I've opened #10 as an example of how the API might be changed to support more than one sensor. What are your thoughts?

[rah2501]

Hello? @kay-ceva ?

[WolfgangWindholtz]

@rah2501 Have you figured this issue this issue out. We are trying figure out the same issue for a project.

[rah2501]

@rah2501 Have you figured this issue this issue out.

No. I don't want to waste time making changes to the library that might not be accepted by upstream. I'm still waiting on the maintainers (Ceva) to respond. It looks like they might not be interested in collaborative development.

@dwheeler-ceva ?

[iLoveAndyBaker]

If the upstream people are not going to make the changes, through no bad faith on their part of course, then why doesn't the community do it instead? It seems just as likely that the upstream folks won't make ANY new changes anyway.

[rah2501]

why doesn't the community do it instead?

Because the community doesn't have write privileges to the repository.

[iLoveAndyBaker]

Rather I should say, leave the upstream version well enough alone, and pack a "fixed" version in the Sparkfun library or whoever happens to be using it

[dwheeler-ceva]

The code in this repo was originally intended as an example implementation, not necessarily as a ready-to-use driver. We chose to support just one device because it was the simplest, most universal case. (For similar reasons, there's no OS integration here.)

I guess what I need to say here is you should consider forking this repo and working together to implement the changes you need.