#Ssd1306 arduino i2c example software
#Ssd1306 arduino i2c example code

#Ssd1306 arduino i2c example code

This may be due to the -Os option trying to make the code small. I also noticed that my 'inline' modifiers on static functions were being ignored. This makes the code less readable to people unfamiliar with ARV MCUs, but necessary in order to gain the speed. The alternative way to access GPIO on AVRs is to reference the PORT (digital output) and DDR (data direction) registers directly. The downside to using those functions is that they do a bit more than just translate the pin numbers and this causes poor performance.

#Ssd1306 arduino i2c example software

This makes it easier to port your software from an ATMega328 to an ATtiny85. The pinMode and digitalWrite / digitalRead functions hide those differences by referencing everything as a physical pin number. A little background - the AVR MCUs come in a variety of configurations and the GPIO ports are mapped to the pins differently depending on the chip. The speed is not impressive, but that's not a deterrent because I know that those access GPIO methods are slow.

The clock frequency I'm generating varies from byte to byte and bit to bit, but I2C is very forgiving as long as the data is stable during the clock transitions. Before anyone starts to complain that I'm not following the spec, for this project I'm not interested in creating a 100% compliant I2C protocol emulator, I just want to see how fast I can push the SSD1306 by bit-banging the data into the I2C pins.Д resulted in a display refresh speed of 5.5 FPS. This meant that I could leave the SDA and SCL lines as outputs the whole time I was writing data.

I was curious if this could be ignored and for the SSD1306, it doesn't seem to care. There is an acknowledge bit that gets sent back from the slave to the master after each byte is sent to signal that it was received successfully. When the master wants to begin a transaction, it sets the lines as output signals and follows the protocol. The signal lines are normally pulled up to VCC and in tri-state (high impedance). The condensed version is that there is typically one master and one or more slave devices on the bus (data + clock lines, aka SDA + SCL). I grabbed a copy of the I2C protocol specification (Rev 6, April 4, 2014) which is apparently owned by NXP Semiconductors.