LCD Graphics/Text Driver for cheap SPI LCD's with optional Touch screen support

jrullan

@ManAtWork said:

I also planned to provide larger fonts. But instead of scaling the 8x8 font up I'd rather use the 32x32 font from the P1 ROM and scale it down.

>

That's great. I'm looking forward to test it when it is implemented, it would benefit my UI framework with a better looking font.

ManAtWork

I just looked at the code. Uaagghh! The fonts use a very strange format of reverse packed bits and the code to extract that into pixels looks weired. I think the reason for this was that the original driver by Cluso placed the font data in cog RAM where there was very little space and it wasn't adressable as single bytes but longword-only. I moved the font data to hub RAM which is byte-adressable and there's a lot more space so we can get rid of that ugly format and store the pixels in their natural order.

Speed is also no concern because the scaling doesn't have to be done in real time. I would pre-calculate the font in the desired size and then let the driver just copy it from the memory image. This takes a bit more RAM but it shouldn't be a problem unless you need more than, say, 2 or 3 different font sizes at once.

Will take some time, though to update the code...

ManAtWork

Ok, I figured it out and re-ordered the bytes in the 6x8 and 8x8 fonts. It now looks like this

  byte %00000000  '\ $41 A   ........
  byte %00011000  '|         ...**...
  byte %00111100  '|         ..****..
  byte %01100110  '|         .**..**.
  byte %01100110  '|         .**..**.
  byte %01111110  '|         .******.
  byte %01100110  '|         .**..**.
  byte %00000000  '/         ........

instead of

  byte %01100110  '\ $41 A   ........
  byte %00111100  '|         ...**...
  byte %00011000  '|         ..****..
  byte %00000000  '|         .**..**.
  byte %00000000  '|         .**..**.
  byte %01100110  '|         .******.
  byte %01111110  '|         .**..**.
  byte %01100110  '/         ........

The driver should now theoretically work with any font size but I still have to implement the actual scaling.

msrobots

I somehow remember there was a trick to use the P1 font as 2 o 4 bit color, that was the reason for the original font order.

Mike

ManAtWork

Yeah, success!

@msrobots said:
I somehow remember there was a trick to use the P1 font as 2 o 4 bit color, that was the reason for the original font order.

The P1 had the pixels of an even/odd character pair interleaved for that reason. But that has nothing to do with Roger's packed format where the 6x8 font used one and a half longword in cog RAM per character with the byte order swapped.

msrobots

looks great

ManAtWork

If anyone want to try, here is the preliminary source code. If it works I'll put it on OBEX/GITHUB.

Depending on the requirements either LCD_FixedFont.spin2 or LCD_VarSizeFont.spin2 can be included, see Demo for an example. You can change the font at any time by calling lcd.SetFont().

Generating the 12x16 font out of the 16x16 image takes ~70ms in Spin. I think that could be sped up by a factor of 10 if optimized in PASM but as it's only required once at startup it doesn't really matter.

jrullan

Excellent! Will try soon enough. Thanks

jrullan

@ManAtWork said:
If anyone want to try, here is the preliminary source code. If it works I'll put it on OBEX/GITHUB.

Depending on the requirements either LCD_FixedFont.spin2 or LCD_VarSizeFont.spin2 can be included, see Demo for an example. You can change the font at any time by calling lcd.SetFont().

Generating the 12x16 font out of the 16x16 image takes ~70ms in Spin. I think that could be sped up by a factor of 10 if optimized in PASM but as it's only required once at startup it doesn't really matter.

Fantastic job! Thank you for the update to the driver. Also thank you for providing a way to set the pins through SetLcdPins and SetTouchPins.

ManAtWork

Thanks. There may be some cosmetic optimizations to be done. I decided to use a 16x16 image as base for all variable size fonts. The original 16x32 from the P1 ROM would probably be better but would use more memory. Cutting it in half causes aliasing, for example the upper horizontal line of the "E" is thinner than the middle and lower lines. That could be fixed by a more clever anti-aliasing scaling or simply manual pixel painting in the 16x16 source.

jrullan

@ManAtWork Here is a test video of the driver with my framework:

jrullan

In reviewing this thread I remembered I had added a function to my copy of the driver after researching how to fill circles. Maybe there's a better/faster way to do this, but this is what I got. I'll post it here in case someone needs this.

PUB fillCircle(xc, yc, r, rgb)|x,y,xr,yr,d
'Midpoint Circle Algorithm, also known as Bresenham's Circle Algorithm.
  x := 0
  y := r
  d := 1 - r
  repeat while x <= y
    drawLine(xc-x, yc+y, xc+x, yc+y, rgb) 
    drawLine(xc-x, yc-y, xc+x, yc-y, rgb) 
    drawLine(xc-y, yc+x, xc+y, yc+x, rgb) 
    drawLine(xc-y, yc-x, xc+y, yc-x, rgb) 

    x++
    if d < 0
      d := d + 2*x + 3
    else
      y--
      d := d + 2*(x - y) + 5

JonnyMac

I don't know if this is any faster -- it's something I "liberated" from an Arduino graphics library.

pub fill_circle(x, y, radius, color) | x1, y1, err, e2

'' Draw filled circle of radius at x/y

  x1  := -radius
  y1  := 0
  err := 2-2*radius

  repeat
    line(x-x1, y+y1, x-x1, y-y1, color)
    line(x+x1, y+y1, x+x1, y-y1, color)
    e2 := err
    if (e2 <= y1)
      err += ++y1*2+1
      if ((-x1 == y1) && (e2 <= x1))
        e2 := 0
    if (e2 > x1)
      err += ++x1*2+1
  while (x1 <= 0)

Wuerfel_21

The obvious optimization here is to replace the arbitrary X/Y to X/Y line draw with a specific horizontal/vertical line function. If you're plotting individual pixels when filling a shape, you've already lost. Though looking at the code, it seems there is no such function is implemented, so do that first. IIRC these LCD controllers can do both vertical and horizontal fills quickly.

jrullan

@Wuerfel_21 said:
The obvious optimization here is to replace the arbitrary X/Y to X/Y line draw with a specific horizontal/vertical line function. If you're plotting individual pixels when filling a shape, you've already lost. Though looking at the code, it seems there is no such function is implemented, so do that first. IIRC these LCD controllers can do both vertical and horizontal fills quickly.

IIRC the Adafruit's library has a fastVLine and a fastHLine that are probably using some feature of the ILI9341. Unfortunately I don't understand most of the terms in the datasheet to be able to figure out what is needed to be done to implement something similar.

jrullan

Ok, this seems to have improved the fill circle rendering time:
Fiddling with the driver a bit added these two functions:

PUB drawFastHLine(x,y,l,rgb)
    setWindow(x,y,x+l,y)
    fillWindow(rgb)

PUB drawFastVLine(x,y,l,rgb)
    setWindow(x,y,x,y+l)
    fillWindow(rgb)

So the fillCircle function now reads:

PUB fillCircle(xc, yc, r, rgb)|x,y,xr,yr,d
'Midpoint Circle Algorithm, also known as Bresenham's Circle Algorithm.
  x := 0
  y := r
  d := 1 - r
  repeat while x <= y
    drawFastHLine(xc-x, yc+y, 2*x, rgb)
    drawFastHLine(xc-x, yc-y, 2*x, rgb)
    drawFastHLine(xc-y, yc+x, 2*y, rgb) 
    drawFastHLine(xc-y, yc-x, 2*y, rgb) 

    x++
    if d < 0
      d := d + 2*x + 3
    else
      y--
      d := d + 2*(x - y) + 5

It is working much faster than previous approach.

jrullan

Did this as well...

PUB drawLine(xs, ys, xe, ye, rgb) | i, x, y, dx, dy
' Draw Line - start co-ords, end co-ords, color
  dx:= xe - xs
  dy:= ye - ys

  if dx == 0
    drawFastVLine(xs,ys,dy,rgb)
  elseif dy == 0
    drawFastHLine(xs,ys,dx,rgb)
  else
    if ABS(dx) > ABS(dy)   'plot incrementing x axis
      repeat i from 0 to dx
        y := (dy*i + dx/2)/dx
        drawPixel(xs+i, ys+y, rgb)
    else 'plot incrementing y axis
      repeat i from 0 to dy
        x := (dx*i + dy/2)/dy
        drawPixel(xs+x, ys+i, rgb)

Most of the widgets in my framework use straight lines so this change has a greater impact.

AJL

@jrullan said:
Ok, this seems to have improved the fill circle rendering time:
Fiddling with the driver a bit added these two functions:

