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 15, 2018 at 05:06

When I speak of having to manually enter the LUT table, I am referring to the docs which guide you through CubeMX.

Apart from the 'Excel Import' option, which so far I have no idea of the import format i.e. required fields, headers, etc, well apart from that it looks like I have to enter a start and end pixel for each row. That's the guidance from ST. I'm pleased to hear that you say we should just use a program (excel macro for amateurs, or python for smart people), but that's not how STCubeMX wants to do it. It wants me to re-input 320*320 boxes of data that I haven't been given by my LCD supplier. Also, I'm being pedantic here, but it doesn't overwrite when you tab to the next box. It should.

http://www.internetsomething.com/lcd/pcb/lutinput.png

[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..

[Carl Farrington]

Posted on July 16, 2018 at 01:02

I've been studying what you wrote.. (ignoring the sine over PI radians business for now as it will require too much brainpower), and I just couldn't get why you were saying 320/8, and talking about the first 80 lines etc. Now I realise that was for the octagon! Thanks very much, makes perfect sense.

In the meantime, I realised that the LUT isn't critical. I'm just wasting memory if it's too big/wide, but it will still work and will correct my problem with the circle being offset due to an incorrect LUT from the discovery example code. So I've been experimenting and it's close.

I decided to put the LCD under the microscope and take photos and try to count the increments from row to row. The middle 32 rows are the same width for example. I ended up with some notes like: 

from centre upwards:

16 rows are full widthnext 8 are +/-1 px next 6 are +/-1 px againnext 5 are +/-1px againnext 4 are +/-1px againnext 4 are +/-1px againnext 4 are +/-1px againnext 4 are +/-1px againnext 3 are +/-1px againnext 3 are +/-1px againnext 3 are +/-1px againnext 2 are +/-1px again

Anyway, it's better but still not right.

Now that I understand what you said about the octagon, I'm going to do exactly that!

I used the Excel import option into CubeMX by the way - it works really well. Just needs 320 rows of start and end pixels - no headers or anything else.

[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

[SSG]

Hi @Tesla DeLorean,

I am using a 454x454 round display and not getting any help from seller. Unfortunately, I could not get your point about "For a circle zero thru 319, use sine over PI radians". Can you please help me? Thanks.