All in one chunk because the infrastructure is already there.
This also implements the parallel 4-bit bus used by quite some
displays.
For now you have to add quite a number of #defines to your
config.h. First, there are all the pins required, pin names
changed to your actual board/display connection, of course:
#define DISPLAY_RS_PIN PC1
#define DISPLAY_RW_PIN PC0
#define DISPLAY_E_PIN PD2
#define DISPLAY_D4_PIN PD3
#define DISPLAY_D5_PIN PD4
#define DISPLAY_D6_PIN PD5
#define DISPLAY_D7_PIN PD6
And then the information about the display actually existing:
#define DISPLAY_BUS_4BIT
#define DISPLAY_TYPE_HD44780
Allowing to do all this in Configtool is forthcoming, of course.
Now we shouldn't experience wait cycles in i2c_write() during
typical display writes any longer. It should also distribute CPU
load of display writes a lot better.
Previously writing a line of text to the display would take
almost as long as it took to actually send it to the display,
because the I2C queue could hold only one transmission, which
effectively meant only one character. This could hold the main
loop for several milliseconds.
Now we queue characters, send them one by one, and return to the
main loop in between.
This costs 160 bytes program memory. Only 18 bytes RAM, because
the I2C queue was reduced accordingly. Now:
Program: 24456 bytes
Data: 1543 bytes
EEPROM: 32 bytes
This isn't pretty at all, but it shows the principle.
Unfortunately it also exploits a bug in the I2C sending mechanism,
I2C sending hangs a few seconds after reset.
You see where the journey is going? This is the equivalent to the
function to write a character to the serial line, so we can
basically swap these two in other functions.
Markus Hitter