PUB drawFastHLine(x,y,l,rgb)
    setWindow(x,y,x+l,y)
    fillWindow(rgb)

PUB drawFastVLine(x,y,l,rgb)
    setWindow(x,y,x,y+l)
    fillWindow(rgb)

So the fillCircle function now reads:

PUB fillCircle(xc, yc, r, rgb)|x,y,xr,yr,d
'Midpoint Circle Algorithm, also known as Bresenham's Circle Algorithm.
  x := 0
  y := r
  d := 1 - r
  repeat while x <= y
    drawFastHLine(xc-x, yc+y, 2*x, rgb)
    drawFastHLine(xc-x, yc-y, 2*x, rgb)
    drawFastHLine(xc-y, yc+x, 2*y, rgb) 
    drawFastHLine(xc-y, yc-x, 2*y, rgb) 

    x++
    if d < 0
      d := d + 2*x + 3
    else
      y--
      d := d + 2*(x - y) + 5

It is working much faster than previous approach.

As drawing involves communication with the screen to set the window and fill it, it would be good to do this the minimum number of times (which I think would be 2R times using horizontal lines)
Calculation, on the other hand, should be relatively fast.
At the potential expense of more memory use, I think this might be faster:

PUB fillCircle(xc, yc, r, rgb)|x, y, xs[r], l[r], d
'Midpoint Circle Algorithm, also known as Bresenham's Circle Algorithm.
  x := 0
  y := r
  d := 1 - r
  xs[r] := 0
  l[r] := 0
  repeat while x <= y
    xs[y] := xc - x
    l[y] := 2*x
    xs[x] := xc - y
    l[x] := 2*x
    x++
    if d < 0
      d := d + 2*x + 3
    else
      y--
      d := d + 2*(x - y) + 5     
  repeat x from 0 to r
    drawFastHLine(xs[x], yc+x, l[x], rgb)
    drawFastHLine(xs[x], yc-x, l[x], rgb)

jrullan

@AJL said:

@jrullan said:
Ok, this seems to have improved the fill circle rendering time:
Fiddling with the driver a bit added these two functions:

PUB drawFastHLine(x,y,l,rgb)
    setWindow(x,y,x+l,y)
    fillWindow(rgb)

PUB drawFastVLine(x,y,l,rgb)
    setWindow(x,y,x,y+l)
    fillWindow(rgb)

So the fillCircle function now reads:

PUB fillCircle(xc, yc, r, rgb)|x,y,xr,yr,d
'Midpoint Circle Algorithm, also known as Bresenham's Circle Algorithm.
  x := 0
  y := r
  d := 1 - r
  repeat while x <= y
    drawFastHLine(xc-x, yc+y, 2*x, rgb)
    drawFastHLine(xc-x, yc-y, 2*x, rgb)
    drawFastHLine(xc-y, yc+x, 2*y, rgb) 
    drawFastHLine(xc-y, yc-x, 2*y, rgb) 

    x++
    if d < 0
      d := d + 2*x + 3
    else
      y--
      d := d + 2*(x - y) + 5

It is working much faster than previous approach.

As drawing involves communication with the screen to set the window and fill it, it would be good to do this the minimum number of times (which I think would be 2R times using horizontal lines)
Calculation, on the other hand, should be relatively fast.
At the potential expense of more memory use, I think this might be faster:

PUB fillCircle(xc, yc, r, rgb)|x, y, xs[r], l[r], d
'Midpoint Circle Algorithm, also known as Bresenham's Circle Algorithm.
  x := 0
  y := r
  d := 1 - r
  xs[r] := 0
  l[r] := 0
  repeat while x <= y
    xs[y] := xc - x
    l[y] := 2*x
    xs[x] := xc - y
    l[x] := 2*x
    x++
    if d < 0
      d := d + 2*x + 3
    else
      y--
      d := d + 2*(x - y) + 5     
  repeat x from 0 to r
    drawFastHLine(xs[x], yc+x, l[x], rgb)
    drawFastHLine(xs[x], yc-x, l[x], rgb)

Interesting... Thanks for the suggestion! Have you perform any testing? If not I could do some testing and post results.

jrullan

@jrullan said:

@AJL said:

PUB fillCircle(xc, yc, r, rgb)|x, y, xs[r], l[r], d
'Midpoint Circle Algorithm, also known as Bresenham's Circle Algorithm.
  x := 0
  y := r
  d := 1 - r
  xs[r] := 0
  l[r] := 0
  repeat while x <= y
    xs[y] := xc - x
    l[y] := 2*x
    xs[x] := xc - y
    l[x] := 2*x
    x++
    if d < 0
      d := d + 2*x + 3
    else
      y--
      d := d + 2*(x - y) + 5     
  repeat x from 0 to r
    drawFastHLine(xs[x], yc+x, l[x], rgb)
    drawFastHLine(xs[x], yc-x, l[x], rgb)

Interesting... Thanks for the suggestion! Have you perform any testing? If not I could do some testing and post results.

@AJL , I tried to run that code in Propeller Tool, FlexProp and Spin Tools IDE but none of them recognize the syntax for the declaration of xs[r] and l[r]

PUB fillCircle(xc, yc, r, rgb)|x, y, xs[r], l[r], d

avsa242

It's because of the variable 'r' used in the definition of xs and l - these can't be known at build time. I haven't looked at the code in depth, but I'd assume by the name that the number of elements in the two arrays is meant to be the same as the radius (so maybe define with worst-case?)

jrullan

@avsa242 said:
It's because of the variable 'r' used in the definition of xs and l - these can't be known at build time. I haven't looked at the code in depth, but I'd assume by the name that the number of elements in the two arrays is meant to be the same as the radius (so maybe define with worst-case?)

I'm not sure I understand. I don't see how that can be done, you cannot know the radius in advance, and I'm not sure it is worth the extra memory considering its current performance is acceptable. If someone manages to do some profiling of the algorithms and the results merit then it would be worth it.

AJL

@jrullan said:

@avsa242 said:
It's because of the variable 'r' used in the definition of xs and l - these can't be known at build time. I haven't looked at the code in depth, but I'd assume by the name that the number of elements in the two arrays is meant to be the same as the radius (so maybe define with worst-case?)

I'm not sure I understand. I don't see how that can be done, you cannot know the radius in advance, and I'm not sure it is worth the extra memory considering its current performance is acceptable. If someone manages to do some profiling of the algorithms and the results merit then it would be worth it.

@avsa242 understood my intent. What’s the biggest radius circle you expect the driver to support? That would be the size you’d need to allow for.
If you are satisfied with the performance then that’s fine. It was just a suggestion for the circumstance that you were only marginally happy with the performance you had achieved.
Another thought that I had, but haven’t investigated, would be to determine the corners of boxes (instead of the endpoints of lines.) That would allow a smaller number of setwindow / fillwindow sequences, but each sequence might take the display longer to perform. It wouldn’t need much more memory than what you are currently doing either.

If you aren’t interested I’ll leave it untouched.

pik33

That's what I have in my drivers family. Fastline draws a horizontal line from x1 to x2 at y in color c.

'-- A filled circle -----------------------------------------------------

pub fcircle(x0,y0,r,c) | d,x,y,da,db

d:=5-4*r
x:=0
y:=r
da:=(-2*r+5)*4
db:=3*4
repeat while (x<=y) 
  fastline(x0-x,x0+x,y0-y,c)
  fastline(x0-x,x0+x,y0+y,c)
  fastline(x0-y,x0+y,y0-x,c)
  fastline(x0-y,x0+y,y0+x,c)
  if d>0 
    d+=da
    y-=1
    x+=1
    da+=4*4
    db+=2*4
  else
    d+=db
    x+=1
    da+=2*4
    db+=2*4

jrullan

@AJL said:
....
@avsa242 understood my intent. What’s the biggest radius circle you expect the driver to support? That would be the size you’d need to allow for.
....

In my case, since I'm building a framework for creating GUIs in general, I wouldn't want to limit the size of the circle to any given maximum radius. Further, I'm not the OG of the driver, nor an official contributor, I just shared my method here in case someone else would like to use it but I'm sure it would be a welcomed contribution if someone else does it. Again, thanks for the suggestion.

Electrodude

You don't need all those arrays. When Y moves to the next row, plot the previous row using the outermost X values encountered for that row.

AJL

@Electrodude said:
You don't need all those arrays. When Y moves to the next row, plot the previous row using the outermost X values encountered for that row.

Yes, I see that now.

AJL

Just to close the loop for anyone reading along, this is the slightly faster approach that requires no extra memory:

