Hi Kurt,
Thanks for your message in the other thread. I went back and looked at the code again, and then looked at the Adafruit_GFX library.
I don't think the original library is treating this as a 6x9 character cell. That is, when you say:
But the height we set up is 8*size+1 pixels and we are outputting 9*size rows of data.
I don't think that's right (or at least it changes the semantics from the original Adafruit library). I read this to say that you're drawing a 6x9 character cell (5x8 character dots, plus one row and one column of background as spacing between glyphs). But I checked the original code and the pixels on the display, and I think it outputs a 6x8 cell (5x8 character dots, plus just the blank column to the right of the glyph, not a blank row below it).
The glcdfont.c file says it's a 5x7 font, and maybe it was originally, but it's stored and drawn as a 5x8 font (and the font currently contains descenders into the 8th row). Adafruit_GFX doesn't draw a 9th blank row, it just butts the lines against each other vertically. If you have descenders and full-height characters on consecutive lines, they do touch. This might not be ideal, but it's the way the original library appears to work.
Adafruit_GFX.cpp and ILI9341_t3.cpp both contain this in the write( uint8_t c ) method to process a newline:
Code:
if (c == '\n') {
cursor_y += textsize*8;
cursor_x = 0;
}
I've confirmed this in the original code and by counting pixels on the LCD. Maybe when you have a moment you could take a look and see if you disagree.
I'm using the following code for the last part of drawChar() for the moment. I don't know enough about the SPI code to understand the implications, but I wanted to ensure that the data was all written using writedata16_cont() except the last, and write that out with writedata16_last(), since the code implies that that's important. This code still might be bugged... I am only writing to a single display at the moment, not using anything else on the SPI bus, and not reading from the display either. I suspect those scenarios are where the problems will come up if this code is incorrect.
This code draws the same pixels to the screen as the Adafruit code does when drawing multiple lines of text.
Code:
} else {
// This solid background approach is about 5 time faster
SPI.beginTransaction(SPISettings(SPICLOCK, MSBFIRST, SPI_MODE0));
setAddr(x, y, x + 6 * size - 1, y + 8 * size - 1);
writecommand_cont(ILI9341_RAMWR);
uint8_t xr, yr;
uint8_t mask = 0x01;
uint16_t color;
for (y=0; y < 8; y++) {
for (yr=0; yr < size; yr++) {
for (x=0; x < 5; x++) {
if (font[c * 5 + x] & mask) {
color = fgcolor;
} else {
color = bgcolor;
}
for (xr=0; xr < size; xr++) {
writedata16_cont(color);
}
}
for (xr=0; xr < size-1; xr++) {
writedata16_cont(bgcolor);
}
if ( y == 7 && yr == size - 1 ) {
// this is the last pixel on the last line
writedata16_last(bgcolor);
} else {
writedata16_cont(bgcolor);
}
}
mask = mask << 1;
}
SPI.endTransaction();
}
}
Cheers,
Dave
