missing gpioConfig.pullMode assignment for VINT pin? about ubxlib HOT 2 CLOSED

Hi. Yes that makes sense to me THX. By the way great library saves a lot of time.

from ubxlib.

Hi there, and thanks for spotting this. You're quite right that the value of driveMode ends up being different when the VInt GPIO pin is set, depending on whether there was a pinEnablePower pin defined; a somewhat dangerous optimised construction on my part. I think the flow goes like this:

• the initial default for pullMode at the start of the function is U_PORT_GPIO_PULL_MODE_NONE,
• if there's a pinPwrOn it becomes U_PORT_GPIO_PULL_MODE_PULL_UP,
• if there's a pinEnablePower it becomes U_PORT_GPIO_PULL_MODE_NONE,
• for the final case, if there's a pinVint, it's not touched, so it will be whatever it was due to the presence of pinPwrOn or pinEnablePower.

Now we only have a single board on our test system with a pinEnablePower, so the vast majority of cases we test will have pinVInt set to U_PORT_GPIO_PULL_MODE_PULL_UP.

[caveat: I'm not a HW engineer!]

And that seems wrong to me. VInt is simply being monitored, it should not be pulled anywhere. Not that it seems to make a difference in our cases but it might in other HW setups.

To cut this rambling story short: I will test a change which explicitly sets all the goldarned IO config lines before each call to uPortGpioConfig(); certainty much better than optimisation in this case. And for the pinVint case the pull mode will be U_PORT_GPIO_PULL_MODE_NONE. Does that make sense to you?

from ubxlib.