PUB fillCircle(xc, yc, r, rgb)|x, y, d
'Midpoint Circle Algorithm, also known as Bresenham's Circle Algorithm.
  x := 0
  y := r
  d := 1 - r
  repeat while x <= y
    x++
    if d < 0
      d := d + 2*x + 3
    else
      drawFastHLine(xc-x, yc+y, 2*x, rgb)
      drawFastHLine(xc-x, yc-y, 2*x, rgb)
      drawFastHLine(xc-y, yc+x, 2*y, rgb) 
      drawFastHLine(xc-y, yc-x, 2*y, rgb) 
      y--
      d := d + 2*(x - y) + 5     

jrullan

In case someone else needs this, I just added a new method for sending an image's pixel data (word) in 5-6-5 RGB format to the ILI9341 display.
Previously I was using a Spin2 method that called drawPixel() on each pixel of the image, but it was significantly slower.

' Spin2 code
''+-----------------------------------------------------+
'' Added by Jose Rullan 
'' mailbox  (data): $88  -> sendImage command
'' mailbox1 (data1): imagePtr
''+-----------------------------------------------------+
PUB sendImage(imagePtr,x,y,w,h)
  setWindow(x, y, x+w-1, y+h-1)
  WaitMailbox()
  mailbox1 := imagePtr
  mailbox  := $88_00_0000


' PASM2 code mods
'...
                cmp     command, #$88     wz            '| $88= paintImage
        if_e    jmp     #send_image_data                '|
'...


' PASM2 new code
''+-----------------------------------------------------+
'' Added by Jose Rullan 
'' sendImage(imagePtr, x, y, w, h)
'' mailbox1 (data1): imagePtr
''+-----------------------------------------------------+
send_image_data
                'Setup FIFO read of image data
                rdfast #0, data1

                'Send command to ILI9341
                mov     data, #LCD_RAM_WRITE            ' Send LCD_RAM_WRITE command to ILI9341
                call    #writecmd

                'Send pixels to ILI9341
.next_pixel     rfword  data                            ' Reads a pixel from imagePtr into data
                call    #write16data                    ' Send pixel data to ILI9341
                djnz    pixelno,#.next_pixel            ' Decrement pixelno and if not zero loop for next word (pixel data)
                jmp     #done

I confess this ended up being simpler than I expected but it took me a while to figure out exactly what to do. First trying to understand existing code to notice the pattern of how a command and data was sent to the ILI9341 (not fully understood yet), then understanding the mailbox parameters mechanism and how to use it from Spin2 and finally, figuring out (by looking at the rest of the code) how to create a loop to send the image pixels.

Feedback is always welcome (even if I don't get it the first time).

M.E.S.H

I've tried this with a 1.3 inch LCD, with a ST7789, from WaveShare:
https://www.waveshare.com/1.3inch-lcd-module.htm

LCD_Graphics_Driver_v3.01

Demo:

' LCD: 1.3in 240x240 ST7789 LCD
  width         = 240                                   ' lcd screen width  (pixels)   \ 1.3in 240x240 ST7789 LCD & 8x8 font
  height        = 240                                   '            height (pixels)   |
  lcd_rotate    = LCD_rotate_0                         ' lcd no rotation / mirror       /
  touchscreen   = false                                 ' false = touch screen disabled

Driver``, in PRI lcdInit(rotate):
...

' Pixel Format 16bits/pixel
  lcdWriteCmd(LCD_PIXEL_FORMAT)
  lcdWriteData($05)                                     ' 16b/pixel

' Invert display colors
  lcdWriteCmd(LCD_INVERSION_ON)
  waitms(5)

  'set display rotation and RGB/BRG Order
  'Bit D3- RGB/BGR Order
  '0 = RGB (When MADCTL D3=0)
  '1 = BGR (When MADCTL D3=1)
  lcdWriteCmd(LCD_MADCTR)                               ' mem addr ctrl
  lcdWriteData(rotate + $08)                            ' rotation 0/90/180/270deg=$00/$A0/$C0/$60 + RGB/BGR Order (+$00 OR +$08)

' Display On
  lcdWriteCmd(LCD_DISPLAY_ON)
  waitms(1)                                             ' 1ms

```

And it seems to present the colors correct now, black background, and BGR instead of RGB.

It would be good to have a "color list" in the demo, with the colors name/text, in that color.

/M.E.S.H