Critique my first PCB

[carl0s]

Hi. I'm looking for opinions or advice on my PCB layout.

It's simply an adapter for the STM32L4R9I-DISCOVERY board to allow me to use a large round Panasys MIPI LCD display. It is to go in place of the supplied MB1314 AMOLED smartwatch daughterboard.

So it has a backlight LED driver, basically following the datasheet circuit diagram, and then just tracks between the connectors. Both clock and DSI are high speed differentials. Annoyingly the P/N of the differential pairs always seemed to need to cross over each other! On the big connector they are side by side, but as the LCD panel's connector is double row, they are opposite each other instead!

Things I thought about:

• I could have made use of the bottom layer for more than just one big ground fill. That could have made it much easier to route the tracks. I was trying to keep it simple though and wasn't sure if that was a good or bad idea.
• Number of vias to the ground layer.. too many? not enough?

I suppose once I have one in my hand I will have a better idea of size and where I could have gone bigger or smaller. I will do a print out as well.

I started with the ST schematics, just so I could get the big Samtec connector. That's why it still has their logo on it, and is named 'copy of mb1314' :-)

Here's a PDF: http://www.internetsomething.com/lcd/pcb/PDF.pdf
The rest (gerbers etc) can be downloaded from this directory: http://www.internetsomething.com/lcd/pcb/

and here's 3D pictures:






Any obvious total fails? Other suggestions?

[ataradov]

1. It is probably better to have some of the traces go on the bottom layer rather than have them snake around between the pins of the connector like this.
2. Purely aesthetic: I'd use only 45 degree traces.
3. Pour solid ground on the top layer as well. And more ground stitching can't hurt. Especially close to those ground pins next to the differential lines

[carl0s]

1. It is probably better to have some of the traces go on the bottom layer rather than have them snake around between the pins of the connector like this.
2. Purely aesthetic: I'd use only 45 degree traces.
3. Pour solid ground on the top layer as well. And more ground stitching can't hurt. Especially close to those ground pins next to the differential lines

Thanks. I have to admit, it was a lot harder than I expected. I started along merrily and then one track would be unroutable and I'd have to un-do it all and move components. One minute the LCD socket was below and the next it was above. Turning the backlight driver chip around multiple times, etc.

I suppose I just thought that routing on both layers would be too much for me to try to deal with for my first time. Plus I was battling with not knowing how to use the program (Altium) that I borrowed. I think I might want to look at KiCad or Allegro as I have found a few things frustrating (length tuning being awkward, moving objects with tracks connected, erm, highlighted/unhighlighted toggle not actually reflecting what's on screen.. ).

[ataradov]

Sometimes it is easier to go back and redo the whole board with your new knowledge after you've struggled though the first one.

I would try to route all differential signals on one layer and actually keep the traces parallel for as long as possible. Then route remaining pins that can be routed cleanly on one side. A then move the rest on the other side. Right now there is not a whole lot of point in your length matching, for example.

[carl0s]

Sometimes it is easier to go back and redo the whole board with your new knowledge after you've struggled though the first one.

I would try to route all differential signals on one layer and actually keep the traces parallel for as long as possible. Then route remaining pins that can be routed cleanly on one side. A then move the rest on the other side. Right now there is not a whole lot of point in your length matching, for example.

Hmm but the differential pairs are side by side on one connector, and top and bottom on the other. Unless I was to put the smaller LCD connector on sideways?

How come there's not much point to the length matching? Is it not about time delay?

[ataradov]

Nevermind, I thought there was much more going on with them. What you have is fine. Well the trace on the right can be made a bit more parallel to the other pair, but really on that distance it is all cosmetic and won't make much difference in real life.

[carl0s]

Nevermind, I thought there was much more going on with them. What you have is fine. Well the trace on the right can be made a bit more parallel to the other pair, but really on that distance it is all cosmetic and won't make much difference in real life.

Yes I was just thinking about how that could be pulled in and kept parallel. No need for the odd shape.

Thanks for your help!

[carl0s]

I made it more parallel:







Altium is really annoying with that length tuning. For example it wouldn't move that extension piece higher. It will only allow it where it is - beneath the connector outline silkscreen.
It's like it refuses to go anywhere near corners or something.

[ataradov]

Add the ground pour on the top layer. And add more vias to connect the two. That's probably the best thing you can do on this board for signal integrity.

[carl0s]

Add the ground pour on the top layer. And add more vias to connect the two. That's probably the best thing you can do on this board for signal integrity.

OK I shall have a go! Thanks.

[carl0s]

Right, I have had a go!

I had the clearance rules turned off before because.. well because I didn't know better. I didn't realise they actually directed things like polygon pour to clear themselves around tracks. I thought they were just there to nag you about things!

So I have done it, and.. well two things. Firstly, it's left a stray bit of copper, and as it's part of the overall polygon i don't know how to remove it. Just ignore it? I suppose it looks nice.. adds balance.

Secondly, the clearance rules have highlighted to me that those tracks coming in beween the pads, are 3.89mils next to the connector pads. Do you think this is too close for el-cheapo PCB manufacturers? Please say it'll be fine..

(I know, I need to put in some more vias)

[ataradov]

The polygon part is fine. But the typical cheap PCB manufacturers offer 5/5 or 6/6 mil track/clearance. I typically route everything using 10 mil tracks and spaces when possible. So you will have to rethink your layout.

[carl0s]

Currently looking like this:

[carl0s]

The polygon part is fine. But the typical cheap PCB manufacturers offer 5/5 or 6/6 mil track/clearance. I typically route everything using 10 mil tracks and spaces when possible. So you will have to rethink your layout.

Alright.. Well, when I read that, I thought, bugger.. nightmare. Re-think. But, now that I know that the polygon pour is smart and will leave clearances around other nets, I think I'm comfortable with adding in vias and signal tracks on the bottom layer, instead of going between pins, and then re-pouring the bottom ground layer.

I'm going to have a go after my tea

Thanks!

[ocset]

here is my PCB layotu guide attached.

Also, Dave Jones guide to PCB layout
http://alternatezone.com/electronics/files/PCBDesignTutorialRevA.pdf

Thats Dave Jones who runs this site

[carl0s]

I was reading Dave's 2004 PDF the other night!!

Anyway, here is my latest revision. Better. I made the drill holes 12mil too. They were 10mil before.

[ANTALIFE]

My first though is that it looks like you have a switching DCDC converter, not sure of the current/power requirements but if it was me I would try connect each component that is part of the power path with a thicker track or a plane like this:

[carl0s]

My first though is that it looks like you have a switching DCDC converter, not sure of the current/power requirements but if it was me I would try connect each component that is part of the power path with a thicker track or a plane like this:

Yes I thought that might come up. I'm just not quite sure how to do it in Altium other than by literally drawing the polygons, and I can see them ending up rather ugly :-)
I might have a go though.

It's an AP5724 DC to DC converter. http://www.internetsomething.com/lcd/AP5724%20backlight%20driver.pdf

There's 6 LEDs in series, at 20mA, 18v total, so 360mw total. They say the above driver chip is 84% efficient, so expected draw of 430mw. Call it 500mw. I'm not really sure I know enough about this stuff, but I gather it's current that matters. So the 500mw should pull 151mA from the 3.3v supply. I've used 10 mil traces which an online calculator says should be good for 450mA with 1oz copper. The LCD panel itself pulls 15mA. So I'm at about 165mA.

What do you think? I suppose it makes sense for me to learn how to do the job properly though doesn't it..

[carl0s]

I've just tidied up some stray ground tracks for now, from before I did the ground fill on the top layer

[David Chamberlain]

What happened to the fill on the bottom?

[carl0s]

My first though is that it looks like you have a switching DCDC converter, not sure of the current/power requirements but if it was me I would try connect each component that is part of the power path with a thicker track or a plane like this:

All right, I have had a go! I have beefed up a lot of the tracks as well:

[carl0s]

What happened to the fill on the bottom?

It's still there isn't it? I just didn't have it highlighted it in the image so it was under the soldermask.

[carl0s]

[ANTALIFE]

My first though is that it looks like you have a switching DCDC converter, not sure of the current/power requirements but if it was me I would try connect each component that is part of the power path with a thicker track or a plane like this:

Yes I thought that might come up. I'm just not quite sure how to do it in Altium other than by literally drawing the polygons, and I can see them ending up rather ugly :-)
I might have a go though.

It's an AP5724 DC to DC converter. http://www.internetsomething.com/lcd/AP5724%20backlight%20driver.pdf

There's 6 LEDs in series, at 20mA, 18v total, so 360mw total. They say the above driver chip is 84% efficient, so expected draw of 430mw. Call it 500mw. I'm not really sure I know enough about this stuff, but I gather it's current that matters. So the 500mw should pull 151mA from the 3.3v supply. I've used 10 mil traces which an online calculator says should be good for 450mA with 1oz copper. The LCD panel itself pulls 15mA. So I'm at about 165mA.

What do you think? I suppose it makes sense for me to learn how to do the job properly though doesn't it..

The way I see it if the LED's expect to consume 360mW and the converter is 84% efficient then this means 70mW will be dissipated as heat in the SOT23-6 package. Given that θJA is 162°C/W this means that IC will rise by ~11°C above ambient. Not that bad but for the sake of it I would still use a polygon to help dissipate the heat, and give the current a much less resistance pathway (lower ohmic loss, not that it matters that much with your current draw).

As for polygons you can either manually place them down and adjust as you go like:
Or you could use another layer (like MECH 1) to define the shape and then create a polygon on copper layer, like (Create Polygon from Selected Primitives): https://www.altium.com/documentation/15.1/display/ADES/PCB_Cmd-ConvertSelected((ConvertSelected))_AD

Also I think your latest iteration with polygons looks better, but there is still room for improvement. To get an idea of a good layout have a look at the appnote:
https://www.diodes.com/diodes-part-files/AC/AP5724/User%20Guides%20and%20EV%20Boards/AP5724-EVM.pdf
Notice how all components part of the power path (inductor, diode, filter caps, IC...) are all connected via a large polygon

[Dave]

The current paths in that SMPS look unnecessarily long. You want the high currents to have short, uninterrupted current paths from the input capacitors to the output capacitors.
You could improve this by rotating the inductor by 90° clockwise and move those input capacitors closer to the output caps. Also, fatten the traces up around the diode.

[carl0s]

My first though is that it looks like you have a switching DCDC converter, not sure of the current/power requirements but if it was me I would try connect each component that is part of the power path with a thicker track or a plane like this:

Yes I thought that might come up. I'm just not quite sure how to do it in Altium other than by literally drawing the polygons, and I can see them ending up rather ugly :-)
I might have a go though.

It's an AP5724 DC to DC converter. http://www.internetsomething.com/lcd/AP5724%20backlight%20driver.pdf

There's 6 LEDs in series, at 20mA, 18v total, so 360mw total. They say the above driver chip is 84% efficient, so expected draw of 430mw. Call it 500mw. I'm not really sure I know enough about this stuff, but I gather it's current that matters. So the 500mw should pull 151mA from the 3.3v supply. I've used 10 mil traces which an online calculator says should be good for 450mA with 1oz copper. The LCD panel itself pulls 15mA. So I'm at about 165mA.

What do you think? I suppose it makes sense for me to learn how to do the job properly though doesn't it..

The way I see it if the LED's expect to consume 360mW and the converter is 84% efficient then this means 70mW will be dissipated as heat in the SOT23-6 package. Given that θJA is 162°C/W this means that IC will rise by ~11°C above ambient. Not that bad but for the sake of it I would still use a polygon to help dissipate the heat, and give the current a much less resistance pathway (lower ohmic loss, not that it matters that much with your current draw).

As for polygons you can either manually place them down and adjust as you go like:
Or you could use another layer (like MECH 1) to define the shape and then create a polygon on copper layer, like (Create Polygon from Selected Primitives): https://www.altium.com/documentation/15.1/display/ADES/PCB_Cmd-ConvertSelected((ConvertSelected))_AD

Also I think your latest iteration with polygons looks better, but there is still room for improvement. To get an idea of a good layout have a look at the appnote:
https://www.diodes.com/diodes-part-files/AC/AP5724/User%20Guides%20and%20EV%20Boards/AP5724-EVM.pdf
Notice how all components part of the power path (inductor, diode, filter caps, IC...) are all connected via a large polygon

Thank you. I didn't think of dissipating heat with pads/polygon.

The reason my +3.3v polygon doesn't continue through the diode is because the LED driver datasheet specifically says to minimise trace width here.

However, I may be misunderstanding. Perhaps it's just the trace from the diode to the IC that needs to be minimised, and maybe I should still have a fat trace (polygon) from the inductor to the diode.. but then.. isn't the effect the same?

[carl0s]

The current paths in that SMPS look unnecessarily long. You want the high currents to have short, uninterrupted current paths from the input capacitors to the output capacitors.
You could improve this by rotating the inductor by 90° clockwise and move those input capacitors closer to the output caps. Also, fatten the traces up around the diode.

I'm not clear on how to do that :-/

What about moving output capacitor C4 up top by the LCD socket? Would that be an improvement?

[ANTALIFE]

I think they mean trace area going into SW pin, if you have a look at reference design they still have a wide traces for all components it's only when they funnel into the IC that they become smaller (design constraint of pin positions).

Also Dave made a good point. Think of a transient happening on the Vout and suddenly you must supply additional current to get the voltage back up, how you have C4 positioned makes it harder for the circuit to respond faster.

[carl0s]

I think they mean trace area going into SW pin, if you have a look at reference design they still have a wide traces for all components it's only when they funnel into the IC that they become smaller (design constraint of pin positions).

Also Dave made a good point. Think of a transient happening on the Vout and suddenly you must supply additional current to get the voltage back up, how you have C4 positioned makes it harder for the circuit to respond faster.

I hear ya. I did think that C4 might need moving closer to the LED backlight. I just wasn't sure about moving the other caps or re-orienting the inductor... too much brain power required at this stage!

The whole thing is super tiny mind you - if that makes a difference. In fact I forgot how small it was, and I have just spent ages lengthening the pads on the small LCD connector at the top so that I have a better chance of soldering it.



Here's the latest iteration/changes then.. Hopefully it'll do the job. I forgot to re-apply teardrops, but I'll do that later.

[carl0s]

Any better? : C4 only has that one 12mil via to ground. Do you think that's a problem? I suppose I could simply make it a bigger via. Otherwise, if it matters, I'd have to look to get the ground pour to reach around.

[carl0s]

nevermind, I have sorted that ground pour for C4

[carl0s]

I've got an important question.

C1 (100nf) and C3 (1uF) are in parallel, right next to each other.
This is because the original schematic had C1 on the power into the board, and then the datasheet schematic for the backlight driver had C3 (1uF) in it.

Should I ditch one of them? Obviously this elementary question will highlight my naivety and lack of knowledge on basic electronics :-/

I have beefed all the caps up to 0805s, for ease of placement, and availability on the higher voltage side (~18 - 20v).

[BrianHG]

If J1 is a single sided flex cable connector, the pins where you length equalize extended the traces may travel into the connector to the flex cable with a little more length inside the connector compared to the pins right under the connector.  Have you taken this into account when extending those 2 traces to their length on the PCB?

[carl0s]

If J1 is a single sided flex cable connector, the pins where you length equalize extended the traces may travel into the connector to the flex cable with a little more length inside the connector compared to the pins right under the connector.  Have you taken this into account when extending those 2 traces to their length on the PCB?

Hi. Do you mean that they may have already compensated for the connector pin separation in the flex cable?

[carl0s]

boards have come out looking reasonable, and the pads line up too

I'll report back if they actually work, once I've finished my reflow oven.

[carl0s]

So it turns out I had the LCD pinouts back to front

My first attempt at reflow soldering went well. Little bit too much paste - bridge on a pin that didn't matter.

but the LCD backlight driver didn't work. Progress was hampered by the fact that I've only ever done Arduino. Between Keil and TrueStudio, I had a hard time getting the discovery board example programs to compile. I needed them to compile so that I could add in an 'HAL_GPIOB pin1 enable' thingy.. i.e. turn on the LCD backlight, since the examples are all meant for the amoled screen with no backlight.

I did some playing. In fact I burned out one of my LCD flat flex by sticking a li-po on it and getting the polarity back to front. I guess this is why I need a current limiting power supply. DP711 or DP832 though.. ? DP832 is more money but crucially its kind of huge

Anyway then I constructed a better test.. 5 plain LEDs wired in series on some breadboard, to be driven by my little circuit. and it worked! 3.3v in, drives 5x LEDs nicely.

Then I looked closely at the LCD datasheet for the FFC pinouts and it looks like I had it the wrong way up. Well, what I mean is that I assumed the FPC to be going in the connector at top-contact rather than bottom contact. So pins 1-17 should be pins 17-1 instead. Left to right-flip.

I don't think this is fixable. So I have 49 keychain PCBs

In all honesty, it quickly became apparent that I have made myself a PCB here that's very difficult to debug (since it's face down when fitted to the ST Discovery board). Perhaps I'll spend a bit more time on rev 2 and put some test points, as well as maybe more than one type of LCD connector.

