You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Because the class-level properties of AccelRange and GyroRange are defined when the ICM20948 and ICM20649 are inited, the values overwrite each other if you use both in the same code. The values differ between both models (eg: RANGE_4G is 0 on ICM20649 and 1 on the other), and which values are allowed varies too. One solution would be to have them defined globally with all the values and have each model have its own translation table of allowed values. That would still allow using AccelRange.RANGE_4G in user code.
While an edge case, it was reported on discord.
The text was updated successfully, but these errors were encountered:
I looked into this and attempted a few solutions but I didn't come up with a way to do it as described.
I think it's not entirely possible that AccelRange.RANGE_4G can continue to work in user code, at least in the case where the user is making use of both sensors. RANGE_4G has different values for the different sensors so if both are in use somehow the user code would need to specify which one they are attempting to access.
My instinct is to move the AccelRange values onto the subclasses instead of the super class so that they would need to be accessed with like self.AccelRange or similar internally or instance.AccelRange externally. But I'm not sure that is a fully satisfying solution either as constants aren't typically accessed from the instance like that.
I am moving on for now and wanted to get my thoughts down here, I may circle back to this after some more thought.
Because the class-level properties of
AccelRange
andGyroRange
are defined when the ICM20948 and ICM20649 are inited, the values overwrite each other if you use both in the same code. The values differ between both models (eg: RANGE_4G is 0 on ICM20649 and 1 on the other), and which values are allowed varies too. One solution would be to have them defined globally with all the values and have each model have its own translation table of allowed values. That would still allow usingAccelRange.RANGE_4G
in user code.While an edge case, it was reported on discord.
The text was updated successfully, but these errors were encountered: