Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SMBus fails in a loop for the first couple reads #36

Open
wildbiotiger opened this issue Apr 30, 2019 · 3 comments
Open

SMBus fails in a loop for the first couple reads #36

wildbiotiger opened this issue Apr 30, 2019 · 3 comments

Comments

@wildbiotiger
Copy link

Working on an Ubuntu system using the following

  • Ubuntu 16.04
  • Python 3.5.2
  • I2C bus 8 w/ a smart battery at address 0xb

and encountered a weird error. When using SMBus or SMBusWrapper, for the first couple of reads, I get the following OSError exception:
[Errno 6] No such device or address
But after a half second or so, the reads begin to succeed. I've used the command-line python to try and reproduce but I am getting mixed results: some success, some failures.

Example code below (should reproduce it):

def main():
 nowork = True
    bust = smbus2.SMBus(8)
    while(nowork):
        try:
            temperature = bust.read_word_data(0xb, 0x8)
            nowork = False
        except OSError as ex:
            print("fail %s" % str(ex))
        except:
            print("fails")

if __name__ == "__main__":
    main()

By sticking it in a retry loop until successful, I'm able to bypass it, but it doesn't feel like a clean solution to me. Any suggestions?

@kplindegaard
Copy link
Owner

kplindegaard commented May 11, 2019

@wildbiotiger, I've no idea.

But I have come across devices that require a little time to process the last operation you send. For example, if you write/call something that does return a result successfully, the device isn't really ready for the next command right away. Some need time to do a little processing before they can accept a new one. Could that be part of the explanation here, you think? Or that the device need time to power up properly? Or there is some kind of other initialization that's not done right?

@wildbiotiger
Copy link
Author

It may be that the script is processing faster than the underlying buffer fills, but I am curious if the operations are somewhat non-blocking. Would make things a little more interesting.

@kplindegaard
Copy link
Owner

@wildbiotiger It would surprise me if that's the explanation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants