delayMicroseconds() is way off with attiny85 @8MHz

[haldark]

I am using a naked attiny85 on a breadboard and using an Uno as ISP. I had installed this core v1.5.2 today. Selected the following,

Board: "ATtiny25/45/85 (No Bootloader)"
Chip: "ATtiny85"
Clock Source (Only set on bootload): "8 MHz (internal)"
Timer 1 Clock: "CPU (CPU frequency)"
LTO (1.6.11+ only): "Enabled"
Save EEPROM (only set on bootload): "EEPROM retained"
B.O.D. Level (Only set on bootload): "B.O.D Disabled (saves power)"

The burned the bootloader. Readback the fuses and they are correct (E: FF, H: DF, L: E2].

I intend to implement a USI I2C master @100khz, that will master 2 slaves. In USI, the clock is generated by SW by writing to USICR register. The clock frequency achievable thus depends on resolution and accuracy of delay functions.

I did a simple test with register write to a output pin and capturing the pin using a logic analyzer. the sketch is,
`//ATTIny85 Pin Map
#define LED1_PIN 3 //PB2 (pin 2)
#define LED2_PIN 4 //PB4 (pin 3)

void setup()
{
pinMode(LED1_PIN, OUTPUT);
digitalWrite(LED1_PIN,LOW);
pinMode(LED2_PIN, OUTPUT);
digitalWrite(LED2_PIN,LOW);

delay(1000);
digitalWrite(LED1_PIN,HIGH);
delayMicroseconds(4);
digitalWrite(LED1_PIN,LOW);
delayMicroseconds(5);
digitalWrite(LED1_PIN,HIGH);
delayMicroseconds(4);
digitalWrite(LED1_PIN,LOW);
delayMicroseconds(5);
digitalWrite(LED1_PIN,HIGH);
delayMicroseconds(4);
digitalWrite(LED1_PIN,LOW);
delayMicroseconds(5);
digitalWrite(LED1_PIN,HIGH);
delayMicroseconds(4);
digitalWrite(LED1_PIN,LOW);
delayMicroseconds(5);

}

// Our main program loop.
void loop()
{
} `

I was expecting to see for pulses with 4us high period and 5us low period, with around 1us deviation (for execution cycles). But the logic analyzer trace shows that the periods are way off. T(High) is 9.33us and T(Low) is 10.5us (see attached screenshot)

When I use delayMicroseconds(1), the periods become worst. So, I can't even create a clock with period (High _ Low) 10us, which is required for 100KHz I2C. 400KHz is out of question. Max I seem to be able to reach is 50KHz.

Is it expected with Attiny @8MHz? I understand that 8MHz is 125ns cycle period. but 4us means 32 cycles. It should be easily achievable in a tight delay loop, isn't it? I believe some people reported to use Attiny85 to easily achieve 100KHz I2C. But I fail to see how?

Is it issue with this core? Some setting is messing with the delay loop implementation of delayMicroseconds?

Anybody faced this kind of issue? Appreciate if you can help me with your insight.. I really want to reach at least 100KHz I2C.

[hmeijdam]

Yes, I had the same issue when playing with IR transmitters for the first time. The "delayMicroseconds()" function and the "digitalWrite()" function take up quite some clock-cycles themselves to complete.

Discarding digitalWrite and using direct port manipulation may improve that a bit, but delayMicroseconds is not accurate enough on the T85 itself I observed.

I had to use the hardware timer (TCNT0 or TCNT1) to get a stable PWM

[fsievers]

Also note that the internal oscillator is only 10% accurate if not user calibrated as specified in the datasheet.

[SpenceKonde]

I was expecting to see for pulses with 4us high period and 5us low period,

Why would you expect something like that?
I would expect to see around 10 us high and 11us low, which is within measurement accuracy limits of what you observed.

digitalWrite() is slow as shit. It takes around 6us to execute (at 8 MHz)... . The Arduino API functions were written largely without consideration for efficiency and with an ATmega x8 running at a power-of-2 MHz clock as the target, and that happened to become a huge smash hit. Making no assumptions about the pin mapping or target processor, the conceptual basis of digitalWrite() is sound, and it's implementation follows from that that rather straightforward starting point.

