Serial + Wire on attiny25

[pepijndevos]

I have this really simple program that talks to a sensor over UART and can be read over I2C.
It compiles just fine, but as far as I can tell, SDA and TXD are both on PB0.

I tried using SoftwareSerial but it uses too much space.

Is there any way I can disable more stuff to save space, or a way to move the TXD pin elsewhere?

I'm fine with manually hacking some headers, or other more low-level hacks.

#include <Wire.h>

void setup() {
  Wire.begin(8);                // join i2c bus with address #8
  Wire.onRequest(requestEvent); // register event
  Serial.begin(9600);
}

uint8_t res[9];
void loop() {
  const uint8_t cmd[9] = {0xFF, 0x01, 0x86, 0x00, 0x00, 0x00, 0x00, 0x00, 0x79};
  Serial.write(cmd, 9);
  Serial.flush();
  Serial.readBytes(res, 9);
}

// function that executes whenever data is requested by master
// this function is registered as an event, see setup()
void requestEvent() {
  Wire.write(&res[2], 2); // send co2 ppm
}

[pepijndevos]

Maybe setTxBit is the secret... let's try.

[pepijndevos]

Well it did produce output on another pin, but neither I2C nor UART seems to be fully working.

[pepijndevos]

Wire by itself seems to work. This just reads AAAA on the master, even though my scope thinks it's messed up I2C.

#include <Wire.h>

void setup() {
  Wire.begin(8);                // join i2c bus with address #8
  Wire.onRequest(requestEvent); // register event
  //Serial.setTxBit(3);
  //Serial.begin(9600);
  pinMode(3, OUTPUT);
}

const uint8_t cmd[9] = {0xFF, 0x01, 0x86, 0x00, 0x00, 0x00, 0x00, 0x00, 0x79};
uint8_t res[9] = {0xFF, 0xaa, 0xaa, 0xaa, 0xaa, 0x00, 0x00, 0x00, 0x79};
void loop() {
  //Serial.write(cmd, 9);
  //Serial.flush();
  //Serial.readBytes(res, 9);
}

// function that executes whenever data is requested by master
// this function is registered as an event, see setup()
void requestEvent() {
  Wire.write(&res[2], 2); // send co2 ppm
}

Serial by itself... kinda? Without Wire and without changing the txbit it works.
When changing the tx bit nothing works, but when manually changing ANALOG_COMP_AIN0_BIT in variants as suggested in #443 I get Serial output on pin 3.
When adding wire back in, Serial sends out garbage. That is, I think it slows waaaay down, to somewhere around 2000 baud or so.
Do both of them mess with the same timer or something?

#include <Wire.h>

void setup() {
  Wire.begin(8);                // join i2c bus with address #8
  Wire.onRequest(requestEvent); // register event
  //Serial.setTxBit(3);
  Serial.begin(9600);
  //pinMode(3, OUTPUT);
}

//const uint8_t cmd[9] = {0xFF, 0x01, 0x86, 0x00, 0x00, 0x00, 0x00, 0x00, 0x79};
uint8_t res[9] = {0xFF, 0xaa, 0xaa, 0xaa, 0xaa, 0x00, 0x00, 0x00, 0x79};
void loop() {
  Serial.println("hello world");
  //Serial.write(cmd, 9);
  //Serial.flush();
  //Serial.readBytes(res, 9);
}

// function that executes whenever data is requested by master
// this function is registered as an event, see setup()
void requestEvent() {
  Wire.write(&res[2], 2); // send co2 ppm
}

[pepijndevos]

It seems that most of the errors are just it running out of memory.
But it also seems like UART just completely blocks I2C.

[xiaojidan]

wow, this pic is so good. Can you tell me which develop environment? tools or system? linux? macos?

[pepijndevos]

Just a Rigol MSO5074. Insert USB drive, hit "quick" button and voila, screenshot gets saved to USB drive.

[SpenceKonde]

Sorry, I thought I replied

The serial portis a software serial implementation. That means it is counting clock cycles to receive and transmit characters, and has to disable interrupts while doing so. This is much more of a problem since the chip also has a crappy USI instead of real TWI - although as a slave, the USI can receive data if it's busy as the first bits come in (unlike software serial), but unlike real wire, it uses cycle counting and a software strobe to clock the USI (they were too cheap to include a clock generator in the USI - they claim the U stands for universal, but I think "unwieldy" or "unfortunate" better describes it. Essentially all it does for you is clock data in and out, but you provide the clock with a software strobe x_x While recently fixing some issue or another in Wire for 2.0.0-dev, i was struck by the contrast with the modern AVR TWI module, which when generating the clock, waits for the pin to register as high before starting the timer for the high period..... (the slow rise time is a major limiting factor in I2C, since SPI isn't open drain, it can reach much higher speeds. open drain works only up to about 1 MHz if you really try, while serial can and is used at speeds up to 6 mbit (not on AVRs generally, though an AVR DB with extended temperature range can function at 48 MHz with an external clock at room temp, twice it's rated speed.) and SPI can reach 80 MHz and is the de-facto standard for microcontrollers that use external instead of internal flash (it also has been extended to use 4 data lines in some cases, taking over the other pins on the memory - that's how the ESP8266 and ESP32's are able to perform decently despite having everything on an external SPI flash chip - they generally use at least 2 and often 4 of the pins (DIO, and QIO mde), with the chip clocked at like 40 MHz