Writing data to SSD1306 via I2C

I am using OLED SSD1306 and am wondering.

When writing data to a buffer via I2C, some libraries write 16 bytes each time.

For example:

void SSD1306::sendFramebuffer(const uint8_t *buffer) {
  // Set Column Address (0x00 - 0x7F)
  sendCommand(SSD1306_COLUMNADDR);
  sendCommand(0x00);
  sendCommand(0x7F);
  // Set Page Address (0x00 - 0x07)
  sendCommand(SSD1306_PAGEADDR);
  sendCommand(0x00);
  sendCommand(0x07);
  for (uint16_t i = 0;i < SSD1306_BUFFERSIZE;) {
    i2c.start();
    i2c.write(0x40);
    for (uint8_t j = 0;j < 16; ++j, ++i) {
      i2c.write(buffer[i]);
    }
    i2c.stop();
  }
}

      

Why don't they write 1024 bytes directly?

+3


source to share


2 answers


Most of the I2C libraries I've seen source code in, including Aruduino, split data this way. While the I2C standard does not require this as mentioned in other posters, there may be buffer considerations. The command .stop()

here can signal the device to process the 16 bytes just sent and prepare for more.



Invariably, you need to read the datasheet for your device and understand what it expects to display correctly. They say "RTFM" in software, but the hardware is at least as unforgiving. You must read and follow the datasheets when interacting with external hardware devices.

+1


source


Segmenting the data by more frames helps when the receiving device does not have enough buffer space or is simply not fast enough to digest the data at full speed. The START / STOP approach can give the receiving device some time to process the received data. In your specific case, 16 byte chunks appear to be exactly one display line.



Other reasons for segmentation of translations are multi-master operations, but this is not like that.

0


source







All Articles