000000dc <digitalWrite>:
digitalWrite():
C:\Users\Spence\Documents\Arduino\hardware\ATTinyCore\avr\cores\tiny/wiring_digital.c:138
}

void digitalWrite(uint8_t pin, uint8_t val) {
  if (pin > 127) {pin = analogInputToDigitalPin((pin & 127));}
  check_valid_digital_pin(pin);
  uint8_t timer = digitalPinToTimer(pin);
  dc:	90 e0       	ldi	r25, 0x00	; 0
  de:	fc 01       	movw	r30, r24
  e0:	e2 5e       	subi	r30, 0xE2	; 226
  e2:	ff 4f       	sbci	r31, 0xFF	; 255
  e4:	34 91       	lpm	r19, Z
C:\Users\Spence\Documents\Arduino\hardware\ATTinyCore\avr\cores\tiny/wiring_digital.c:139
  uint8_t mask = digitalPinToBitMask(pin);
  e6:	fc 01       	movw	r30, r24
  e8:	e0 5d       	subi	r30, 0xD0	; 208
  ea:	ff 4f       	sbci	r31, 0xFF	; 255
  ec:	24 91       	lpm	r18, Z
C:\Users\Spence\Documents\Arduino\hardware\ATTinyCore\avr\cores\tiny/wiring_digital.c:140
  uint8_t port = digitalPinToPort(pin);
  ee:	fc 01       	movw	r30, r24
  f0:	e6 5d       	subi	r30, 0xD6	; 214
  f2:	ff 4f       	sbci	r31, 0xFF	; 255
  f4:	e4 91       	lpm	r30, Z
C:\Users\Spence\Documents\Arduino\hardware\ATTinyCore\avr\cores\tiny/wiring_digital.c:143
  volatile uint8_t *out;

  if (port == NOT_A_PIN) return;
  f6:	ef 3f       	cpi	r30, 0xFF	; 255
  f8:	b1 f0       	breq	.+44     	; 0x126 <digitalWrite+0x4a>
C:\Users\Spence\Documents\Arduino\hardware\ATTinyCore\avr\cores\tiny/wiring_digital.c:147

  // If the pin that support PWM output, we need to turn it off
  // before doing a digital write.
  if (timer != NOT_ON_TIMER) turnOffPWM(timer);
  fa:	33 23       	and	r19, r19
  fc:	29 f0       	breq	.+10     	; 0x108 <digitalWrite+0x2c>
turnOffPWM():
C:\Users\Spence\Documents\Arduino\hardware\ATTinyCore\avr\cores\tiny/wiring_digital.c:70
      timer &= 0x07;
    }
  #else

    #if defined(TCCR0A) && defined(COM0A1)
      if( timer == TIMER0A) {
  fe:	31 30       	cpi	r19, 0x01	; 1
 100:	99 f4       	brne	.+38     	; 0x128 <digitalWrite+0x4c>
C:\Users\Spence\Documents\Arduino\hardware\ATTinyCore\avr\cores\tiny/wiring_digital.c:71
        TCCR0A &= ~(1 << COM0A1);
 102:	8a b5       	in	r24, 0x2a	; 42
 104:	8f 77       	andi	r24, 0x7F	; 127
C:\Users\Spence\Documents\Arduino\hardware\ATTinyCore\avr\cores\tiny/wiring_digital.c:77
        // TCCR0A &= ~(1 << COM0A0); /* no user cleanup */
      } else
    #endif
    #if defined(TCCR0A) && defined(COM0B1)
      if( timer == TIMER0B){
        TCCR0A &= ~(1 << COM0B1);
 106:	8a bd       	out	0x2a, r24	; 42
digitalWrite():
C:\Users\Spence\Documents\Arduino\hardware\ATTinyCore\avr\cores\tiny/wiring_digital.c:149

  // If the pin that support PWM output, we need to turn it off
  // before doing a digital write.
  if (timer != NOT_ON_TIMER) turnOffPWM(timer);

  out = portOutputRegister(port);
 108:	f0 e0       	ldi	r31, 0x00	; 0
 10a:	ec 5d       	subi	r30, 0xDC	; 220
 10c:	ff 4f       	sbci	r31, 0xFF	; 255
 10e:	a4 91       	lpm	r26, Z
 110:	b0 e0       	ldi	r27, 0x00	; 0
C:\Users\Spence\Documents\Arduino\hardware\ATTinyCore\avr\cores\tiny/wiring_digital.c:168
      *out |= mask;
      SREG = oldSREG;
    }
  #else
    if (val == LOW) {
      uint8_t oldSREG = SREG;
 112:	8f b7       	in	r24, 0x3f	; 63
C:\Users\Spence\Documents\Arduino\hardware\ATTinyCore\avr\cores\tiny/wiring_digital.c:167
      *pue |= mask;
      *out |= mask;
      SREG = oldSREG;
    }
  #else
    if (val == LOW) {
 114:	61 11       	cpse	r22, r1
 116:	19 c0       	rjmp	.+50     	; 0x14a <digitalWrite+0x6e>
C:\Users\Spence\Documents\Arduino\hardware\ATTinyCore\avr\cores\tiny/wiring_digital.c:169
      uint8_t oldSREG = SREG;
      cli();
 118:	f8 94       	cli
C:\Users\Spence\Documents\Arduino\hardware\ATTinyCore\avr\cores\tiny/wiring_digital.c:170
      *out &= ~mask;
 11a:	9c 91       	ld	r25, X
 11c:	e2 2f       	mov	r30, r18
 11e:	e0 95       	com	r30
 120:	e9 23       	and	r30, r25
C:\Users\Spence\Documents\Arduino\hardware\ATTinyCore\avr\cores\tiny/wiring_digital.c:175
      SREG = oldSREG;
    } else {
      uint8_t oldSREG = SREG;
      cli();
      *out |= mask;
 122:	ec 93       	st	X, r30
C:\Users\Spence\Documents\Arduino\hardware\ATTinyCore\avr\cores\tiny/wiring_digital.c:176
      SREG = oldSREG;
 124:	8f bf       	out	0x3f, r24	; 63
C:\Users\Spence\Documents\Arduino\hardware\ATTinyCore\avr\cores\tiny/wiring_digital.c:179
    }
  #endif
}
 126:	08 95       	ret
