Bit banging I2C

[abbrev]

Hi @threeme3, is there a reason that I2C is bit banged on pins that support hardware I2C? Specifically in class I2C:

https://github.com/threeme3/QCX-SSB/blob/57e438da4425f3d22deb9ba9b5e64167a20d67b2/QCX-SSB.ino#L768-L775

We can probably at least reduce the code size a little by using the hardware I2C (though it probably wouldn't reduce the CPU load since we'd still have to synchronously wait for each byte to transfer).

[threeme3]

Hi @abbrev,
Thanks for the suggestion on reducing the code size by using hardware I2C support.
Currently, the SSB TX implementation require a I2C bit-stream of about 750kbit/s, and a constant periodic point in time of submitting the new phase-frequency changes towards the si5351.
With hardware I2C support it is not easy to meet both criteria. This is unfortunate, because with hardware I2C support it would be possible to do some processing in the background while transporting I2C data, but on the other hand I2C hardware support would also generate +80k/s interrupts, which is also rather inefficient.

Thanks for raising this idea.
73, Guido

[howard0su]

I think it is not necessary to generate interrupts when using hardware I2C. We can still pull the reg which has the transfer finish flags. In such way, we don't save too much cpu time but rather reduce the size of the code only.

[threeme3]

Yes, this is a good idea, thanks Howard!
I have re-opened so we can think of a solution and test it out.

[howard0su]

let's assume I2C runs on 800kbps, and the most common usage is SendPLLBRegisterBulk which changes Si5351 clock. The function issues the commands which contains 7 bytes + start + stop = 60 bits. It takes about 60/800k = 0.075ms = 75us. On 16Mhz AVR, it can run 1200 instructions. maybe worth to look at if we can combine freq_calc_fast with SendPLLBRegisterBulk and interleave the code to save some CPU load.