[carl0s]

Checking over my designs and I can see why it's happened. I used Molex 504281-1700 in the design, which has contacts on both top and bottom. I have 5 of these connectors. I actually fitted a flip-connector though (Amp 10061122-171120HLF), which seemed to grip the FPC better, and was dirt cheap. These are bottom contact only. So it might be Ok after all if I use the other connector

[CopperCone]

Did you protect your I/O? I did not look at it but there might be special things you need to do if that chip is the first thing in the circuit connected by a wire.

And how is that board being mounted mechanically? I don't see any screw holes. I assume it clips into a assembly some how? Keeping it stationary is important.

[carl0s]

Hi. The Samtec DSI connector makes a tight fit!

I'm just reflowing a second attempt now. I had some 17-way 0.3mm top contact flip connectors.. unknown brand from Aliexpress. Just trying again with one of those

I only have one more of these LCD panels left though

[carl0s]

Sweet. It works!

There were a couple of solder bridges there which were on unused pins, but I've wicked them out now anyway.

Just need to figure out what needs changing in the LCD driver code now !

This is a marked improvement from a couple of hours ago where I thought I'd designed the pin outs back to front and would have to re-do the design!

[carl0s]

Well, something's happening. The thing is, I can't make sense of all the DSI init commands in the example code. I just don't know how the sequence works. Having spent about an hour reading data sheets and still not really understanding, I removed a load of the init commands (which aren't meant for this screen), and I got this:




then I removed some more, and now I have this

[carl0s]

Now I have added in a command, and it works as per the data sheet. Yay. MADCTL, x-mirror, etc.

[carl0s]

So close now.

I think all that's wrong is the GFXMMU thing that basically manages memory (framebuffer) usage for circular displays. It chops off bits or something. I dunno. Well anyway it all looks good so maybe I should move onto the StEmWin stuff.

[lukewren]

I realise you now have your boards back (and they work! awesome!  ) so it's probably a bit too late, but... why do you have thermal relief on your stitching vias?

[carl0s]

I realise you now have your boards back (and they work! awesome!  ) so it's probably a bit too late, but... why do you have thermal relief on your stitching vias?

What's that then??

Is that something to do with the vias looking like a cross-hair? (I have no idea why that is.. Altium just did that).

[carl0s]

Another weird thing is that R1 footprint.

It's a metric 1608 (should be same as an 0603) from the Cern Altium library. The footprint looked like an odd size in the end though and I've actually put an 0805 resistor on there. I've done two of the boards now and it seems to fit OK. All the caps are 0805 anyway. Sort of figured there might be less chance of tombstoning with bigger bits / more paste etc.

[james_s]

That has worked out remarkably well for a first PCB. In the future I would suggest using thicker traces in the switching regulator area, and keeping everything as short as possible there but it seems it has worked out ok in this case.

[carl0s]

That has worked out remarkably well for a first PCB. In the future I would suggest using thicker traces in the switching regulator area, and keeping everything as short as possible there but it seems it has worked out ok in this case.

Thanks for the tips. Yes I'm pleased! I did burn up one of my LCDs mind you. Thankfully just as $25 one.

I really do need to get a current limiting PSU that doesn't take up half a desk.. I might look at those modules that Dave reviewed some time ago. Those all over eBay.

[carl0s]

Last pic, cos I'm super chuffed

[james_s]

That looks really good, it's always very exciting when a complex display like that actually works. That would make an interesting analog style desk clock or weather station, I've always been fond of analog dials.

[bitseeker]

I realise you now have your boards back (and they work! awesome!  ) so it's probably a bit too late, but... why do you have thermal relief on your stitching vias?

What's that then??

Is that something to do with the vias looking like a cross-hair? (I have no idea why that is.. Altium just did that).

Nice job with that board, Carl. It was cool seeing it improve as the thread progressed.

I, too, was wondering about the thermal relief on the vias. Yes, it's those crosshair-looking structures. They reduce the rate at which heat flows from the pad to the ground plane so that it's easier to heat the pad for soldering. Normally, you'd do that where you have to solder through-hole parts, otherwise a soldering iron might struggle. Since these are vias, they're not needed.

I haven't used Altium, but there must be an option to turn off the thermal relief or perhaps choose a different part for vias vs. plated through holes for leads. Of course, it won't affect anything the way it is since those are simply vias. It just looks odd. Something to figure out for the next PCB.

[carl0s]

I realise you now have your boards back (and they work! awesome!  ) so it's probably a bit too late, but... why do you have thermal relief on your stitching vias?

What's that then??

Is that something to do with the vias looking like a cross-hair? (I have no idea why that is.. Altium just did that).

Nice job with that board, Carlos. It was cool seeing it improve as the thread progressed.

I, too, was wondering about the thermal relief on the vias. Yes, it's those crosshair-looking structures. They reduce the rate at which heat flows from the pad to the ground plane so that it's easier to heat the pad for soldering. Normally, you'd do that where you have to solder through-hole parts, otherwise a soldering iron might struggle. Since these are vias, they're not needed.

I haven't used Altium, but there must be an option to turn off the thermal relief or perhaps choose a different part for vias vs. plated through holes for leads. Of course, it won't affect anything the way it is since those are simply vias. It just looks odd. Something to figure out for the next PCB.

Thanks! Yes I googled thermal relief vias and found some pictures in the end. I'll watch out for it next time.

[carl0s]

That looks really good, it's always very exciting when a complex display like that actually works. That would make an interesting analog style desk clock or weather station, I've always been fond of analog dials.