turnOffPWM():
C:\Users\Spence\Documents\Arduino\hardware\ATTinyCore\avr\cores\tiny/wiring_digital.c:76
        TCCR0A &= ~(1 << COM0A1);
        // TCCR0A &= ~(1 << COM0A0); /* no user cleanup */
      } else
    #endif
    #if defined(TCCR0A) && defined(COM0B1)
      if( timer == TIMER0B){
 128:	32 30       	cpi	r19, 0x02	; 2
 12a:	19 f4       	brne	.+6      	; 0x132 <digitalWrite+0x56>
C:\Users\Spence\Documents\Arduino\hardware\ATTinyCore\avr\cores\tiny/wiring_digital.c:77
        TCCR0A &= ~(1 << COM0B1);
 12c:	8a b5       	in	r24, 0x2a	; 42
 12e:	8f 7d       	andi	r24, 0xDF	; 223
 130:	ea cf       	rjmp	.-44     	; 0x106 <digitalWrite+0x2a>
C:\Users\Spence\Documents\Arduino\hardware\ATTinyCore\avr\cores\tiny/wiring_digital.c:108
        TCCR1C &= ~(1 << COM1D1);
      } else
    #else
      // Timer1 for non-x61/x7
      #if defined(TCCR1) && defined(COM1A1) // x5
        if(timer == TIMER1A) {
 132:	33 30       	cpi	r19, 0x03	; 3
 134:	21 f4       	brne	.+8      	; 0x13e <digitalWrite+0x62>
C:\Users\Spence\Documents\Arduino\hardware\ATTinyCore\avr\cores\tiny/wiring_digital.c:109
          TCCR1 &= ~(1 << COM1A1);
 136:	80 b7       	in	r24, 0x30	; 48
 138:	8f 7d       	andi	r24, 0xDF	; 223
 13a:	80 bf       	out	0x30, r24	; 48
 13c:	e5 cf       	rjmp	.-54     	; 0x108 <digitalWrite+0x2c>
C:\Users\Spence\Documents\Arduino\hardware\ATTinyCore\avr\cores\tiny/wiring_digital.c:113
        } else
      #endif
      #if defined(TCCR1) && defined(COM1B1) // x5
        if(timer == TIMER1B) {
 13e:	34 30       	cpi	r19, 0x04	; 4
 140:	19 f7       	brne	.-58     	; 0x108 <digitalWrite+0x2c>
C:\Users\Spence\Documents\Arduino\hardware\ATTinyCore\avr\cores\tiny/wiring_digital.c:114
          GTCCR &= ~(1 << COM1B1);
 142:	8c b5       	in	r24, 0x2c	; 44
 144:	8f 7d       	andi	r24, 0xDF	; 223
 146:	8c bd       	out	0x2c, r24	; 44
 148:	df cf       	rjmp	.-66     	; 0x108 <digitalWrite+0x2c>
digitalWrite():
C:\Users\Spence\Documents\Arduino\hardware\ATTinyCore\avr\cores\tiny/wiring_digital.c:174
      cli();
      *out &= ~mask;
      SREG = oldSREG;
    } else {
      uint8_t oldSREG = SREG;
      cli();
 14a:	f8 94       	cli
C:\Users\Spence\Documents\Arduino\hardware\ATTinyCore\avr\cores\tiny/wiring_digital.c:175
      *out |= mask;
 14c:	ec 91       	ld	r30, X
 14e:	e2 2b       	or	r30, r18
 150:	e8 cf       	rjmp	.-48     	; 0x122 <digitalWrite+0x46>

Of course, there are a lot of simplifying assumptions that can be made particuarly if you consider what parts are being used. (ex, on the 85, you know that any valid pin will be on PB and hence use PORTB/DDRB/PINB registers, that any pin number < 6 is valid and all others are not, and that it's bitmask is 1<<pin number).

In 2.0.0-dev (used for above as well), if you replace the calls to digitalWrite() with digitalWriteFast(), you get fully optimal code - each write to a constant numbered pin compiles to an SBI or CBI instruction. digitalWriteFast is not available in the released versions. Currently

I have considered making this happen for all calls to digitalWrite with constant pin numbers but decided against it because there is a large volume of code in the wild that makes implicit assumptions about the speed of digitalWrite (this is not theoretical; I've seen sketches and libraries that people were copying code from and posted about on the forums (for unrelated reasons) and noticed that the code would break badly if automatic optimization of digitalWrite() with constant pins was performed, which I'd been considering (until I saw that sketch, which finished off that idea.

But yeah, your problem is the fact that digitalWrite() is a lot slower than you were expecting.

Why do you feel a need to reinvent the wheel w/regards to USI-based I2C? The included Wire.h library will transparently choose the correct implementation of I2C (for example, using the USI on t85, and a fully software implementation for I2C master on the 841 and 828 because they have neither hardware I2C master nor a USI - the only hardware help they have is the TWI slave interface, which of course we use when the part is configured as slave).

[MikeDebonair]

• Does the ATtiny core do a "user calibration" of the RC oscillator of ATtiny85, in order to improve accuracy ?
• If no, will "TinyTuner" library help to improve accuracy ?

[SpenceKonde]

Not unless you are using code I have not written yet for 2.x,x which is not released - OR if you are using a Micronucleus board definitiion, most recently uploaded code via VUSB; In this case it will be either untuned (back to defaul) or left at the cal that gets the 16.5 MHz that VUSB needs to meet timing sonstraints with the bifurcated classic calibration registers.

There are likely hundreds of pieces of software called tiny tuner? Please be more specific, but I do not belive you have any hope until version 2.0.0 comes out which will support automatic loading of a tuned speed.

Users who require greater precision in their timing should not use the RC oscillator on a classic AVR (excepting the 828, 841, 828 and 1634 - those aren't simple, but at a given voltage, the frequency is very nearly fixed regardless of temperature (not the case with classics!)

[MikeDebonair]

Thank you, Mr. Spence Konde ( Dr. Azzy). I do look forward to your ATtiny core version 2.0.0.
I was referring to this TinyTuner :: https://forum.arduino.cc/t/poor-mans-tiny-tuner/8617

[haldark]

Thanks a lot for responding to this thread.

@hmeijdam, your response gave me confidence that I am not on wrong track.
@fsievers, I was aware of that, but even writing to registers USICR using bit blast with _delayus(4) resulted a I2C clock of around 50KHz. that's way beyond 10% margin.

@SpenceKonde , Thanks a lot for your detailed response.

I indeed tried Wire, Adafruit TinyWireM or directly USI_TWI_Master libraries. They don't use digitalWrite(). They use direct register and port manipulations. None of them are working with default T_LOW=4.7us and T_HIGH=4us to create a 100KHz clock. In fact, these libraries are not even creating a valid I2C pattern (screen shot attached).

This is my test code with Wire library.
`// Reference the I2C Library
#include <Wire.h>

// Setup routine, here we will configure the microcontroller and compass.
void setup()
{
Wire.begin(); // Start the I2C interface.
Wire.beginTransmission(0x0E); //slave address
Wire.write(0x01); //slave's register address
Wire.write(0x20); //data
Wire.endTransmission();
}

void loop()
{
}`

If I don't use external 4.7K pullups, logic analyzer captures flatlines on SCL/SDA. When I use 4.7K external pullups, only START condition is created (see attachment)...that's it.

using my homegrown code for USI I2C, I am able to create perfect I2C pattern and able to read a magnetometer over I2c. But I am using very slow clock now (50, 25), just to solidify my code.

Is there a way to make Wire library create a slower I2C clock? (just to see if is are not working because of clock speed, or some bug in the library)? Without it I am stuck with these libraries and need to reinvent my own USI I2C code.

Thanks a lot for your time.

[UPDATED]
It worked without external pullups. It was a very stupid mistake of mine that was causing the issue. I forgot to remove the SPI wires that was for programming ATTINY85 during testing. ABSOLUTELY HORRENDOUS IDIOTIC MISTAKE of mine.

I apologize for wasting your time.

Attached is the analyzer screen shot.

[haldark]

@SpenceKonde

The sceenshot I sent earlier (where 100kHz I2C is working), is when my sketch includes USI_TWI_Master.h and uses its functions directly.

But when I include <Wire.h>, and use Wire library member functions, the I2C clock becomes 36KHz.

I noticed that the USI_TWI_Master.h I am using and the one included in your ATTinyCore is slightly different.

I was using USI_TWI_Master.h that comes included with Adafruit TinyWireM library. This has the following and uses _delay_us function. It was giving me 100KHz SCL.

// For use with _delay_us() #define T2_TWI 5 //!< >4,7us #define T4_TWI 4 //!< >4,0us

Whereas, USI_TWI_Master.h that you are using in ATTinycore is little different. It uses the following definitions

#define CLKBASE ((F_CPU+999999)/1000000) #define T2_TWI (5*CLKBASE) //5us #define T4_TWI (4*CLKBASE) //4us
And uses the following delay loop

#define DELAY_T2TWI (_delay_loop_1(T2_TWI / 3)) #define DELAY_T4TWI (_delay_loop_1(T4_TWI / 3))
This is giving me 36KHz SCL.

I am suspecting the _delay_loop_1 function inside delay_basic.h is causing it.

I have already proved my project in Nano using Wire library. I am just porting it to AtTiny85 and I would love to stick with Wire library, instead of using USI_TWI_Master library natively.

Is there any way (without modifying the lines above in SRC directory of ATTinyCore,) I can override DELAY_T2TWI to (_us_delay(5)) from my sketch?

Thanks for your help.

[PegasSoft]

Hello everyone,
first of all, thanks SpenceKonde for his work...
I see that you too have had problems with the speed of the USI I2C.
I state that I do not have a logic analyzer, I am based on the times calculated with an ATmega328P in the same conditions, the same sketch and the same peripheral ...
A few weeks ago I downloaded the ATtinyCore to test with an ATtiny85, both as a master and as a slave and as a master I had several timing problems.
Analyzing the code, I too noticed problems with these definitions on the USI_TWI_Master.h, so I went back to the original Atmel code (AVR310).

/******* USI_TWI_Master.h **********/
#if __GNUC__
#ifndef F_CPU
#define F_CPU 4000000
#endif
#include <avr/io.h>
#include <util/delay.h>
#endif
//********** Defines **********//
// Defines controlling timing limits
#define TWI_FAST_MODE

#define SYS_CLK 4000.0 // [kHz]

#ifdef TWI_FAST_MODE                            // TWI FAST mode timing limits. SCL = 100-400kHz
#define T2_TWI ((SYS_CLK * 1300) / 1000000) + 1 // >1,3us
#define T4_TWI ((SYS_CLK * 600) / 1000000) + 1  // >0,6us

#else                                           // TWI STANDARD mode timing limits. SCL <= 100kHz
#define T2_TWI ((SYS_CLK * 4700) / 1000000) + 1 // >4,7us
#define T4_TWI ((SYS_CLK * 4000) / 1000000) + 1 // >4,0us
#endif

…

#if __GNUC__
#define DELAY_T2TWI (_delay_us(T2_TWI / 4))
#define DELAY_T4TWI (_delay_us(T4_TWI / 4))
#else
#define DELAY_T2TWI (__delay_cycles(T2_TWI))
#define DELAY_T4TWI (__delay_cycles(T4_TWI))
#endif

/******* USI_TWI_Master.c **********/
unsigned char USI_TWI_Master_Transfer(unsigned char temp)
{
	USISR = temp;                                          // Set USISR according to temp.
	                                                       // Prepare clocking.
	temp = (0 << USISIE) | (0 << USIOIE) |                 // Interrupts disabled
	       (1 << USIWM1) | (0 << USIWM0) |                 // Set USI in Two-wire mode.
	       (1 << USICS1) | (0 << USICS0) | (1 << USICLK) | // Software clock strobe as source.
	       (1 << USITC);                                   // Toggle Clock Port.
	do {
		DELAY_T2TWI;
		USICR = temp; // Generate positve SCL edge.
		while (!(PIN_USI & (1 << PIN_USI_SCL)))
			; // Wait for SCL to go high.
		DELAY_T4TWI;
		USICR = temp;                   // Generate negative SCL edge.
	} while (!(USISR & (1 << USIOIF))); // Check for transfer complete.

	DELAY_T2TWI;
	temp  = USIDR;                 // Read out data.
	USIDR = 0xFF;                  // Release SDA.
	DDR_USI |= (1 << PIN_USI_SDA); // Enable SDA as output.

	return temp; // Return the data from the USIDR
}
/****************************/

I don't know where the port in this library comes from, but it has two big problems:

1. the time is rounded to 5us against Atmel's 4.7 us, then as babushon said, they used the _delay_loop_1 which introduces a delay equal to n*3 CPU cycles so the calculated cycles are divided by 3 generating other approximations.

2. in the original Atmel code, the clock was set at 4MHz and the choice between standard mode and fast mode was done at compile time. In this port, however, it has been modified so that you can change the speed at runtime. Good thing you will say, but unfortunately the (considerable) delay introduced by this change has not been considered.
   Analyzing the assembler source I noticed that each test carried out on the USI_TWI_MASTER_SPEED field causes a delay of 9 cycles for the fast mode and 5 cycles for the standard, therefore at 16MHz 562.5ns and 312.5ns, at 8MHz they become 1125ns and 625ns.

in my research I then came across this page almost by chance:
https://gcc.gnu.org/onlinedocs/gcc/AVR-Built-in-Functions.html
thanks to which I found the function:
void __builtin_avr_delay_cycles (unsigned long ticks)
to enter the exact number of delay machine cycles.

For me the best thing would be to go back to the modified Atmel code:

/******************
USI_TWI_Master.h
******************/
#if !defined (TWI_STANDARD_MODE)
#define	TWI_STANDARD_MODE
#endif
#if !defined (TWI_FAST_MODE)
//#define	TWI_FAST_MODE
#endif

#if defined (TWI_STANDARD_MODE)
#define	T2_TWI		T2_TWI_STD
#define	T4_TWI		T4_TWI_STD
#elif defined (TWI_FAST_MODE)
#define	T2_TWI		T2_TWI_FM
#define	T4_TWI		T4_TWI_FM
#endif

#define SYS_CLK   F_CPU/1000UL  // [kHz]

#define T2_TWI_STD	((SYS_CLK * 4700UL) / 1000000UL) + 1UL // >4,7uS
#define T4_TWI_STD	((SYS_CLK * 4000UL) / 1000000UL) + 1UL // >4,0uS
#define T2_TWI_FM	((SYS_CLK * 1300UL) / 1000000UL) + 1UL // >1,3uS
#define T4_TWI_FM	((SYS_CLK *  600UL) / 1000000UL) + 1UL // >0,6uS

#define DELAY_T2TWI (__builtin_avr_delay_cycles(T2_TWI))
#define DELAY_T4TWI (__builtin_avr_delay_cycles(T4_TWI))
/*************************************************************/`

For the USI_TWI_Master.c you cannot use the Atmel code directly because the USI_TWI_Start_Transceiver_With_Data has been modified for the needs of Wire (stop ...), but you can easily make the following changes to the current one:

change all occurrence of:
if (USI_TWI_MASTER_SPEED) DELAY_T2TWI_FM; else DELAY_T2TWI;
to:
DELAY_T2TWI;

and
if (USI_TWI_MASTER_SPEED) DELAY_T4TWI_FM; else DELAY_T4TWI;
to:
DELAY_T4TWI;

paying attention to this:

   if (USI_TWI_MASTER_SPEED) DELAY_T4TWI_FM; // Delay for T4TWI if TWI_FAST_MODE
   else DELAY_T2TWI; // Delay for T2TWI if TWI_STANDARD_MODE

to be changed to:

#ifdef TWI_FAST_MODE
    DELAY_T4TWI:
#else
    DELAY_T2TWI;
#endif

these also greatly simplify the reading of the code ...

I then also modified Wire.cpp:

void TwoWire::setClock (uint32_t clock) {
// USI_TWI_Master_Speed (clock> 200000);
}

as I have completely eliminated the USI_TWI_Master_Speed function.

Using these changes in USI_TWI_Master.h and USI_TWI_Master.c a transfer of 7 bytes + address at 100KHz takes exactly the same 940us average time of the mega328P, at 400KHz it is slightly faster, ~ 312 us against the 316-320 of the mega328P.

at 16MHz the delay cycle calculation is very correct, for 'strange' clocks there will probably be some changes to be made...

One last thing ... I noticed that with more I2C peripherals the tiny85 needs more 'robust' pullups.
The mega328P only needs 4.7k pullups (plus internal pullup) and in this way it works very well even at 800KHz, instead the tiny85 to reach the same speeds I had to add a further 4.7k pullup. With only one device connected, 4.7k is enough.

I hope I have written something useful for you :)

[SpenceKonde]

I think I've gotten the USI I2C problem solved for 2.0.0, essentially in the same way, only without removing the master speed function and hence the ability to enable fastmode.

[PegasSoft]

@SpenceKonde
Hi,
before writing the message, I studied the USI_TWI_Master code of 2.0.0 to see if I could use it, but it seems to me the same as the one I was using in 1.5.2.
With the precise calculation of the delay cycles and the use of the __builtin_avr_delay_cycles I was also able to maintain the correct timing, but only by subtracting from the DELAY_TxTWI the number of cycles needed to do the test calculated in the disassembled code. But this is not a safe system because it depends on the compiler version and compile-time options.
Without these changes with 16MHz clock in fast mode there was a slowdown of about 30%

[SpenceKonde]

That would be because I haven't checked in those changes....

I think the built-in pullup interacts with the USI differently than it does with real hardware I2C.

I2C without an external pullup is never remotely close to meeting spec HOWEVER where there's real hardware I2C, classic AVRs when they aren't actively driving the bus low, will set the pins high and input - hence turning on the internal pullup which is about 35k (ie, nearly an order of magnitude weaker than it should be). This is, amazingly, sometimes good enough for very simple configurations to work under ideal conditions.

In DxCore and megaTinyCore, I specifically don't turn on the pullups unless the user asks for them. If the pullups being turned on fixes the problem, you forgot to install external pullups, or the Vcc rail you connected them to isn't actually tied to vcc or something like that.

4.7k is appropriate for pullups on at normal speed, I think you need stronger pullups for fast mode.

[PegasSoft]

@SpenceKonde

I think the built-in pullup interacts with the USI differently than it does with real hardware I2C

This may be, I have no experience with using the USI device such as I2C, so far I have only used it in SPI mode.
Personally on the different cores I use I have disabled the internal pullups for I2C because they alter the overall value of the pullups. Without it you can make a more precise calculation of the load on the I2C (max 3mA if I remember correctly). Here for now I am still in the testing phase, now I am testing the I2C slave, then I will test at 8MHz which will be the actual speed of the project.
As soon as possible I will do some tests turning off the internal pullups.