A few things I noticed.

[Koepel]

Hi, I have not tested your SWire library yet, but I noticed a few things.

The Wire.available() should return the number of valid bytes in the rxBuffer.

Writing a 16-bit value is not according to the Arduino Wire library. Please don't add that. It is very confusing and might result into different functionality between the Arduino Wire library and your SWire library. I will guaranteed cause a lot of trouble.

You mix HIGH and LOW with 1 and 0. They are the same, but from a programmers viewpoint they are different things. Perhaps you can make it more obvious what is used in the code.

The buffer length is only 8 bytes ? The Arduino Wire library for AVR chips has 32 bytes.

Is it possible to do a Wire.beginTransmission() followed by a Wire.endTransmission() to test the ACK of a sensor ? That is used in i2c scanner sketches. I did not test it, and I can not tell from the source if that will work.

What about making it more compatible ? Perhaps a (dummy) setClock(), a peek(), a end() and a flush(), en perhaps some functions from the Stream class.

[RaemondBW]

Hi, I am surprised you found this so soon after publishing... :) The documentation and code cleanliness is definitely lacking. Also I am definitely open to Pull requests :)

Writing a 16-bit value is not according to the Arduino Wire library. Please don't add that. It is very confusing and might result into different functionality between the Arduino Wire library and your SWire library. I will guaranteed cause a lot of trouble.

noted. It was useful for my single usecase and can be updated to follow the Wire Interface more closely.

You mix HIGH and LOW with 1 and 0. They are the same, but from a programmers viewpoint they are different things. Perhaps you can make it more obvious what is used in the code.

Will fix.

The buffer length is only 8 bytes ? The Arduino Wire library for AVR chips has 32 bytes.

Will fix.

Is it possible to do a Wire.beginTransmission() followed by a Wire.endTransmission() to test the ACK of a sensor ? That is used in i2c scanner sketches. I did not test it, and I can not tell from the source if that will work.

I haven't tried this particular use case yet. I can investigate.

What about making it more compatible ? Perhaps a (dummy) setClock(), a peek(), a end() and a flush(), en perhaps some functions from the Stream class.

This is all definitely possible.

[Koepel]

I'm surprised as well, that I found your software I2C so soon.

I noticed one more thing:
Your .endTransmission() has already a 'stop' parameter, but the .requestFrom() should also get a 'stop' parameter. Is a repeated start implemented ? That's another thing to add.

Did you know that the SCL can be combined for multiple busses ? That means that a number of objects can be created and .begin(sda,scl) can be called a number of times with the same SCL pin. That reduces the number of used pins.

[RaemondBW]

I have made a couple of the changes and more are in a pr awaiting my time to verify on hardware.

on the mix of HIGH and LOW with 1 and 0. Do you have any suggestions? It is complicated because in some cases it doesn't make sense to use a 1 or 0. I could just make a secondary function, setOne or setZero that calls the High and Low functions.

[Koepel]

I was talking about digitalRead(). That function returns HIGH or LOW. Therefor readBit() and readAck() return HIGH or LOW.
In readByte(), the Arduino macro bitWrite() is used, assuming LOW is 0 and HIGH is 1.
In readNack() the readBit() is compared to 1, assuming HIGH is 1.
It is okay of course, but when looking at it, the HIGH and LOW suddenly change into 1 and 0.
I suggest to also add comment to readBit() that it returns 0 or 1. Then it is defined what it is.
If you are a purist, you could translate HIGH and LOW into 1 or 0 in readBit() and readAck().

[RaemondBW]

Just checked i2c scanning and confirmed it works.

Please try the library and let me know if it works for you. I believe I updated most of the existing API to much closer follow the Arduino library.

[Koepel]

Test with Arduino Uno and HMC5883L with level shifter.

• I can confirm as well that the i2c scanner works.
• There is no delay when the clock pulse is low between the last data bit and 9th clock pulse when writing data. For a slow Arduino Uno it is still 9.8 µs, but for a faster processor it might be too short. A i2cDelay() in .writeByte() just before the readAck() solves it.
• In my code I used the third parameter for .requestFrom(). Implementing the repeated start would be nice.
• The .write() does not return the number of bytes that are written. A simple return 1; would solve it.
• A .setClock() is useful. Can you think of a smart algorithm to calculate the delay ? I think you have to use a seperate calculation for __AVR__ and for other faster processors.
• The default pins for SDA and SCL (when not set) are 7 and 6. In the Arduino environment, the 'SDA' and 'SCL' are defined and you could perhaps use those as a default: uint8_t data_pin = SDA;
• Are you sure that you want the non-standard .readByte() and .writeByte() as public functions ?