notes.txt

Technical Notes:
----------------

I2C
---
Since adding the obdCachededWrite feature to reduce the number of I2C transactions
when drawing fixed fonts, I discovered the limitations of the Wire library. On AVR
targets the wire library allows a maximum write length of 32 bytes in a single call.
Any data beyond the 32 bytes is not sent. The ESP32 has a similar behavior, but the
limit is 128 bytes. OneBitDisplay tests for this condition in the write wrapper function
and breaks up a data write into 32-byte pieces if it's being sent to hardware I2C.
The bit-bang I2C doesn't have this limitation, so the write length is unlimited.

BLE
---
Getting BLE to work on both ESP32 and the Arduino hardware like the Nano 33 BLE was
challenging not only because of the different API, but a fundamental difference in
behavior. Sending fast data is hindered when the write() requests a response. On ESP32
the writeValue() method allows you to choose if you want a response or not, but on
the ArduinoBLE library (for the Nano 33 BLE), it will choose to wait for a response
when the characteristic offers both properties. I added a new overloaded function to
the ArduinoBLE library to allow you to choose. I created a pull request on Github and
hope that Arduino will eventually merge the code:

https://github.com/arduino-libraries/ArduinoBLE/pull/72

UART
----
Sending the SSD1306 commands over a UART presented new challenges. With I2C and
BLE there are well defined "packets" because a transmission begins and ends.
This is necessary for this type of data stream because a single byte tells the
display controller to interpret the following bytes as commands or graphics.
If there is no boundary between one packet and the next, the controller will
misinterpret the start byte as a command or graphics from the previous packet.
This is the exact problem with transmission over a UART because the way the
data is read on the receiving end doesn't necessarily correspond with the way
it's transmitted. To solve this problem, I added additional code on the 
sending side to add a length byte in front of each packet and on the receiving
end I added code to re-sync the data if the length+D/C bytes don't line up
properly.