Can you bitbang I2C as a Slave Device?

Hi guys,

Working on a robot and I have an interesting conundrum. I have one central Mega talking to a few 5V Trinkets (boards that use AT328p). As far as I know these trinket boards are pretty much 100% compatible with the Arduino libraries. We need all 8 ADCs on the trinket boards, and also to talk to them via I2C. The problem is that the SCL and SDA pins on the trinket are shared with 2 analog pins.

No worries I think, I'll just bitbang the I2C. I know that's a thing I can do.

You probably see where this is going. These trinkets need to be slave devices, and after some googling around I see that the typical software serial library is for Master devices only. I'm pretty familiar with i2c as a protocol but my head starts to pin when I pour through these libraries. I thought I'd come here and ask real quick.

  • Is there a i2c bitbang library where the device can be a slave device?
  • Why are these i2c bitbang libraries master-only? How difficult would it be to convert them to slave?

Try these:

Just the first results I found on Github :slight_smile:

I'm still weak in the ways of Git. Thanks! I'll dig into these and give them a try.

Why not throw those 'trinket' boards away and get some Arduino DUE boards ?
The DUE, is 3v3 and has two I2C ports as well as more analogue inputs at 12 bit resolution, which you might find worthwhile instead of 10 bit resolution on the AVR boards.

Like the SoftwareSerial library, I would avoid any form of bit banging a serial data stream, unless you know very well what is going on and fully understand the limitations and things to watch.

The reason for master mode only may be down to the fact that while not transmitting, the processor in master mode can carry on doing what ever it wants. But in slave mode, the poor thing is constantly polling for start of data and when data does start, the processor is fully tied up sampling the digital inputs trying to work out the clock signal and data signal. This has significant implications on what the processor can do while that is happening, which in the case of these small micro-controllers, may not be a great deal if anything at all. So you need to design you whole application around this rather than having it as a service that is buffered by hardware, as is usually the case with serial communications, such as async, SPI or I2C.


Paul - VK7KPA

The problem with the DUE:
It is expensive
It is 3.3V only
It doesn't work with some libraries because of the architecture
It is bigger

Just use a Teensy LC.

This is great advice. A couple days after we sent our board out I remembered the Teensy and casually looked it up, then couldn't stop cursing. 12 ADC? I2C/SPI/UART? We wouldn't be dealing with any of this nonsense if I'd remembered that bloody board just a few days earlier.

Everyones' concerns about bitbanging i2c Slave are well founded. I was concerned that constant polling wouldn't leave room for much else and it seems my fears are legitimate. We will probably get by with a UART daisy chain for now, then switch to a nice I2C bus using Teensy for our next iteration.

The Teensy has 12 ADC? Wow, I only looked at the Teensy LC.