SoftI2CMaster implementation

[mcaralp]

This adds compatibility with SoftI2CMaster (https://github.com/felias-fogg/SoftI2CMaster) library.
It is a software implementation of I2C and allows to use other pins than 0 and 2.

[datacute]

Thanks. I had been renaming the i2c implementation functions so I could re-use the technique (in a library to read the Wii Nunchuk) without duplicating code. I've pushed those renames.
I see the SoftI2CMaster supports two interfaces, and it's Wire like interface isn't as efficient. Are their reasons why the i2c_init, i2c_start etc can't be used instead? I'll take a look if you haven't already investigated.

[mcaralp]

I mostly used the Wire like interface for the sake of simplicity. The way that SoftI2CMaster returns errors is a bit different than the Wire library (i2c_start returns a boolean and i2c_stop returns nothing), and I was not sure that it would work the same. But since TinyI2C seems to use the same error handling as SoftI2CMaster, it is probably not a problem.

There is still a benefit to use the Wire like interface: the Wire.beginTransmission function can be called multiple times before calling Wire.endTransmission, as it uses i2c_start and i2c_rep_start functions to send several packets in a row. If you don't need this feature I can switch to the original set of functions. I will also rename the functions to use your new nomenclature.

[datacute]

I experimented a while ago with this idea, and discovered that Spence Konde's ATTinyCore uses a version of SoftI2CMaster as its implementation of the Wire library. As I use this core, I found it hard to identify when the user selected implementation was chosen rather than the one supplied by the core.
Which board manager core implementation are you using?

[WanderLG]

Good Morning.
Is it possible to use Tinyoled4K without the need for a wire library?

I tried to edit the TinyOled4K.cpp file
including direct command functions according to this simple library.
https://github.com/evilnick/evilOLED/blob/master/evilOLED.cpp

But everything I try to do, I only get scrambled images on the display.

Can anyone help?

[datacute]

@WanderLG yes, the library already supports three i2c implementations. Internally, the library receives pointers to functions to implement the various parts.

Does that evilOLED library work on its own? It is interesting in that it doesn't make any attempt to respect i2c timing, or wait for acknowledgements.

I've seen that the SSD1306 appears quite accepting of misuse of the i2c best practices, for example I've run some tests with over half a dozen different sized screens wired together and all on the same address, and they all receive the commands and show the same images.

[datacute]

@WanderLG I've just committed an implementation based on evilOLED's, along with a speed test example program.
I haven't yet released a new version, so you will need the code from github if you want to try it out.

[WanderLG]

@WanderLG Acabei de enviar uma implementação baseada no evilOLED's, junto com um programa de exemplo de teste de velocidade.
Ainda não lancei uma nova versão, então você precisará do código do github se quiser testá-lo.

Glad you removed the wire library.
Thank you so much for this.
however, I couldn't make it work here. I tried using just the: #include <Tiny4kOLED_bitbang.h>
Compiles normal, but has no traffic on pins A4 and A5.
Am I doing something wrong?

[WanderLG]

Sorted out. You were directing to the address of another pin. I edited your Tiny4kOLED_bitbang.h and put the address of pins A4 and A5

PORTC = PORTC |(1<<PC5); // HIGH PINO A5
PORTC = PORTC |(1<<PC4); // HIGH PINO A4
PORTC = PORTC &(1<<PC4); // LOW PINO A4
PORTC = PORTC &(1<<PC5); // LOW PINO A5

I'm going to test it, but it looks like it's much faster than using wire, and now it doesn't crash. that's what's most important. I loved it. Thank you so much for this.