Going back to electronic after a 20 years break

 Printing stuff  with the ILI9341 over SPI is a bit slow. After looking into it, the main culprit is the SPI+DMA setup/teardown time, which takes about the same time as the transfer itself for small chunks. So let's add a little cache to buffer writing for a given glyph and do a lot less transactions over SPI. With a 512 bytes cache the result are pretty good : This is the time take to print "0123456789" on the screen in milliseconds, using a GD32F303 @ 72 Mhz. - No spi means we compute the bitmaps , but don't send it over SPI - Spi is the regular code, without cache - Spi/cache is the regular cache with a writing cache Nb: Size 18 font is compressed, size 32 is not, that's why it may seem inconsistent.

 One bit per pixel font are a bit harsh on the eye. Let's increase the bit-per-pixel to 2, that is a pixel can have a value between 0 and 3. The above pic is one bit per pixel                                                                That one is two bits per pixel. It's not that obvious, but the 2bpp one is much nicer to look at, especially with very small fonts. Of course,  it basically doubles the flash size consumed by the font bitmap. Unfortunately, the  rule seen previously still applies : Compression is not working for small fonts. But for big fonts you get anti aliased font for ~ free (flash size), and for cheap er for medium fonts. In terms of code size : Adding 2 bits per pixel support : +~ 500 bytes Adding compression support :     + ~2kBytes In terms of speed, if we ignore the SPI/parralel bus time, to display 10 characters (size 32) :    -1bpp nc : 5.5ms    -1bpp c   : 9.5 ms    -2bpp nc : 6 ms    -2bpp c   : 12.5 ms So using 2bpp in terms of cpu load  is not

  While doing something else, i played a bit with adafruit font format. When dealing with big screen (320x240) , the fonts are getting huge and taking a lot of flash space. The obvious answer is : Let's compress them !.  But how does that fare ? So i added support for  heatshrink  in my ILI9341 font rendering engine. and the result is ...... The pink line is uncompressed font, the blue one is heatshrink'ed  font, the axis is font size. The additional font rendering code + heatshrink takes ~ 800 bytes. The bottom line is that if the font size is below ~ 32, it' simply not worth the effort. With font below 10, the compressed font is even bigger than the uncompressed font. In terms of speed, displaying a string of 11 chars with a size 32 font on a 320x240 screen takes : - 25 ms with uncompressed fonts - 30ms with compressed fonts  Both  includes actual display. So the penalty is not too bad for big fonts. So end of story ? Not really, see next post.