GFXMMU LUT. Really have to get from panel manufacturer?

[Carl Farrington]

Posted on July 15, 2018 at 02:10

Hi.

I am doing well. The Panasys 3.4' round TFT (actually it's about 2.4' round, in an octagon, that was probably cut from a 3.4' square once upon a time) MIPI DSI display is working on the stm32l4r9i-discovery, after I made a little adapter board with backlight driver. (

https://www.eevblog.com/forum/projects/critique-my-first-pcb/msg1672430/#msg1672430

  )

but.. the circle is offset, and I'm sure it's because the GFXMMU LUT is for the 390*390 amoled.

I looked at CubeMX, and also I read the AN5051 application note. This says that the panel manufacturer will say what is the first and last pixel of each row.

But they don't

:(

Can't this be worked out? Something to do with Pi and what not?

Do I really have to enter each start and end pixel  for my 320*320 round TFT?

[Tesla DeLorean]

Posted on July 15, 2018 at 04:16

>>Can't this be worked out? Something to do with Pi and what not?

Yes, I'd imagine it would be covered by secondary school math.

On cheaper hardware I'd presume they just store and send a 320x320 bitmap/raster. The ma gic of the GFXMMU you can optimize the frame buffer so you're not wasting memory that the display clips/masks.

>>Do I really have to enter each start and end pixel  for my 320*320 round TFT?

Only in the same sense as you would 'enter' a sine table, I'd either compute it on the fly, on have a PC side app compute and spit out a block of C code to the console.

Here you need to create a cropping table. You could probably create a octogon if that were easier.

320 / 8 = 80 so from lines 0 thru 79, starting point being 80, 79, 78, 77, ... decrementing for each line. The end points 239, 240, 241, ... the middle 160 lines as 0 thru 319, and then the last 80 reversing the sequence of the first 80.

For a circle zero thru 319, use sine over PI radians

[Carl Farrington]

Posted on July 15, 2018 at 04:22

Thank you for replying ! I will sit down with Excel, and no alcohol, tomorrow, and work it out. At least you have confirmed my suspicion that it can be calculated with a bit of thought (and elementary school knowledge/education ;) haha. If only I could go back..), instead of being stuck without the information from the LCD TFT supplier.

[Carl Farrington]

Posted on July 16, 2018 at 02:24

It works :)

It's been quite a successful weekend. I roughly understand how to use TrueStudio and CubeMX, and how to compile the example code.

My first attempt at a PCB design has worked out (Discovery DSI adapter board for Panasys LCD, with back-light driver), as well as my first attempt at reflow soldering with a toaster reflow oven.

And then, getting the actual MIPI DSI screen working with the example code has worked out successfully too!

I do have a question though, if anybody knows about round TFTs. In the example code, they give pixel xPos (column) = 0 for centered text. This didn't work for my panel. I had to give BSP_LCD_GetXSize() / 2 (i.e. 160.. the middle).

Do some round displays treat 0 as the centre? Or have I missed something else somewhere? I have basically looked for everything to do with 390*390 and changed it to 320*320..

[T J]

Posted on July 16, 2018 at 04:34

I think all LCDs etc are X,Y starting in a corner.

in hardware you tend to scan left to right. hence 0,0 in is a corner.

the datasheet for your display will have it.

on page 3 of the NMLCD-T334TOS data sheet it indicates the drive chip ST7796SI

320RGB x 480 dot 262K Color with Frame Memory Single-Chip TFT Controller/Driver

which has 1778 pins... (for such a little display...)

but no mention of an Radius/Angle process where 0,0 would be centered.

[Carl Farrington]

Posted on July 16, 2018 at 04:43

Yes that's right for this screen. But in the original st example code, which is for the G1120TB103GF-001 amoled screen, the centre-text function seemed to give an xPos of 0. The function seems to put the centre of the string at this location, so that it's centres the whole string on screen. With that xPos of 0, everything was actually at 0 as you would expect.. and not centered on the screen at all. So I changed the funtion to say if xPos == 0 { xPos = screenwidh/2) and now it's correct and all good!

Just wondering how it was ok on the original amoled screen with xPos = 0