It sure is an interesting screen. It's quite bright (650 nits), and doesn't have a touch screen. Meant for industrial/scientific. Will do nicely for some kind of automotive gauge I think. It is part of my foray into MIPI DSI screens on microcontrollers. There aren't many MCUs that do MIPI DSI, but the STM32L4+ does - it does up to 2 lane MIPI DSI. This screen only needs 1 lane. I think the interesting thing is (although I know nothing about non-MIPI screens...) that the command set is somewhat standardised. So it should be pretty easy to get different screens going. Famous last words..

My next project, is to try to get this much bigger round TFT to work. This is a proper ~3.4" TFT. You can see it's a lot bigger than the octagonal one that I have had success with - that one is also sold as 3.34", but it's really about 2.4". It was possibly cut from a 3.34" square once upon a time though. This bigger one requires 3 MIPI lanes, and no MCU supports that, so part of the project will involve getting the SSD2828 RGB to MIPI bridge chip working. That's the QFN68 chip that you can see on the proto-board there. This big one is gram-less i.e. has no internal graphics memory/framebuffer, and I don't know enough about these things yet to know how much harder that will make things, but it'll be interesting having a go! The dev board I have, and the ST discovery board, all have decent amounts of SDRAM or PSRAM etc which I think can be used as the framebuffer, and they both have LTDC (LCD TFT Display Controller) which handles a lot of the work for you as far as I know.

Oh yeah that's what I meant to say.. this big round one is 800*800px !! It really does look like a beauty, but, the brightness according to the datasheet is only 350 nits, and this has sort of put it on the back burner for me, also the complexity of my first project of course.. I have started with the simpler 1-lane MIPI.

[dlo]

Nice work Carl! I'm trying to do something similar with a smaller 2.1" DSI LCD using the ST7796H2 controller. Can you share what files you edited to make yours work? Thanks!

[luiHS]

 
Hi carl0s.

I will use the same octagonal screen, for now the only thing I know is that it uses the ST7796SI controller, I have no experience with MIPI DSI screens.

From what I understand, it is necessary to send some commands to initialize it. In my case I will use an STM32F769 microcontroller, because it has hardware JPEG decoding, I will test it with a Discovery evaluation board. I have also made my adapter board (pictures attached), to connect it to the Discovery, this includes a voltage booster (18v) for the backlight.

Could you share the modifications you made to the source, to initialize this screen? As you indicated, you removed all the initialization commands from the kit, and with that it started working, but you added a command to make it work perfectly.

Regards

[luiHS]

 
 
Also attached, a technical documentation, which was sent to me by the seller of the screen, on the list of commands on the screen. I don't know if they are standard DCS commands, or each screen needs its own list of MCS commands.

 

[carl0s]

Hi!

I will try to get time this weekend to find what I modified and post it on here.

I made some more of the LCD adapter boards last night, and I also now have the stm32f769ni discovery board, for which I'd also like to make the big round screen work. There was a reason why I bought that disco kit but I can't for the life of me remember it.. I think I just wanted to have a further play with TouchGFX designer.

[luiHS]

 

Okay thanks.
The good feature of the STM32F769 is that it integrates hardware JPEG decoding, so you can see any JPEG image instantly, or play MJPEG video very smoothly and with a good resolution for these small screens.

In the Cube, there is a complete video player source for the EVAL board, and one to display JPEG images for the Discovery. Considering that both boards use the same microncontroller, I hope to use the source of the EVAL video player on Discovery, my only question is about the initialization sequence of the screen.

I have the documentation that I have put before, on the commands that the screen controller accepts, as soon as I can I will try everything. I also have other round screens, some of the vendor gives documentation, others only a very basic datasheet that does not give any information about DCS or MCS commands.

Waiting, with great interest, for the list of commands you used to make your screen work, is the same one I want to use.

[carl0s]

Okay thanks.
The good feature of the STM32F769 is that it integrates hardware JPEG decoding, so you can see any JPEG image instantly, or play MJPEG video very smoothly and with a good resolution for these small screens.

In the Cube, there is a complete video player source for the EVAL board, and one to display JPEG images for the Discovery. Considering that both boards use the same microncontroller, I hope to use the source of the EVAL video player on Discovery, my only question is about the initialization sequence of the screen.

I have the documentation that I have put before, on the commands that the screen controller accepts, as soon as I can I will try everything. I also have other round screens, some of the vendor gives documentation, others only a very basic datasheet that does not give any information about DCS or MCS commands.

Waiting, with great interest, for the list of commands you used to make your screen work, is the same one I want to use.

I'm off to the supermarket to get some cold coca cola, then I'm going to dig through my project to find what I changed. Then I'll try the same stuff on the STM32F769 Disco board that I have here.

[carl0s]

You will be surprised. It looks like, apart from one command, I simply removed all the rest.

I was working with the BSP Example / Demo. I.e. the board support package demo - that's what you can see in my photos before, with the ST logo etc.

The original LCD Power on sequence in /STM32Cube_FW_L4_v1.12.0/Drivers/BSP/STM32L4R9I-Discovery/stm32l4r9i_discovery_lcd.c (for the included GVO 1.2" 390*390 AMOLED smartwatch-screen) looked like this:

Code: [Select]

/*************************/
    /* LCD POWER ON SEQUENCE */
    /*************************/
    /* Step 1 */
    /* Go to command 2 */
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0xFE, 0x01);
    /* IC Frame rate control, set power, sw mapping, mux swithc timing command */
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x06, 0x62);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x0E, 0x80);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x0F, 0x80);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x10, 0x71);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x13, 0x81);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x14, 0x81);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x15, 0x82);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x16, 0x82);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x18, 0x88);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x19, 0x55);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x1A, 0x10);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x1C, 0x99);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x1D, 0x03);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x1E, 0x03);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x1F, 0x03);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x20, 0x03);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x25, 0x03);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x26, 0x8D);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x2A, 0x03);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x2B, 0x8D);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x36, 0x00);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x37, 0x10);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x3A, 0x00);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x3B, 0x00);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x3D, 0x20);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x3F, 0x3A);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x40, 0x30);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x41, 0x1A);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x42, 0x33);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x43, 0x22);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x44, 0x11);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x45, 0x66);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x46, 0x55);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x47, 0x44);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x4C, 0x33);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x4D, 0x22);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x4E, 0x11);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x4F, 0x66);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x50, 0x55);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x51, 0x44);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x57, 0x33);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x6B, 0x1B);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x70, 0x55);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x74, 0x0C);

    /* Go to command 3 */
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0xFE, 0x02);
    /* Set the VGMP/VGSP coltage control */
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x9B, 0x40);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x9C, 0x00);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x9D, 0x20);

    /* Go to command 4 */
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0xFE, 0x03);
    /* Set the VGMP/VGSP coltage control */
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x9B, 0x40);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x9C, 0x00);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x9D, 0x20);


    /* Go to command 5 */
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0xFE, 0x04);
    /* VSR command */
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x5D, 0x10);
    /* VSR1 timing set */
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x00, 0x8D);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x01, 0x00);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x02, 0x01);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x03, 0x01);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x04, 0x10);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x05, 0x01);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x06, 0xA7);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x07, 0x20);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x08, 0x00);
    /* VSR2 timing set */
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x09, 0xC2);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x0A, 0x00);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x0B, 0x02);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x0C, 0x01);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x0D, 0x40);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x0E, 0x06);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x0F, 0x01);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x10, 0xA7);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x11, 0x00);
    /* VSR3 timing set */
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x12, 0xC2);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x13, 0x00);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x14, 0x02);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x15, 0x01);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x16, 0x40);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x17, 0x07);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x18, 0x01);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x19, 0xA7);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x1A, 0x00);
    /* VSR4 timing set */
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x1B, 0x82);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x1C, 0x00);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x1D, 0xFF);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x1E, 0x05);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x1F, 0x60);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x20, 0x02);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x21, 0x01);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x22, 0x7C);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x23, 0x00);
    /* VSR5 timing set */
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x24, 0xC2);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x25, 0x00);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x26, 0x04);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x27, 0x02);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x28, 0x70);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x29, 0x05);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x2A, 0x74);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x2B, 0x8D);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x2D, 0x00);
    /* VSR6 timing set */
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x2F, 0xC2);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x30, 0x00);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x31, 0x04);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x32, 0x02);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x33, 0x70);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x34, 0x07);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x35, 0x74);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x36, 0x8D);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x37, 0x00);
    /* VSR marping command */
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x5E, 0x20);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x5F, 0x31);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x60, 0x54);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x61, 0x76);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x62, 0x98);

    /* Go to command 6 */
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0xFE, 0x05);
    /* Set the ELVSS voltage */
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x05, 0x17);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x2A, 0x04);
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x91, 0x00);

    /* Go back in standard commands */
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0xFE, 0x00);

    /* Set tear off */
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, DSI_SET_TEAR_OFF, 0x0);

    /* Set DSI mode to internal timing added vs ORIGINAL for Command mode */
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0xC2, 0x0);

    /* Set memory address MODIFIED vs ORIGINAL */
    uint8_t InitParam1[4]= {0x00, 0x04, 0x01, 0x89}; // MODIF OFe: adjusted w/ real image
    HAL_DSI_LongWrite(&hdsi_discovery, 0, DSI_DCS_LONG_PKT_WRITE, 4, DSI_SET_COLUMN_ADDRESS, InitParam1);
    uint8_t InitParam2[4]= {0x00, 0x00, 0x01, 0x85};
    HAL_DSI_LongWrite(&hdsi_discovery, 0, DSI_DCS_LONG_PKT_WRITE, 4, DSI_SET_PAGE_ADDRESS, InitParam2);

    /* Sleep out */
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P0, DSI_EXIT_SLEEP_MODE, 0x0);

    HAL_Delay(120);


My changed version of that sequence looks like this :

Code: [Select]

    /*************************/
    /* LCD POWER ON SEQUENCE */
    /*************************/


// very minimal init code for panasys round octagonal tft
// this is 0x36 for MADCTL, with parameter 0x48 for xmirror, top left to bottom-right, bgr
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x36, 0x48);
    //HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x3A, 0x55);



    /* Sleep out */
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P0, DSI_EXIT_SLEEP_MODE, 0x0);

    HAL_Delay(120);


Essentially I replaced all the LCD init code with a simple MATCTL 0x48 (that is cmd 0x36, data 0x48).

I created a rough GFXMMU_LUT, but this is just to save memory by, erm, not allocating the bits of pixel space that would be outside of the circle. I think you can work without it..

Code: [Select]

/**
  ******************************************************************************
  * File Name          : gfxmmu_lut.h
  * Description        : header file for GFX MMU Configuration Table
  ******************************************************************************
  ** This notice applies to any and all portions of this file
  * that are not between comment pairs USER CODE BEGIN and
  * USER CODE END. Other portions of this file, whether
  * inserted by the user or by software development tools
  * are owned by their respective copyright owners.
  *
  * COPYRIGHT(c) 2018 STMicroelectronics
  *
  * Redistribution and use in source and binary forms, with or without modification,
  * are permitted provided that the following conditions are met:
  *   1. Redistributions of source code must retain the above copyright notice,
  *      this list of conditions and the following disclaimer.
  *   2. Redistributions in binary form must reproduce the above copyright notice,
  *      this list of conditions and the following disclaimer in the documentation
  *      and/or other materials provided with the distribution.
  *   3. Neither the name of STMicroelectronics nor the names of its contributors
  *      may be used to endorse or promote products derived from this software
  *      without specific prior written permission.
  *
  * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
  * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
  * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
  * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
  * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
  * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
  * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
  * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
  * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
  * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  *
  ******************************************************************************
  */
/* Define to prevent recursive inclusion -------------------------------------*/
#ifndef __gfxmmu_lut_H
#define __gfxmmu_lut_H
#ifdef __cplusplus
 extern "C" {
#endif
// GFX MMU Configuration Table

  #define GFXMMU_FB_SIZE 359680
  #define GFXMMU_LUT_FIRST 0
  #define GFXMMU_LUT_LAST  319
  #define GFXMMU_LUT_SIZE 320

uint32_t gfxmmu_lut_config_argb8888[2*GFXMMU_LUT_SIZE] = {
  0x003B1401, //GFXMMU_LUT0L
  0x003FFEC0, //GFXMMU_LUT0H
  0x003C1301, //GFXMMU_LUT1L
  0x00000150, //GFXMMU_LUT1H
  0x003C1301, //GFXMMU_LUT2L
  0x000003F0, //GFXMMU_LUT2H
  0x003C1301, //GFXMMU_LUT3L
  0x00000690, //GFXMMU_LUT3H
  0x003C1301, //GFXMMU_LUT4L
  0x00000930, //GFXMMU_LUT4H
  0x003D1201, //GFXMMU_LUT5L
  0x00000BE0, //GFXMMU_LUT5H
  0x003D1201, //GFXMMU_LUT6L
  0x00000EA0, //GFXMMU_LUT6H
  0x003D1201, //GFXMMU_LUT7L
  0x00001160, //GFXMMU_LUT7H
  0x003D1201, //GFXMMU_LUT8L
  0x00001420, //GFXMMU_LUT8H
  0x003E1101, //GFXMMU_LUT9L
  0x000016F0, //GFXMMU_LUT9H
  0x003E1101, //GFXMMU_LUT10L
  0x000019D0, //GFXMMU_LUT10H
  0x003E1101, //GFXMMU_LUT11L
  0x00001CB0, //GFXMMU_LUT11H
  0x003E1101, //GFXMMU_LUT12L
  0x00001F90, //GFXMMU_LUT12H
  0x003F1001, //GFXMMU_LUT13L
  0x00002280, //GFXMMU_LUT13H
  0x003F1001, //GFXMMU_LUT14L
  0x00002580, //GFXMMU_LUT14H
  0x003F1001, //GFXMMU_LUT15L
  0x00002880, //GFXMMU_LUT15H
  0x003F1001, //GFXMMU_LUT16L
  0x00002B80, //GFXMMU_LUT16H
  0x00400F01, //GFXMMU_LUT17L
  0x00002E90, //GFXMMU_LUT17H
  0x00400F01, //GFXMMU_LUT18L
  0x000031B0, //GFXMMU_LUT18H
  0x00400F01, //GFXMMU_LUT19L
  0x000034D0, //GFXMMU_LUT19H
  0x00400F01, //GFXMMU_LUT20L
  0x000037F0, //GFXMMU_LUT20H
  0x00410E01, //GFXMMU_LUT21L
  0x00003B20, //GFXMMU_LUT21H
  0x00410E01, //GFXMMU_LUT22L
  0x00003E60, //GFXMMU_LUT22H
  0x00410E01, //GFXMMU_LUT23L
  0x000041A0, //GFXMMU_LUT23H
  0x00410E01, //GFXMMU_LUT24L
  0x000044E0, //GFXMMU_LUT24H
  0x00420D01, //GFXMMU_LUT25L
  0x00004830, //GFXMMU_LUT25H
  0x00420D01, //GFXMMU_LUT26L
  0x00004B90, //GFXMMU_LUT26H
  0x00420D01, //GFXMMU_LUT27L
  0x00004EF0, //GFXMMU_LUT27H
  0x00420D01, //GFXMMU_LUT28L
  0x00005250, //GFXMMU_LUT28H
  0x00430C01, //GFXMMU_LUT29L
  0x000055C0, //GFXMMU_LUT29H
  0x00430C01, //GFXMMU_LUT30L
  0x00005940, //GFXMMU_LUT30H
  0x00430C01, //GFXMMU_LUT31L
  0x00005CC0, //GFXMMU_LUT31H
  0x00430C01, //GFXMMU_LUT32L
  0x00006040, //GFXMMU_LUT32H
  0x00440B01, //GFXMMU_LUT33L
  0x000063D0, //GFXMMU_LUT33H
  0x00440B01, //GFXMMU_LUT34L
  0x00006770, //GFXMMU_LUT34H
  0x00440B01, //GFXMMU_LUT35L
  0x00006B10, //GFXMMU_LUT35H
  0x00440B01, //GFXMMU_LUT36L
  0x00006EB0, //GFXMMU_LUT36H
  0x00450A01, //GFXMMU_LUT37L
  0x00007260, //GFXMMU_LUT37H
  0x00450A01, //GFXMMU_LUT38L
  0x00007620, //GFXMMU_LUT38H
  0x00450A01, //GFXMMU_LUT39L
  0x000079E0, //GFXMMU_LUT39H
  0x00450A01, //GFXMMU_LUT40L
  0x00007DA0, //GFXMMU_LUT40H
  0x00460901, //GFXMMU_LUT41L
  0x00008170, //GFXMMU_LUT41H
  0x00460901, //GFXMMU_LUT42L
  0x00008550, //GFXMMU_LUT42H
  0x00460901, //GFXMMU_LUT43L
  0x00008930, //GFXMMU_LUT43H
  0x00460901, //GFXMMU_LUT44L
  0x00008D10, //GFXMMU_LUT44H
  0x00470801, //GFXMMU_LUT45L
  0x00009100, //GFXMMU_LUT45H
  0x00470801, //GFXMMU_LUT46L
  0x00009500, //GFXMMU_LUT46H
  0x00470801, //GFXMMU_LUT47L
  0x00009900, //GFXMMU_LUT47H
  0x00470801, //GFXMMU_LUT48L
  0x00009D00, //GFXMMU_LUT48H
  0x00480701, //GFXMMU_LUT49L
  0x0000A110, //GFXMMU_LUT49H
  0x00480701, //GFXMMU_LUT50L
  0x0000A530, //GFXMMU_LUT50H
  0x00480701, //GFXMMU_LUT51L
  0x0000A950, //GFXMMU_LUT51H
  0x00480701, //GFXMMU_LUT52L
  0x0000AD70, //GFXMMU_LUT52H
  0x00490601, //GFXMMU_LUT53L
  0x0000B1A0, //GFXMMU_LUT53H
  0x00490601, //GFXMMU_LUT54L
  0x0000B5E0, //GFXMMU_LUT54H
  0x00490601, //GFXMMU_LUT55L
  0x0000BA20, //GFXMMU_LUT55H
  0x00490601, //GFXMMU_LUT56L
  0x0000BE60, //GFXMMU_LUT56H
  0x004A0501, //GFXMMU_LUT57L
  0x0000C2B0, //GFXMMU_LUT57H
  0x004A0501, //GFXMMU_LUT58L
  0x0000C710, //GFXMMU_LUT58H
  0x004A0501, //GFXMMU_LUT59L
  0x0000CB70, //GFXMMU_LUT59H
  0x004A0501, //GFXMMU_LUT60L
  0x0000CFD0, //GFXMMU_LUT60H
  0x004B0401, //GFXMMU_LUT61L
  0x0000D440, //GFXMMU_LUT61H
  0x004B0401, //GFXMMU_LUT62L
  0x0000D8C0, //GFXMMU_LUT62H
  0x004B0401, //GFXMMU_LUT63L
  0x0000DD40, //GFXMMU_LUT63H
  0x004B0401, //GFXMMU_LUT64L
  0x0000E1C0, //GFXMMU_LUT64H
  0x004C0301, //GFXMMU_LUT65L
  0x0000E650, //GFXMMU_LUT65H
  0x004C0301, //GFXMMU_LUT66L
  0x0000EAF0, //GFXMMU_LUT66H
  0x004C0301, //GFXMMU_LUT67L
  0x0000EF90, //GFXMMU_LUT67H
  0x004C0301, //GFXMMU_LUT68L
  0x0000F430, //GFXMMU_LUT68H
  0x004D0201, //GFXMMU_LUT69L
  0x0000F8E0, //GFXMMU_LUT69H
  0x004D0201, //GFXMMU_LUT70L
  0x0000FDA0, //GFXMMU_LUT70H
  0x004D0201, //GFXMMU_LUT71L
  0x00010260, //GFXMMU_LUT71H
  0x004D0201, //GFXMMU_LUT72L
  0x00010720, //GFXMMU_LUT72H
  0x004E0101, //GFXMMU_LUT73L
  0x00010BF0, //GFXMMU_LUT73H
  0x004E0101, //GFXMMU_LUT74L
  0x000110D0, //GFXMMU_LUT74H
  0x004E0101, //GFXMMU_LUT75L
  0x000115B0, //GFXMMU_LUT75H
  0x004E0101, //GFXMMU_LUT76L
  0x00011A90, //GFXMMU_LUT76H
  0x004F0001, //GFXMMU_LUT77L
  0x00011F80, //GFXMMU_LUT77H
  0x004F0001, //GFXMMU_LUT78L
  0x00012480, //GFXMMU_LUT78H
  0x004F0001, //GFXMMU_LUT79L
  0x00012980, //GFXMMU_LUT79H
  0x004F0001, //GFXMMU_LUT80L
  0x00012E80, //GFXMMU_LUT80H
  0x004F0001, //GFXMMU_LUT81L
  0x00013380, //GFXMMU_LUT81H
  0x004F0001, //GFXMMU_LUT82L
  0x00013880, //GFXMMU_LUT82H
  0x004F0001, //GFXMMU_LUT83L
  0x00013D80, //GFXMMU_LUT83H
  0x004F0001, //GFXMMU_LUT84L
  0x00014280, //GFXMMU_LUT84H
  0x004F0001, //GFXMMU_LUT85L
  0x00014780, //GFXMMU_LUT85H
  0x004F0001, //GFXMMU_LUT86L
  0x00014C80, //GFXMMU_LUT86H
  0x004F0001, //GFXMMU_LUT87L
  0x00015180, //GFXMMU_LUT87H
  0x004F0001, //GFXMMU_LUT88L
  0x00015680, //GFXMMU_LUT88H
  0x004F0001, //GFXMMU_LUT89L
  0x00015B80, //GFXMMU_LUT89H
  0x004F0001, //GFXMMU_LUT90L
  0x00016080, //GFXMMU_LUT90H
  0x004F0001, //GFXMMU_LUT91L
  0x00016580, //GFXMMU_LUT91H
  0x004F0001, //GFXMMU_LUT92L
  0x00016A80, //GFXMMU_LUT92H
  0x004F0001, //GFXMMU_LUT93L
  0x00016F80, //GFXMMU_LUT93H
  0x004F0001, //GFXMMU_LUT94L
  0x00017480, //GFXMMU_LUT94H
  0x004F0001, //GFXMMU_LUT95L
  0x00017980, //GFXMMU_LUT95H
  0x004F0001, //GFXMMU_LUT96L
  0x00017E80, //GFXMMU_LUT96H
  0x004F0001, //GFXMMU_LUT97L
  0x00018380, //GFXMMU_LUT97H
  0x004F0001, //GFXMMU_LUT98L
  0x00018880, //GFXMMU_LUT98H
  0x004F0001, //GFXMMU_LUT99L
  0x00018D80, //GFXMMU_LUT99H
  0x004F0001, //GFXMMU_LUT100L
  0x00019280, //GFXMMU_LUT100H
  0x004F0001, //GFXMMU_LUT101L
  0x00019780, //GFXMMU_LUT101H
  0x004F0001, //GFXMMU_LUT102L
  0x00019C80, //GFXMMU_LUT102H
  0x004F0001, //GFXMMU_LUT103L
  0x0001A180, //GFXMMU_LUT103H
  0x004F0001, //GFXMMU_LUT104L
  0x0001A680, //GFXMMU_LUT104H
  0x004F0001, //GFXMMU_LUT105L
  0x0001AB80, //GFXMMU_LUT105H
  0x004F0001, //GFXMMU_LUT106L
  0x0001B080, //GFXMMU_LUT106H
  0x004F0001, //GFXMMU_LUT107L
  0x0001B580, //GFXMMU_LUT107H
  0x004F0001, //GFXMMU_LUT108L
  0x0001BA80, //GFXMMU_LUT108H
  0x004F0001, //GFXMMU_LUT109L
  0x0001BF80, //GFXMMU_LUT109H
  0x004F0001, //GFXMMU_LUT110L
  0x0001C480, //GFXMMU_LUT110H
  0x004F0001, //GFXMMU_LUT111L
  0x0001C980, //GFXMMU_LUT111H
  0x004F0001, //GFXMMU_LUT112L
  0x0001CE80, //GFXMMU_LUT112H
  0x004F0001, //GFXMMU_LUT113L
  0x0001D380, //GFXMMU_LUT113H
  0x004F0001, //GFXMMU_LUT114L
  0x0001D880, //GFXMMU_LUT114H
  0x004F0001, //GFXMMU_LUT115L
  0x0001DD80, //GFXMMU_LUT115H
  0x004F0001, //GFXMMU_LUT116L
  0x0001E280, //GFXMMU_LUT116H
  0x004F0001, //GFXMMU_LUT117L
  0x0001E780, //GFXMMU_LUT117H
  0x004F0001, //GFXMMU_LUT118L
  0x0001EC80, //GFXMMU_LUT118H
  0x004F0001, //GFXMMU_LUT119L
  0x0001F180, //GFXMMU_LUT119H
  0x004F0001, //GFXMMU_LUT120L
  0x0001F680, //GFXMMU_LUT120H
  0x004F0001, //GFXMMU_LUT121L
  0x0001FB80, //GFXMMU_LUT121H
  0x004F0001, //GFXMMU_LUT122L
  0x00020080, //GFXMMU_LUT122H
  0x004F0001, //GFXMMU_LUT123L
  0x00020580, //GFXMMU_LUT123H
  0x004F0001, //GFXMMU_LUT124L
  0x00020A80, //GFXMMU_LUT124H
  0x004F0001, //GFXMMU_LUT125L
  0x00020F80, //GFXMMU_LUT125H
  0x004F0001, //GFXMMU_LUT126L
  0x00021480, //GFXMMU_LUT126H
  0x004F0001, //GFXMMU_LUT127L
  0x00021980, //GFXMMU_LUT127H
  0x004F0001, //GFXMMU_LUT128L
  0x00021E80, //GFXMMU_LUT128H
  0x004F0001, //GFXMMU_LUT129L
  0x00022380, //GFXMMU_LUT129H
  0x004F0001, //GFXMMU_LUT130L
  0x00022880, //GFXMMU_LUT130H
  0x004F0001, //GFXMMU_LUT131L
  0x00022D80, //GFXMMU_LUT131H
  0x004F0001, //GFXMMU_LUT132L
  0x00023280, //GFXMMU_LUT132H
  0x004F0001, //GFXMMU_LUT133L
  0x00023780, //GFXMMU_LUT133H
  0x004F0001, //GFXMMU_LUT134L
  0x00023C80, //GFXMMU_LUT134H
  0x004F0001, //GFXMMU_LUT135L
  0x00024180, //GFXMMU_LUT135H
  0x004F0001, //GFXMMU_LUT136L
  0x00024680, //GFXMMU_LUT136H
  0x004F0001, //GFXMMU_LUT137L
  0x00024B80, //GFXMMU_LUT137H
  0x004F0001, //GFXMMU_LUT138L
  0x00025080, //GFXMMU_LUT138H
  0x004F0001, //GFXMMU_LUT139L
  0x00025580, //GFXMMU_LUT139H
  0x004F0001, //GFXMMU_LUT140L
  0x00025A80, //GFXMMU_LUT140H
  0x004F0001, //GFXMMU_LUT141L
  0x00025F80, //GFXMMU_LUT141H
  0x004F0001, //GFXMMU_LUT142L
  0x00026480, //GFXMMU_LUT142H
  0x004F0001, //GFXMMU_LUT143L
  0x00026980, //GFXMMU_LUT143H
  0x004F0001, //GFXMMU_LUT144L
  0x00026E80, //GFXMMU_LUT144H
  0x004F0001, //GFXMMU_LUT145L
  0x00027380, //GFXMMU_LUT145H
  0x004F0001, //GFXMMU_LUT146L
  0x00027880, //GFXMMU_LUT146H
  0x004F0001, //GFXMMU_LUT147L
  0x00027D80, //GFXMMU_LUT147H
  0x004F0001, //GFXMMU_LUT148L
  0x00028280, //GFXMMU_LUT148H
  0x004F0001, //GFXMMU_LUT149L
  0x00028780, //GFXMMU_LUT149H
  0x004F0001, //GFXMMU_LUT150L
  0x00028C80, //GFXMMU_LUT150H
  0x004F0001, //GFXMMU_LUT151L
  0x00029180, //GFXMMU_LUT151H
  0x004F0001, //GFXMMU_LUT152L
  0x00029680, //GFXMMU_LUT152H
  0x004F0001, //GFXMMU_LUT153L
  0x00029B80, //GFXMMU_LUT153H
  0x004F0001, //GFXMMU_LUT154L
  0x0002A080, //GFXMMU_LUT154H
  0x004F0001, //GFXMMU_LUT155L
  0x0002A580, //GFXMMU_LUT155H
  0x004F0001, //GFXMMU_LUT156L
  0x0002AA80, //GFXMMU_LUT156H
  0x004F0001, //GFXMMU_LUT157L
  0x0002AF80, //GFXMMU_LUT157H
  0x004F0001, //GFXMMU_LUT158L
  0x0002B480, //GFXMMU_LUT158H
  0x004F0001, //GFXMMU_LUT159L
  0x0002B980, //GFXMMU_LUT159H
  0x004F0001, //GFXMMU_LUT160L
  0x0002BE80, //GFXMMU_LUT160H
  0x004F0001, //GFXMMU_LUT161L
  0x0002C380, //GFXMMU_LUT161H
  0x004F0001, //GFXMMU_LUT162L
  0x0002C880, //GFXMMU_LUT162H
  0x004F0001, //GFXMMU_LUT163L
  0x0002CD80, //GFXMMU_LUT163H
  0x004F0001, //GFXMMU_LUT164L
  0x0002D280, //GFXMMU_LUT164H
  0x004F0001, //GFXMMU_LUT165L
  0x0002D780, //GFXMMU_LUT165H
  0x004F0001, //GFXMMU_LUT166L
  0x0002DC80, //GFXMMU_LUT166H
  0x004F0001, //GFXMMU_LUT167L
  0x0002E180, //GFXMMU_LUT167H
  0x004F0001, //GFXMMU_LUT168L
  0x0002E680, //GFXMMU_LUT168H
  0x004F0001, //GFXMMU_LUT169L
  0x0002EB80, //GFXMMU_LUT169H
  0x004F0001, //GFXMMU_LUT170L
  0x0002F080, //GFXMMU_LUT170H
  0x004F0001, //GFXMMU_LUT171L
  0x0002F580, //GFXMMU_LUT171H
  0x004F0001, //GFXMMU_LUT172L
  0x0002FA80, //GFXMMU_LUT172H
  0x004F0001, //GFXMMU_LUT173L
  0x0002FF80, //GFXMMU_LUT173H
  0x004F0001, //GFXMMU_LUT174L
  0x00030480, //GFXMMU_LUT174H
  0x004F0001, //GFXMMU_LUT175L
  0x00030980, //GFXMMU_LUT175H
  0x004F0001, //GFXMMU_LUT176L
  0x00030E80, //GFXMMU_LUT176H
  0x004F0001, //GFXMMU_LUT177L
  0x00031380, //GFXMMU_LUT177H
  0x004F0001, //GFXMMU_LUT178L
  0x00031880, //GFXMMU_LUT178H
  0x004F0001, //GFXMMU_LUT179L
  0x00031D80, //GFXMMU_LUT179H
  0x004F0001, //GFXMMU_LUT180L
  0x00032280, //GFXMMU_LUT180H
  0x004F0001, //GFXMMU_LUT181L
  0x00032780, //GFXMMU_LUT181H
  0x004F0001, //GFXMMU_LUT182L
  0x00032C80, //GFXMMU_LUT182H
  0x004F0001, //GFXMMU_LUT183L
  0x00033180, //GFXMMU_LUT183H
  0x004F0001, //GFXMMU_LUT184L
  0x00033680, //GFXMMU_LUT184H
  0x004F0001, //GFXMMU_LUT185L
  0x00033B80, //GFXMMU_LUT185H
  0x004F0001, //GFXMMU_LUT186L
  0x00034080, //GFXMMU_LUT186H
  0x004F0001, //GFXMMU_LUT187L
  0x00034580, //GFXMMU_LUT187H
  0x004F0001, //GFXMMU_LUT188L
  0x00034A80, //GFXMMU_LUT188H
  0x004F0001, //GFXMMU_LUT189L
  0x00034F80, //GFXMMU_LUT189H
  0x004F0001, //GFXMMU_LUT190L
  0x00035480, //GFXMMU_LUT190H
  0x004F0001, //GFXMMU_LUT191L
  0x00035980, //GFXMMU_LUT191H
  0x004F0001, //GFXMMU_LUT192L
  0x00035E80, //GFXMMU_LUT192H
  0x004F0001, //GFXMMU_LUT193L
  0x00036380, //GFXMMU_LUT193H
  0x004F0001, //GFXMMU_LUT194L
  0x00036880, //GFXMMU_LUT194H
  0x004F0001, //GFXMMU_LUT195L
  0x00036D80, //GFXMMU_LUT195H
  0x004F0001, //GFXMMU_LUT196L
  0x00037280, //GFXMMU_LUT196H
  0x004F0001, //GFXMMU_LUT197L
  0x00037780, //GFXMMU_LUT197H
  0x004F0001, //GFXMMU_LUT198L
  0x00037C80, //GFXMMU_LUT198H
  0x004F0001, //GFXMMU_LUT199L
  0x00038180, //GFXMMU_LUT199H
  0x004F0001, //GFXMMU_LUT200L
  0x00038680, //GFXMMU_LUT200H
  0x004F0001, //GFXMMU_LUT201L
  0x00038B80, //GFXMMU_LUT201H
  0x004F0001, //GFXMMU_LUT202L
  0x00039080, //GFXMMU_LUT202H
  0x004F0001, //GFXMMU_LUT203L
  0x00039580, //GFXMMU_LUT203H
  0x004F0001, //GFXMMU_LUT204L
  0x00039A80, //GFXMMU_LUT204H
  0x004F0001, //GFXMMU_LUT205L
  0x00039F80, //GFXMMU_LUT205H
  0x004F0001, //GFXMMU_LUT206L
  0x0003A480, //GFXMMU_LUT206H
  0x004F0001, //GFXMMU_LUT207L
  0x0003A980, //GFXMMU_LUT207H
  0x004F0001, //GFXMMU_LUT208L
  0x0003AE80, //GFXMMU_LUT208H
  0x004F0001, //GFXMMU_LUT209L
  0x0003B380, //GFXMMU_LUT209H
  0x004F0001, //GFXMMU_LUT210L
  0x0003B880, //GFXMMU_LUT210H
  0x004F0001, //GFXMMU_LUT211L
  0x0003BD80, //GFXMMU_LUT211H
  0x004F0001, //GFXMMU_LUT212L
  0x0003C280, //GFXMMU_LUT212H
  0x004F0001, //GFXMMU_LUT213L
  0x0003C780, //GFXMMU_LUT213H
  0x004F0001, //GFXMMU_LUT214L
  0x0003CC80, //GFXMMU_LUT214H
  0x004F0001, //GFXMMU_LUT215L
  0x0003D180, //GFXMMU_LUT215H
  0x004F0001, //GFXMMU_LUT216L
  0x0003D680, //GFXMMU_LUT216H
  0x004F0001, //GFXMMU_LUT217L
  0x0003DB80, //GFXMMU_LUT217H
  0x004F0001, //GFXMMU_LUT218L
  0x0003E080, //GFXMMU_LUT218H
  0x004F0001, //GFXMMU_LUT219L
  0x0003E580, //GFXMMU_LUT219H
  0x004F0001, //GFXMMU_LUT220L
  0x0003EA80, //GFXMMU_LUT220H
  0x004F0001, //GFXMMU_LUT221L
  0x0003EF80, //GFXMMU_LUT221H
  0x004F0001, //GFXMMU_LUT222L
  0x0003F480, //GFXMMU_LUT222H
  0x004F0001, //GFXMMU_LUT223L
  0x0003F980, //GFXMMU_LUT223H
  0x004F0001, //GFXMMU_LUT224L
  0x0003FE80, //GFXMMU_LUT224H
  0x004F0001, //GFXMMU_LUT225L
  0x00040380, //GFXMMU_LUT225H
  0x004F0001, //GFXMMU_LUT226L
  0x00040880, //GFXMMU_LUT226H
  0x004F0001, //GFXMMU_LUT227L
  0x00040D80, //GFXMMU_LUT227H
  0x004F0001, //GFXMMU_LUT228L
  0x00041280, //GFXMMU_LUT228H
  0x004F0001, //GFXMMU_LUT229L
  0x00041780, //GFXMMU_LUT229H
  0x004F0001, //GFXMMU_LUT230L
  0x00041C80, //GFXMMU_LUT230H
  0x004F0001, //GFXMMU_LUT231L
  0x00042180, //GFXMMU_LUT231H
  0x004F0001, //GFXMMU_LUT232L
  0x00042680, //GFXMMU_LUT232H
  0x004F0001, //GFXMMU_LUT233L
  0x00042B80, //GFXMMU_LUT233H
  0x004F0001, //GFXMMU_LUT234L
  0x00043080, //GFXMMU_LUT234H
  0x004F0001, //GFXMMU_LUT235L
  0x00043580, //GFXMMU_LUT235H
  0x004F0001, //GFXMMU_LUT236L
  0x00043A80, //GFXMMU_LUT236H
  0x004F0001, //GFXMMU_LUT237L
  0x00043F80, //GFXMMU_LUT237H
  0x004F0001, //GFXMMU_LUT238L
  0x00044480, //GFXMMU_LUT238H
  0x004F0001, //GFXMMU_LUT239L
  0x00044980, //GFXMMU_LUT239H
  0x004F0001, //GFXMMU_LUT240L
  0x00044E80, //GFXMMU_LUT240H
  0x004F0001, //GFXMMU_LUT241L
  0x00045380, //GFXMMU_LUT241H
  0x004F0001, //GFXMMU_LUT242L
  0x00045880, //GFXMMU_LUT242H
  0x004E0101, //GFXMMU_LUT243L
  0x00045D70, //GFXMMU_LUT243H
  0x004E0101, //GFXMMU_LUT244L
  0x00046250, //GFXMMU_LUT244H
  0x004E0101, //GFXMMU_LUT245L
  0x00046730, //GFXMMU_LUT245H
  0x004E0101, //GFXMMU_LUT246L
  0x00046C10, //GFXMMU_LUT246H
  0x004D0201, //GFXMMU_LUT247L
  0x000470E0, //GFXMMU_LUT247H
  0x004D0201, //GFXMMU_LUT248L
  0x000475A0, //GFXMMU_LUT248H
  0x004D0201, //GFXMMU_LUT249L
  0x00047A60, //GFXMMU_LUT249H
  0x004D0201, //GFXMMU_LUT250L
  0x00047F20, //GFXMMU_LUT250H
  0x004C0301, //GFXMMU_LUT251L
  0x000483D0, //GFXMMU_LUT251H
  0x004C0301, //GFXMMU_LUT252L
  0x00048870, //GFXMMU_LUT252H
  0x004C0301, //GFXMMU_LUT253L
  0x00048D10, //GFXMMU_LUT253H
  0x004C0301, //GFXMMU_LUT254L
  0x000491B0, //GFXMMU_LUT254H
  0x004B0401, //GFXMMU_LUT255L
  0x00049640, //GFXMMU_LUT255H
  0x004B0401, //GFXMMU_LUT256L
  0x00049AC0, //GFXMMU_LUT256H
  0x004B0401, //GFXMMU_LUT257L
  0x00049F40, //GFXMMU_LUT257H
  0x004B0401, //GFXMMU_LUT258L
  0x0004A3C0, //GFXMMU_LUT258H
  0x004A0501, //GFXMMU_LUT259L
  0x0004A830, //GFXMMU_LUT259H
  0x004A0501, //GFXMMU_LUT260L
  0x0004AC90, //GFXMMU_LUT260H
  0x004A0501, //GFXMMU_LUT261L
  0x0004B0F0, //GFXMMU_LUT261H
  0x004A0501, //GFXMMU_LUT262L
  0x0004B550, //GFXMMU_LUT262H
  0x00490601, //GFXMMU_LUT263L
  0x0004B9A0, //GFXMMU_LUT263H
  0x00490601, //GFXMMU_LUT264L
  0x0004BDE0, //GFXMMU_LUT264H
  0x00490601, //GFXMMU_LUT265L
  0x0004C220, //GFXMMU_LUT265H
  0x00490601, //GFXMMU_LUT266L
  0x0004C660, //GFXMMU_LUT266H
  0x00480701, //GFXMMU_LUT267L
  0x0004CA90, //GFXMMU_LUT267H
  0x00480701, //GFXMMU_LUT268L
  0x0004CEB0, //GFXMMU_LUT268H
  0x00480701, //GFXMMU_LUT269L
  0x0004D2D0, //GFXMMU_LUT269H
  0x00480701, //GFXMMU_LUT270L
  0x0004D6F0, //GFXMMU_LUT270H
  0x00470801, //GFXMMU_LUT271L
  0x0004DB00, //GFXMMU_LUT271H
  0x00470801, //GFXMMU_LUT272L
  0x0004DF00, //GFXMMU_LUT272H
  0x00470801, //GFXMMU_LUT273L
  0x0004E300, //GFXMMU_LUT273H
  0x00470801, //GFXMMU_LUT274L
  0x0004E700, //GFXMMU_LUT274H
  0x00460901, //GFXMMU_LUT275L
  0x0004EAF0, //GFXMMU_LUT275H
  0x00460901, //GFXMMU_LUT276L
  0x0004EED0, //GFXMMU_LUT276H
  0x00460901, //GFXMMU_LUT277L
  0x0004F2B0, //GFXMMU_LUT277H
  0x00460901, //GFXMMU_LUT278L
  0x0004F690, //GFXMMU_LUT278H
  0x00450A01, //GFXMMU_LUT279L
  0x0004FA60, //GFXMMU_LUT279H
  0x00450A01, //GFXMMU_LUT280L
  0x0004FE20, //GFXMMU_LUT280H
  0x00450A01, //GFXMMU_LUT281L
  0x000501E0, //GFXMMU_LUT281H
  0x00450A01, //GFXMMU_LUT282L
  0x000505A0, //GFXMMU_LUT282H
  0x00440B01, //GFXMMU_LUT283L
  0x00050950, //GFXMMU_LUT283H
  0x00440B01, //GFXMMU_LUT284L
  0x00050CF0, //GFXMMU_LUT284H
  0x00440B01, //GFXMMU_LUT285L
  0x00051090, //GFXMMU_LUT285H
  0x00440B01, //GFXMMU_LUT286L
  0x00051430, //GFXMMU_LUT286H
  0x00430C01, //GFXMMU_LUT287L
  0x000517C0, //GFXMMU_LUT287H
  0x00430C01, //GFXMMU_LUT288L
  0x00051B40, //GFXMMU_LUT288H
  0x00430C01, //GFXMMU_LUT289L
  0x00051EC0, //GFXMMU_LUT289H
  0x00430C01, //GFXMMU_LUT290L
  0x00052240, //GFXMMU_LUT290H
  0x00420D01, //GFXMMU_LUT291L
  0x000525B0, //GFXMMU_LUT291H
  0x00420D01, //GFXMMU_LUT292L
  0x00052910, //GFXMMU_LUT292H
  0x00420D01, //GFXMMU_LUT293L
  0x00052C70, //GFXMMU_LUT293H
  0x00420D01, //GFXMMU_LUT294L
  0x00052FD0, //GFXMMU_LUT294H
  0x00410E01, //GFXMMU_LUT295L
  0x00053320, //GFXMMU_LUT295H
  0x00410E01, //GFXMMU_LUT296L
  0x00053660, //GFXMMU_LUT296H
  0x00410E01, //GFXMMU_LUT297L
  0x000539A0, //GFXMMU_LUT297H
  0x00410E01, //GFXMMU_LUT298L
  0x00053CE0, //GFXMMU_LUT298H
  0x00400F01, //GFXMMU_LUT299L
  0x00054010, //GFXMMU_LUT299H
  0x00400F01, //GFXMMU_LUT300L
  0x00054330, //GFXMMU_LUT300H
  0x00400F01, //GFXMMU_LUT301L
  0x00054650, //GFXMMU_LUT301H
  0x00400F01, //GFXMMU_LUT302L
  0x00054970, //GFXMMU_LUT302H
  0x003F1001, //GFXMMU_LUT303L
  0x00054C80, //GFXMMU_LUT303H
  0x003F1001, //GFXMMU_LUT304L
  0x00054F80, //GFXMMU_LUT304H
  0x003F1001, //GFXMMU_LUT305L
  0x00055280, //GFXMMU_LUT305H
  0x003F1001, //GFXMMU_LUT306L
  0x00055580, //GFXMMU_LUT306H
  0x003E1101, //GFXMMU_LUT307L
  0x00055870, //GFXMMU_LUT307H
  0x003E1101, //GFXMMU_LUT308L
  0x00055B50, //GFXMMU_LUT308H
  0x003E1101, //GFXMMU_LUT309L
  0x00055E30, //GFXMMU_LUT309H
  0x003E1101, //GFXMMU_LUT310L
  0x00056110, //GFXMMU_LUT310H
  0x003D1201, //GFXMMU_LUT311L
  0x000563E0, //GFXMMU_LUT311H
  0x003D1201, //GFXMMU_LUT312L
  0x000566A0, //GFXMMU_LUT312H
  0x003D1201, //GFXMMU_LUT313L
  0x00056960, //GFXMMU_LUT313H
  0x003D1201, //GFXMMU_LUT314L
  0x00056C20, //GFXMMU_LUT314H
  0x003C1301, //GFXMMU_LUT315L
  0x00056ED0, //GFXMMU_LUT315H
  0x003C1301, //GFXMMU_LUT316L
  0x00057170, //GFXMMU_LUT316H
  0x003C1301, //GFXMMU_LUT317L
  0x00057410, //GFXMMU_LUT317H
  0x003C1301, //GFXMMU_LUT318L
  0x000576B0, //GFXMMU_LUT318H
  0x003B1401, //GFXMMU_LUT319L
  0x00057940 //GFXMMU_LUT319H
};

#ifdef __cplusplus
}
#endif
#endif /*__ gfxmmu_lut_H */

