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

Rise error when I2C is not prepared #9

Open
Benik3 opened this issue Mar 21, 2020 · 6 comments
Open

Rise error when I2C is not prepared #9

Benik3 opened this issue Mar 21, 2020 · 6 comments

Comments

@Benik3
Copy link

Benik3 commented Mar 21, 2020

Hello.

I spend a lot of time now finding why I don't get any data from my sensor (BMP180) and then I found that I forgot to call init function with I2c.begin(). :D
Anyway it took me so long because all write and read functions returned 0 like OK.
Wouldnt be better to make, that if I2C is not initialized, the functions will end automatically with error?

P.S. nice to see that this library is still maintained. It's in my opinion much better then Wire library for Atmega, where I had some weird lock-ups and also work with this is much easier and clear in the code.

@Benik3
Copy link
Author

Benik3 commented Mar 22, 2020

Hmm now I see that there is no room for new error :/
Any idea?

@rambo
Copy link
Owner

rambo commented Mar 23, 2020

"maintained" is a bit of a stretch... I haven't looked in to this in a loong while but will of course merge any sane looking requests when I get around to eyeballing them.

Anyway, it would require a breaking change to switch the return values to int16_t and use negative numbers for errors like this.

Backwards compatible option would be to find a value in the reserved range that is not actually used by any of the supported MCU:s and use that for this purpose.

edit: and with some ifdefs we can even work around the problem that in the future (or even now) there might come a MCU that uses said code (but probably not another).

@Benik3
Copy link
Author

Benik3 commented Mar 23, 2020

I also thought about switching error to int16, but it's not 100% ideal for backward compatibility.
Anyway when I look on error codes of TWS, I think that we can use safely code 0xFF.
The 5 bits of TWSR are similar to our first 7 codes so it's not possible to rise all these errors at once :)
Also the max error of TWS is 0xF8, not 0xFF (because first 3 bits are omitted).

@PhilHaw
Copy link

PhilHaw commented Jan 16, 2021

Is this library compatible with the ATmega2560 chip?

@rambo
Copy link
Owner

rambo commented Jan 17, 2021

Is this library compatible with the ATmega2560 chip?

off-topic for this issue, but maybe for the first TWI peripheral, the I2C::pullup method at least does not have a case for 2560. Just try it if it works it works, if not then you can add the support and make a PR, shouldn't be too hard.

@PhilHaw
Copy link

PhilHaw commented Jan 17, 2021

Sorry about the off-topic post. I'm a bit of a noob in GitHub!
I'm not using the pull-up feature as I have external pull-ups on the bus so probably this won't affect me.

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

3 participants