Attiny85 i2c slave talking to Raspberry Pi

[prandeamus]

Hey, I wonder if anyone can give advice on the following i2c setup which I can "almost" get to work but not reliably.

Tiny85, breadboad, 100nF decoupling, Reset button 10K pullup, I2C 10K Pullup
Connected Raspberry Pi (v1, old!) using the Pi's i2c bus 1
Everything powered at 3.3v for safety

I've created a fairly dumb i2c client, which is intended to flash LED in a loop to say "I'm alive" while being an i2c device # 0x42. the receive event should just suck up the data from the master and do nothing, while the request event returns the same 5 byte packet.

#include <Wire.h>

#define LED 1

void requestEvent() {
  // Master reads from slave
  Wire.write("hElLo"); // 5 byte response
}

void receiveEvent(int howManyBytes) {
  // Master writes to slave. Just suck it up.
  while(howManyBytes) {
    while(!Wire.available())
      ;
    Wire.read();
    --howManyBytes;
  }
}

void setup() {
  // Join i2c bus on port 42, and wait
  Wire.begin(0x42);
  Wire.onRequest(requestEvent);
  Wire.onReceive(receiveEvent);
  pinMode(LED, OUTPUT);
}

void loop() {
  digitalWrite(LED, HIGH);
  delay(500);
  digitalWrite(LED, LOW);
  delay(500);
}

Pi can detect the tiny: i2cdetect -y 1 shows device 0x42

I have a python script using the smbus library to a simple stress test. It sits in a loop writing a bit of data and looking at the response, then a short wait.

#!/usr/bin/env python3

import smbus2
import time

addr = 0x42

while True:
        w = smbus2.i2c_msg.write(addr, [99])
        r = smbus2.i2c_msg.read(addr, 5)
        with smbus2.SMBus(1) as bus:
                bus.i2c_rdwr(w, r)
        print(r)
        time.sleep(0.2)

This is SO close to working but sometimes the returned data shows as hElLo (correct) then hElo (drops a byte) and eventually the PI craps out with an error and the python script ends. All the while the led flashes calmly.

I know the PI had some problems with clock stretch logic and this is quite an old board; but the OS and firmware is up to date. It seems to be slightly more reliable when the 85 is running on the 16MHz PLL clock compared to 1MHz or 8 MHz internal, but the problem is essentially the same, and the payload really isn't big.

I'm kinda stuck because I have no insight as to the fault location. There's a hundred and one tutorials showing elementary byte transfer between regular Arduinos and Nanos, but little that I can find of use on the Raspberry Pi Master / Tiny Slave kind of configurations.

With the clear understanding that I'm not blaming the tiny core, can anyone point me in direction of good examples? Or can someone tell me I'm coding the 85 incorrectly?

[prandeamus]

Near instant comment to my own question. I used a different master, same code at each end, but this time using a PC as I2C master. There's a neat project over at https://github.com/harbaum/I2C-Tiny-USB which allows you to use a Digispark unit as an I2C interface.

The simple stress test seems to work without dropping data or crapping out, so I'll hazard a guess that either the PC is a better I2C master OR the change in power supply (now running at 5V not 3.3V) makes a difference. I would still value any insights, and especially if there is anything I can do to mitigate potential timing problems using the PI.

[prandeamus]

Me again, helping myself, it seems :) Too late for me to fix this today, or even investigate but the suggestions for RPI are "yeah hardware clock stretching is trashed"

https://www.advamation.com/knowhow/raspberrypi/rpi-i2c-bug.html
https://www.recantha.co.uk/blog/?p=19880

The canonical solutions are to either limit the hardware i2c clock rate to something lower e.g 10KHz and hope, or there is an alternative big-bang driver on the RPi. Still not sure if that's the primary problem but clearly these are things I can try.

[SpenceKonde]

You will likely dismiss both of these out of hand.... but why 85? Why not snag something with a hardware serial port (841 in classic AVR-land, 412 for 8-pin modern or 1614 for 14-pin modern with massive feature set? Something along those lines? raspi's I2C implementation known to be hosed, and you're currently hoping to use that anyway in order to communicate with the legacy part you;ve chosen, I would reevaluate your options for communications protocols, especially in light of the new tinyAVR 0/1/2-series parts, which have much snazzier peripherals by far.

[prandeamus]

I'd be silly to discuss your advice out of hand, of course. I'm sure that the new parts are good, on your recommendation. I'm learning on several fronts simultaneously (i2c, tiny chips, python), and was using the parts in front of me. I'm a hobbyist playing with the components in my garage(bought some years ago) to see what is possible. That's where I am today, but I fully take your point that I could be somewhere else.

Anyway, to the matter in hand, since the majority of the problem in front of me is in the i2c master, I'll have some fun tinkering/ and playing . And I'll do some research on your recommendations.

[deepcoder]

I am far from an expert. I found that the 2nd I2C slave library listed below was more robust for me. That said, both worked for me on a rpi v2b. I have not tried on a rpi v1b. I saw problems with the first library on a attiny85 digispark running against a seeedstudio odyssey intel master, just moving to the second library solved problems. I sense a timing problem in first library. Both the rpi and odyssey masters set a 400 kHz i2c bus speed. As I think you cited, I do remember some problems with early rpi's and i2c.

https://github.com/rambo/TinyWire

https://github.com/puuu/USIWire

If you want a sense of the swamp that is I2C and Linux, have a watch of this video by the I2C project lead. Eye opening and sad....
https://www.youtube.com/watch?v=E1ok8xxYdko