/**
  * @}
  */

/**
  * @}
  */

/************************ (C) COPYRIGHT STMicroelectronics *****END OF FILE****/


Obviously I disabled all touchscreen stuff in the demo code

I made other modifications for the width, height, etc
essentially, all the modifications I made to the BSP LCD drivers, are in the files here:
http://internetsomething.com/lcd/bsp-example/

I'll see if I can get the screen to do anything useful on the STM32F769I Disco board, although I only have about an hour, and I haven't been near C or STM32 in what feels like a year, and I was only just starting to learn it then too, so it's not very clear to me really

[carl0s]

Oh, actually, it has been a year. About 1yr and 2 weeks :-)

[TiN]

Differential pairs are not routed differentially, as they should be. Good idea to calculate impedance to your stackup so you can maintain correct trace width/spacing to have good SI.
Avoid 90 bends, use 45 degree or arcs. All power connect by wide trace or better yet copper pour shape.
Do not use thermal connection for GND vias, you just introducing more inductance/impedance without any good reason.
All parts with GND connections should have just via next to pad right next to pad, no traces. Nice touch to have evenly distributed GND vias around GND pads of that Mictor connector.

[carl0s]

Differential pairs are not routed differentially, as they should be. Good idea to calculate impedance to your stackup so you can maintain correct trace width/spacing to have good SI.
Avoid 90 bends, use 45 degree or arcs. All power connect by wide trace or better yet copper pour shape.
Do not use thermal connection for GND vias, you just introducing more inductance/impedance without any good reason.
All parts with GND connections should have just via next to pad right next to pad, no traces. Nice touch to have evenly distributed GND vias around GND pads of that Mictor connector.

Thank you. I'll take this on board for next time. The differential pairs are length-matched. Is that not what you mean?

[luiHS]

You will be surprised. It looks like, apart from one command, I simply removed all the rest.

I was working with the BSP Example / Demo. I.e. the board support package demo - that's what you can see in my photos before, with the ST logo etc.

My changed version of that sequence looks like this :

Code: [Select]

    /*************************/
    /* LCD POWER ON SEQUENCE */
    /*************************/


// very minimal init code for panasys round octagonal tft
// this is 0x36 for MADCTL, with parameter 0x48 for xmirror, top left to bottom-right, bgr
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x36, 0x48);
    //HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x3A, 0x55);



    /* Sleep out */
    HAL_DSI_ShortWrite(&hdsi_discovery, 0, DSI_DCS_SHORT_PKT_WRITE_P0, DSI_EXIT_SLEEP_MODE, 0x0);

    HAL_Delay(120);

Essentially I replaced all the LCD init code with a simple MATCTL 0x48 (that is cmd 0x36, data 0x48).

Perfect, thanks for your information, very useful for me.

However, there is a signal, the TE (Tearing effect), I don't know if you are using it. For pictures, it is perhaps not important, but to play videos may be essential, it is a synchronization signal that sends the screen to the program, to avoid an effect that would cause half of the upper image not to be synchronized with the other half, let's say half of the screen would show the current frame and the other half still the previous frame.

This octagonal screen does have the TE signal, but I have other screens that do not. I suppose that the screens that do not have the TE signal would not serve to play video, just to see images.

In the list of commands sent to me by the seller of the screen, there is command 35, data 00, related to the activation of the TE signal.

I created a rough GFXMMU_LUT, but this is just to save memory by, erm, not allocating the bits of pixel space that would be outside of the circle. I think you can work without it..

I also have the same kit you used to do your tests with round screens. I read something about specific routines to save space in RAM, eliminating all the pixels that are outside the circular area of ​​the screen. As soon as I get my screen to work, I will see if setting up that routine correctly, I can optimize the performance of the program. Notwithstanding the example sources for the STM32F769, they are for rectancular screens such as the one included in Discovery, these routines of the STM32L4R9I-DISCOVERY kit should be added.

Obviously I disabled all touchscreen stuff in the demo code

I made other modifications for the width, height, etc
essentially, all the modifications I made to the BSP LCD drivers, are in the files here:
http://internetsomething.com/lcd/bsp-example/

I'll see if I can get the screen to do anything useful on the STM32F769I Disco board, although I only have about an hour, and I haven't been near C or STM32 in what feels like a year, and I was only just starting to learn it then too, so it's not very clear to me really

I will also check all the parameters, in the Cube for the F769, there is also the Drivers / BSP directory with the sources for the lcd that define all those parameters. The sources in the Cube for Discovery with the F769 are for visualizing images. The source for playing videos is for the EVAL board.

Both, Discovery and EVAL evaluation boards, use the same microcontroller, the differences in practice to be able to use the EVAL example source code in Discovery are these.

1.- The EVAL has two SD cardholders, the Discovery only one. In the EVAL sources the cardholder that does not have the Discovery is used, I think the SD1. It would be necessary to edit the sources and change it, it seems simple.

2.- The EVAL Card Detect is connected through an I2c expander, while in the Discovery it goes directly to a GPIO port. It also seems a simple change to make.

3.- The SDRAM in the EVAL is double, 256 Megabytes, in the Discovery we have 128 Megabytes. I don't know if this can be a problem to be able to run the program that plays videos. If 256 megabytes of SDRAM were necessary for the video player, then I will make my own board, with the F769, the SDRAM and an SD card holder, in addition to the backlight voltage booster.


For the voltage booster, for the backlight, I use this scheme with several jumpers, to select several voltages, for the different display models I have, each one requires a different voltage.

[carl0s]

I've been trying to do something with the STM32F769I-DISCO. Firstly trying to build an empty StemWin 'hello world'. I previously compiled the example projects, and they all work fine, but I couldn't get anything to display on the board that CubeMX/STM32CubeIDE had created. The plan was to get that working, seeing as though it's the kit exactly as chosen in the CubeMX 'board selector (including screen)', and then once working, see if I could get the round/octagonal screen to do something useful.

Anyway I've had to 'work from home' today due to sleep deprivation trying to figure out why STM32CubeIDE would not do a Hello World even with the original screen. It's because the LCD_LL_Reset() isn't implemented - seems CubeMX (which is now not really called CubeMX as it's integrated into the IDE that used to be called TrueStudio but is now STM32CubeIDE) just doesn't use the BSP stuff at all. That's why in the Graphics 'Platform Settings' it says 'BSP API: Unknown':


So I just copied the BSP reset function (which is used by the examples) into the empty LCD_LL_Reset() function that CubeMX generated.

Code: [Select]

/* Configures the LCD reset pin. */

     /* USER CODE BEGIN Config_LCD_Reset_Pin */
        static void LCD_LL_Reset(void) {
            GPIO_InitTypeDef  gpio_init_structure;

              __HAL_RCC_GPIOJ_CLK_ENABLE();

                /* Configure the GPIO on PJ15 */
                gpio_init_structure.Pin   = GPIO_PIN_15;
                gpio_init_structure.Mode  = GPIO_MODE_OUTPUT_PP;
                gpio_init_structure.Pull  = GPIO_PULLUP;
                gpio_init_structure.Speed = GPIO_SPEED_HIGH;

                HAL_GPIO_Init(GPIOJ, &gpio_init_structure);

                /* Activate XRES active low */
                HAL_GPIO_WritePin(GPIOJ, GPIO_PIN_15, GPIO_PIN_RESET);

                HAL_Delay(20); /* wait 20 ms */

                /* Desactivate XRES */
                HAL_GPIO_WritePin(GPIOJ, GPIO_PIN_15, GPIO_PIN_SET);

                /* Wait for 10ms after releasing XRES before sending commands */
                HAL_Delay(10);
        }
      /* USER CODE END Config_LCD_Reset_Pin */

That then worked - I had a working Hello World on the original screen.

Moving onto the octagonal screen, I still told CubeMX that I was using the OTM8009A screen, just so I could see where they usually put the DSI commands and stuff. Selecting 'Other screen' left me a bit in the dark about that.

It was in HW_Init.c at line 370 in this case (will be different depending what HW peripherials CubeMX is setting up I suppose)
I obviously changed to One Data Lane in the DSIHOST -> Data and Clock lanes configuration

and you can see I've put those same DSI init commands here as what I did before.

Code: [Select]

  /* Initialize the OTM8009A LCD Display IC Driver (KoD LCD IC Driver)
   *  depending on configuration set in 'hdsivideo_handle'.
   */

  /* Send Display off DCS Command to display */
//  HAL_DSI_ShortWrite(&(hdsi),
//                     0,
//                     DSI_DCS_SHORT_PKT_WRITE_P1,
//                     OTM8009A_CMD_DISPOFF,
//                     0x00);

//  OTM8009A_Init(OTM8009A_FORMAT, OTM8009A_ORIENTATION_LANDSCAPE);
  HAL_DSI_ShortWrite(&hdsi, 0, DSI_DCS_SHORT_PKT_WRITE_P1, 0x36, 0x48);
  HAL_DSI_ShortWrite(&hdsi, 0, DSI_DCS_SHORT_PKT_WRITE_P0, DSI_EXIT_SLEEP_MODE, 0x0);

Anyway at least it's doing something finally



I don't have any video stuff to try though I'm afraid.

Got to admit, this had made me even more eager to focus on Python and MicroPython as much as possible. It's freakin' horrible. Well, trying to get TouchGFX & STM32CubeIDE to play nicely together was anyway. I was probably screwing around with that 'til 2am

[luiHS]

I've been trying to do something with the STM32F769I-DISCO. Firstly trying to build an empty StemWin 'hello world'. I previously compiled the example projects, and they all work fine, but I couldn't get anything to display on the board that CubeMX/STM32CubeIDE had created.

Has the example of a video player for EVAL (JPEG_MJPEG_VideoDecoding) worked for you on Discovery and with the octagonal screen?.

There is one more difference between EVAL and Discovery. The EVAL uses a crystal and the internal oscillator for the clock signal, while the Discovery uses an external oscillator.

 

[carl0s]

I've been trying to do something with the STM32F769I-DISCO. Firstly trying to build an empty StemWin 'hello world'. I previously compiled the example projects, and they all work fine, but I couldn't get anything to display on the board that CubeMX/STM32CubeIDE had created.

Has the example of a video player for EVAL (JPEG_MJPEG_VideoDecoding) worked for you on Discovery and with the octagonal screen?.

There is one more difference between EVAL and Discovery. The EVAL uses a crystal and the internal oscillator for the clock signal, while the Discovery uses an external oscillator.

Hi. I haven't tried video examples on either screen.

I have had quite a bit of trouble getting consistent results to get this screen working with a fresh CubeMX project.
What I have realised is that, I must send the command to enable tearing effect (for which there is already an empty stemwin function - LCD_ReqTear(), otherwise I just get a dotty screen.

Code: [Select]

stemwin_wrapper.c: void LCD_ReqTear(void) { HAL_DSI_ShortWrite(&hdsi, 0, DSI_DCS_SHORT_PKT_WRITE_P1, DSI_SET_TEAR_ON, 0x0); } in the StEmWin code.
Then the DSIHOST must be set for 'refresh framebuffer: on tearing effect event, and external source ( DSI_TE_EXTERNAL).

[carl0s]

OK I'm getting somewhere now.

Previously, I was trying to figure out why I just got 'crap' when the unit was first powered on, but then the image was there was Reset was pressed.
Turns out it wasn't refreshing at all and was just showing the old static image after Reset.
That is because tearing effect needed to be set up properly on both ends (as per my edited post above).

I figured this out by testing a number count. The numbers didn't count

Now I have a big number counter. This is with DMA2D (Chrom-ART accelerator) disabled. StEmWin will make use of it when it's enabled, but so far that's giving me a black screen (maybe alpha issue).

Anyway, check it out: http://internetsomething.com/lcd/big_numbers_no-chrom-art.mp4

[luiHS]

OK I'm getting somewhere now.

Previously, I was trying to figure out why I just got 'crap' when the unit was first powered on, but then the image was there was Reset was pressed.
Turns out it wasn't refreshing at all and was just showing the old static image after Reset.
That is because tearing effect needed to be set up properly on both ends (as per my edited post above).

I figured this out by testing a number count. The numbers didn't count

Now I have a big number counter. This is with DMA2D (Chrom-ART accelerator) disabled. StEmWin will make use of it when it's enabled, but so far that's giving me a black screen (maybe alpha issue).

Anyway, check it out: http://internetsomething.com/lcd/big_numbers_no-chrom-art.mp4

That looks very good.
Is it an MJPEG video or a real-time animation?

I understand that you are trying to make an application using Cube, from scratch. Is that so?

Have you not tried with the examples already made that are in the example source package in en.STM32Cube_FW_F7_V1.15.0 ?, Specifically with the examples JPEG_DecodingUsingFs_DMA for Discovery, and JPEG_MJPEG_VideoDecoding for the EVAL evaluation board.

As soon as I have a free moment, I want to try those two examples, with the round screens, changing the initialization commands. In my case, what interests me most is the play of MJPEG videos and some JPEG images.

[carl0s]

That looks very good.
Is it an MJPEG video or a real-time animation?

Hi. It's just real-time generated text, with stEmWin (emWin free version for ST).
It's the second example after "Hello world" on page 56 of the 1300 page manual (https://www.segger.com/downloads/emwin/UM03001 )
It looks like this:

Code: [Select]

void GRAPHICS_MainTask(void) {

/* USER CODE BEGIN GRAPHICS_MainTask */
 /* User can implement his graphic application here */
  /* Hello Word example */
int i = 0;
    GUI_Clear();
    GUI_SetColor(GUI_WHITE);
    GUI_SetFont(&GUI_FontD80);
    while(1)
    {
      GUI_DispDecAt( i++, 40, 120, 4);
      if (i > 9999) {
      i = 0;
      }
    }
/* USER CODE END GRAPHICS_MainTask */
}

I am trying to start with minimal unknown code. I'm trying to work from a blank CubeMX build and ensure the peripherals work. I'm hoping that along the way I'll begin to understand what's what and recognise the various things in the generated code. Building the examples and altering them is probably going to be too difficult at this stage. I'm still trying to figure out what's involved in getting the Chrom-ART DMA2D controller to do something.

I understand that you are trying to make an application using Cube, from scratch. Is that so?

Yes exactly. It seems like an interesting thing to figure out how to go from nothing, to working screen, in minimal steps with point and click CubeMX

[carl0s]

Same thing is now super fast compared to before.
This is mostly down to CPU DCache and CPU ICache though. The DMA2D made some improvement before the CPU caches were enabled, but nothing like the same improvement that those caches made. I think this simple text demo isn't the best thing to benchmark DMA2D. That's more for shifting large blocks of pixel bytes. Anyway the DMA2D stopped hanging the system once I ticked the box to enable the global interrupt under NVIC. Another thing to read up on ..

http://www.internetsomething.com/lcd/big_numbers_superfast_with_cpudcache_cpuicache.mp4

[luiHS]

 
Do you know what the IC controller chip is on your round screen? I would like to start doing my tests with the same screen model. I have here three different models of screens, two are octagonal and one totally round (2.1 inches).

The controller chips are ST7796S, ST7701S and HX8379-C, fortunately I have the data sheet of the three, the one of the HX8379-C was quite difficult to get.

2.4 inches, octagonal outline, ST7796S controller chip, 320x320 pixel, Active area 60mm, TE available
2.47 inches, octagonal outline, HX8379-C controller chip, 480x480 pixel, Active area 62mm, TE not available
2.1 inches, round outline, ST7701S controller chip, 480x80 pixel, Active Area 53mm, TE available

[carl0s]

Do you know what the IC controller chip is on your round screen? I would like to start doing my tests with the same screen model. I have here three different models of screens, two are octagonal and one totally round (2.1 inches).

The controller chips are ST7796S, ST7701S and HX8379-C, fortunately I have the data sheet of the three, the one of the HX8379-C was quite difficult to get.

2.4 inches, octagonal outline, ST7796S controller chip, 320x320 pixel, Active area 60mm, TE available
2.47 inches, octagonal outline, HX8379-C controller chip, 480x480 pixel, Active area 62mm, TE not available
2.1 inches, round outline, ST7701S controller chip, 480x80 pixel, Active Area 53mm, TE available

Mine is the 2.4" which the manufacturer describes as 3.4", with ST7796S and 17 pin 0.3mm FPC connector, no touch.

Please could you post pictures of all 3 of your screens? Would be interesting to see the differences.

Also, TE can be sent as a MIPI packet, without its own pin. maybe that's what your 2.47" can do ?

[carl0s]

If your 2.47" screen is the one I've just found on the internet, then it's not MIPI-DSI is it? It has SPI and parallel RGB

If that's correct, then maybe you just use VSYNC.
https://kingtechgroup.en.alibaba.com/product/60791460985-807281342/HX8379_C_2_5inch_50pin_24bit_tft_lcd_display_module.html

Oh wait, I just found the MIPI ~2.47" 480*480 screen. I guess maybe you use DSI-TE, i.e. it comes as a DSI packet.

I'm going to order a couple of those because I'm interested in the increased resolution, although the lower brightness is a downer.

[luiHS]

These are my round screens, I have some smaller 1.2 and 1.39 inches, also MIPI.
I also bought two HDMI controller boards to connect the screens to the computer, for initial tests.

[carl0s]

Thanks for the pictures. I have a couple of the 480*480 HX8379-C coming to have a play with.
I think because they are GRAM-less, they are operated in Video mode, where hsync and vsync is sent along with raw pixel data, so no tearing effect line is used.
The 320*320 panel that I have been using (st7796) has a GRAM/framebuffer and works in adapted command mode.
Check ST application note AN4860.
This is the same as my 800*800 ILI9881C screen, which I have not used yet because it requires 3 lane MIPI.

[luiHS]

 
How are you doing with your tests with the round screens? I have already designed the PCBs to use the two 2.1 and 2.4 inch screens.

What I do notice when testing the 2.4 screen is that there is a certain Tearing effect, as if the TE signal was not being used, that makes when playing videos, when scenes with rapid changes come out, a certain cut is shown in the middle of the screen .

The 2.4 screen is much brighter than the 2.1 screen, and although it has less resolution, I think it looks better.

 





 

[carl0s]

Hey Lui

Great work. I can see the tearing too..
Is that stm32F769 with mjpeg video? I think it looks great.

I have done zero work really. I am still playing with SSD2828 bridge for the 4-lane display. No real reason other than to not give up. but it's just a part time hobby for me and I'm just too tired in the evenings lately to do anything

I agree the 320*320 Panasys screen is great and bright.
What about the 480*480 one with the 0.2mm pitch connector? I have a couple of those, but no breakouts for the connector yet and not bothered about having a PCB made just yet.

[carl0s]

Are you sending the TE enable DSI cmd? (DSI_SET_TEAR_ON)

I have found that I don't get any screen output without it.. not sure if I mentioned that on here previously.

[luiHS]

Hey Lui

Great work. I can see the tearing too..
Is that stm32F769 with mjpeg video? I think it looks great.

I have done zero work really. I am still playing with SSD2828 bridge for the 4-lane display. No real reason other than to not give up. but it's just a part time hobby for me and I'm just too tired in the evenings lately to do anything

I agree the 320*320 Panasys screen is great and bright.
What about the 480*480 one with the 0.2mm pitch connector? I have a couple of those, but no breakouts for the connector yet and not bothered about having a PCB made just yet.

Yes, my PCB boards are with the 769, in addition to an SDRAM, SD card holder and backlight voltage booster.

About the connectors, the 320*320 2.1-inch screen needs a 0.5 mm pitch connector, and the 480*480 2.4-inch screen needs a 0.3 mm pitch connector. Both connectors available in Mouser.

[luiHS]

Are you sending the TE enable DSI cmd? (DSI_SET_TEAR_ON)

I have found that I don't get any screen output without it.. not sure if I mentioned that on here previously.

I will check it, I do not remember now.

[carl0s]

Hey Lui

Great work. I can see the tearing too..
Is that stm32F769 with mjpeg video? I think it looks great.

I have done zero work really. I am still playing with SSD2828 bridge for the 4-lane display. No real reason other than to not give up. but it's just a part time hobby for me and I'm just too tired in the evenings lately to do anything

I agree the 320*320 Panasys screen is great and bright.
What about the 480*480 one with the 0.2mm pitch connector? I have a couple of those, but no breakouts for the connector yet and not bothered about having a PCB made just yet.

Yes, my PCB boards are with the 769, in addition to an SDRAM, SD card holder and backlight voltage booster.

About the connectors, the 320*320 2.1-inch screen needs a 0.5 mm pitch connector, and the 480*480 2.4-inch screen needs a 0.3 mm pitch connector. Both connectors available in Mouser.

Cool.
Yes I have the connectors.

[luiHS]

 
I receveid my new PCB for the 2.1 inches round screen. Ready to assemble and test.

Next week I will receive PCB for the 2.4 inches, I hope I can solve the TE problem, its a good round screen, good size and very bright, but the tearing effect spoils something when playing videos with fast movements.

[carl0s]

 In your video it is the 2.4" screen already. Ha, I wondered about that.. the connector is going under the piece of paper isn't it?

[luiHS]

In your video it is the 2.4" screen already. Ha, I wondered about that.. the connector is going under the piece of paper isn't it?

The first tests were with an HDMI controller board, to check the resolution and brightness of each screen.

Now I go with the PCBs that have all the electronics based on the 769, and connect with 3 wires, 2 wires for 5 volt power supply and a third wire for a serial port to control which videos are played.