AnsweredHot!MPLAB Harmony 2.05 GFX

Page: 12 > Showing page 1 of 2
Author
bblessing
Super Member
  • Total Posts : 596
  • Reward points : 0
  • Joined: 2008/12/04 06:44:21
  • Location: Cincinnati, OH
  • Status: online
2018/01/03 08:55:17 (permalink)
0

MPLAB Harmony 2.05 GFX

Background: MPLAB X IDE v4.05, XC32 v1.44B, Harmony v2.05, PIC32MZ2064DAG176, Newhaven NHD-4.3-480272EF-ASXN#-T display
 
With the usual junk out of the way, let me start by saying that it appears that quite a few things have been fixed. Unfortunately, the orientation issue with the GPU has not been fixed. Exhibit A would be the libnano2D_hal.c file. There are six references to the following: N2D_0. It would seem to me that the orientation is hard-coded to 0°. I have fixed this for my case by just changing it to 90°. This would not have worked well with 2.04 as the images would have been "fuzzy". This works with just a solid blue background, but images are messed up. I can't get them to display in the proper place. It seems they are in 0° mode as well.
 
I'm really digging the preprocessing part of the Image Assets dialog in MHGC. I would dig it more if it worked. Padding doesn't seem to help either. Dropping back and punting to the old method doesn't seem to work.
 
Am I out of luck with the GPU again? It would be really nice to use the GPU with 90° (portrait mode). Can somebody at Microchip please try and get a simple screen to display with an image that is centered and oriented correctly at 90°? The caveats are that the GPU should be enabled and the images preloaded into DDR as per the new method in MHGC. If you can get this to work, let me know what the workaround is or what I'm doing wrong.
 
Edit 1: I'm having trouble with my image because I have Direct Blit checked under Image Assets. Get rid of that and it seems fine.
post edited by bblessing - 2018/01/03 09:41:56
#1
jiggoly
Junior Member
  • Total Posts : 79
  • Reward points : 0
  • Joined: 2016/01/19 15:02:48
  • Location: Spain
  • Status: offline
Re: MPLAB Harmony 2.05 GFX 2018/01/03 11:10:13 (permalink)
0
I´ve been checking your config, and as you says at the end it works fine only 1 image as a background, but if you include more images on the same layer and try to preload into ddr, the images are out of place as they would be set to 0º.
#2
bblessing
Super Member
  • Total Posts : 596
  • Reward points : 0
  • Joined: 2008/12/04 06:44:21
  • Location: Cincinnati, OH
  • Status: online
Re: MPLAB Harmony 2.05 GFX 2018/01/04 12:26:05 (permalink)
0
So I dropped back to the basics to see what is and is not working. For some reason, touch wasn't working. If I start a fresh project without importing anything I can press buttons with no problems in 0 or 90 degree mode. Hmmm. It makes me wonder if I should just start over and bolt things in as I go.
 
One thing I did notice was that using the GPU produces artifacts on layers other than the top layer. Granted, this was with my imported settings, but it's disconcerting for one major reason: speed. With a simple project that has nothing more than two buttons on the screen, here is the difference: 9 ms round robin time for no GPU and 4 ms with the GPU (actually the time without is rounded down and the time with is rounded up, so the difference is even larger). What I mean by round robin time is that I use the core timer to measure how quickly it takes to get back to a given spot in code. It also looks for the maximum. The buttons are of size (100,63). As you can see with this simple example, the GPU smokes the traditional method. Still, 4 ms is a pretty long delay for a button press.
 
From here, my goal is to reduce the amount of time that it takes to click a button. I probably should have done this with 2.04, but better late than never. For starters I tried to run this in RGB_888 mode instead of RGBA_8888, my thinking was that if each pixel was only 3/4 the size of what it was previously then it would move that much faster. Additionally, I figured that alpha blending was done on a layer basic to take advantage of the hardware alpha blend so individual pixel alpha values wouldn't matter. No dice. In fact, the screen looked like crap so I dropped back and moved to RGBA_8888 again as I'll need alpha blending for my project. Interesting enough, it dropped the button press time to under 1 ms: ~960 us.
 
Trying things as I go, I forgot that I have to have double buffering so I enabled that. Instantly the button presses took longer: ~10 ms. I then set each button to allow for local redraw optimization. This actually made things WORSE: 12.7 ms.
 
I set each button for draw once, but the interesting thing that this did was simply make both buttons disappear on press. It did speed things up as a press took just under 6 ms. Force Opaque didn't seem to do much.
 
Of the other options, I tried putting a panel behind one of the buttons and adding the button as a child. I turned off all optimizations on the button. A press took 18 ms. This isn't surprising as it probably made the whole tree redraw, which is larger because of the panel. From there I enabled local redraw on the child button. 15 ms per press. Add draw once and the press becomes 14 ms. Remove local redraw and it's 10 ms.
 
After that I started adding optimizations to the panel, but not the child button. 15 ms with only local redraw, 14 ms with only draw once. Having both didn't seem to do much.
 
At this point, it seemed like 9-10 ms is the best that I could do. Another option that I exercised was changing the preemption level. This caused me problems with my old LCC driver, but that was a REALLY slow (comparatively speaking) processor/external RAM combination. Setting the preemption level to 2, which implies that the process is preempted after each widget's draw step completes, helps significantly: 6 ms per press with all other optimization turned off. I have not seen a drop in drawing performance at this point, so I think I'll keep this option. One thing that is strange, though, is that the first time I press a button it takes quite a bit of time (176 ms) for a round robin. I don't believe this is a bug in my round robin logic, as the button press seems slow. After that all is well.
#3
bblessing
Super Member
  • Total Posts : 596
  • Reward points : 0
  • Joined: 2008/12/04 06:44:21
  • Location: Cincinnati, OH
  • Status: online
Re: MPLAB Harmony 2.05 GFX 2018/01/04 13:44:41 (permalink)
0
Since I'm hamstrung here and can't use the GPU due to my need for 90° mode, I'm forced to find clever ways to make this go faster. I may be screwed as far as a button press causing delays in my code of roughly 6 ms. This seems to pale in comparison to the delays that I incur when shifting panels in/out of the viewing area with a laWidget_SetX call. My set up is simply two gradient widgets (sales wants gradient backgrounds), one has two buttons as children, the other has one button. One gradient widget is set at (0,0) and the other is at (272,0); since the screen's physical viewing area in 90° mode is (272,480) the second gradient widget is effectively invisible. A button on either gradient will shift the second gradient in and out of view. It does this by changing the X value upon release.
 
It takes 115 ms and 169 ms, respectively to shift these gradients in/out of view. These are completely unacceptable delays in a super loop environment. I tried to reduce the maximum layer count down to 1, which didn't help. My next thought is to make a layer nothing but a gradient, a wallpaper of sorts. I can then shift in panels with no background on a higher layer. This takes care of the delay, but when I shift a panel in and then out its "image" remains. I'm not quite sure how to tackle this.
 
#4
bblessing
Super Member
  • Total Posts : 596
  • Reward points : 0
  • Joined: 2008/12/04 06:44:21
  • Location: Cincinnati, OH
  • Status: online
Re: MPLAB Harmony 2.05 GFX 2018/01/04 14:58:48 (permalink)
0
Ok, I'm throwing my hands up in exasperation over this. I NEED a gradient background. This works if I put that on a separate layer. The layer on top of that has two panels, both of which have no background, but buttons. One panel is completely off the screen and that is reflected when I run it. If I try and move the visible panel off screen, the images of the two buttons remain. It's like the panel doesn't budge, but I know that it does as you can't press it anymore.
 
Now, if I want to move JUST a button on and off screen it works just fine. I also don't have a major penalty in time delay. I have tried a bunch of different things to try and move the entire panel, but none of them help. Can anyone from Microchip weigh in? The drawing delays are simply non-starters and I feel like my technique is sound: one layer has a gradient and the layer above it has "no background" panels that can be shifted in and out reducing the total area that needs to be drawn.
 
For the record, I've studied the coffee maker demo and there doesn't seem to be anything there that would change things. It uses calls to translate and setposition on panels, which is really no different than what I'm doing.
#5
bblessing
Super Member
  • Total Posts : 596
  • Reward points : 0
  • Joined: 2008/12/04 06:44:21
  • Location: Cincinnati, OH
  • Status: online
Re: MPLAB Harmony 2.05 GFX 2018/01/04 16:17:27 (permalink)
0
I'm beginning to think there is no sneaky way out of these delays. The delays are greatly reduced if I have a single layer with the following descendancy: gradientWidget->panelWidget->buttons. If the panel widget is just large enough to cover the buttons then the move is much faster. In my case, it knocked it down to 15 ms. Still, I will have a much larger set of buttons to work with so I can't count on that time. It would be nice to know what is causing these monstrous delays and, yes, 15 ms is a monstrous delay for a non-blocking system. If everything is already drawn the round robin time is 28 us.
#6
Ed@Microchip
Junior Member
  • Total Posts : 41
  • Reward points : 0
  • Joined: 2017/04/06 09:39:29
  • Location: 0
  • Status: offline
Re: MPLAB Harmony 2.05 GFX 2018/01/04 16:17:39 (permalink)
0
bblessing
Ok, I'm throwing my hands up in exasperation over this. I NEED a gradient background. This works if I put that on a separate layer. The layer on top of that has two panels, both of which have no background, but buttons. One panel is completely off the screen and that is reflected when I run it. If I try and move the visible panel off screen, the images of the two buttons remain. It's like the panel doesn't budge, but I know that it does as you can't press it anymore.
 
Now, if I want to move JUST a button on and off screen it works just fine. I also don't have a major penalty in time delay. I have tried a bunch of different things to try and move the entire panel, but none of them help. Can anyone from Microchip weigh in? The drawing delays are simply non-starters and I feel like my technique is sound: one layer has a gradient and the layer above it has "no background" panels that can be shifted in and out reducing the total area that needs to be drawn.
 
For the record, I've studied the coffee maker demo and there doesn't seem to be anything there that would change things. It uses calls to translate and setposition on panels, which is really no different than what I'm doing.




Hi bblessing - what is the background of the second layer (the one with the buttons)? Try assigning a color scheme (e.g., 'ClearScheme') with a background color of 0x0. This tells the library to fill the layer with a clear background when its contents change. If the layer has no background, the library will not clear (fill) the layer background as it doesn't have a 'color' to fill the layer with.
 
#7
bblessing
Super Member
  • Total Posts : 596
  • Reward points : 0
  • Joined: 2008/12/04 06:44:21
  • Location: Cincinnati, OH
  • Status: online
Re: MPLAB Harmony 2.05 GFX 2018/01/04 18:47:59 (permalink)
0
Ed,

Thanks! I'll give that a shot tomorrow when I'm at my desk again. It does beg the question: with RGBA_8888 and 480x272 pixels, how fast can one reasonably expect to change "screens"? As you can imagine, most projects will have a menu scheme of some sort. That means users will be pressing buttons and navigating through screens. Supposing no animation and images preloaded to ddr, are we talking 10 ms worst case scenario between calls to App_Tasks? 50? 150?

There are tons of variables, I know, but I'm just trying to get everything sorted prior to tackling the menu system again. I just want to be sure that going forward I've done everything I could to minimize long drawing delays.
#8
bblessing
Super Member
  • Total Posts : 596
  • Reward points : 0
  • Joined: 2008/12/04 06:44:21
  • Location: Cincinnati, OH
  • Status: online
Re: MPLAB Harmony 2.05 GFX 2018/01/05 06:40:38 (permalink)
0
Ed,
 
    Your technique did in fact work: set the scheme background to 0 for its RGBA value. Here is my setup:
  • Two layers, each with two buffers
  • Layer 1 is on top of Layer 0
  • 90° mode and RGBA_8888
  • Layer 0 contains only a GradientWidget of size (272,480) at (0,0), it therefore takes up the entire screen as a background
  • Layer 1 contains a PanelWidget as a child of (272,100) at (0, 380)
  • The PanelWidget contains two child buttons each of size (76,76)
  • The buttons are at (10,10) and (186, 10)
  • The button locations are obviously with respect to the PanelWidget's origin
  • I don't have any optimizations on except for the Preemption Level being set to LEVEL_2
  • I'm not using the GPU, as it's turned off through MHC.
  • This project only does a few other things: modbus on RS485 and a MCP79520 chip over SPI
    From there, I simply move the entire PanelWidget from (0,380) to (272,380). This effectively moves the panel off of the screen. As you know this is how one would, at least historically, simulate changing menu screens. This all works very well EXCEPT for the time it takes to do it. My round robin timer clocks this move at roughly 41 ms. If I make the panel the same size as the layer (272,480), the time is roughly 169 ms. If don't make ANY changes to the screen the round robin timer worst case scenario is excellent: 28 us.
 
    My question, now that I'm not in a funk after hours of testing different things in vain yesterday, is how do I get these delays to go down and is this the best approach to simulating navigation through menu screens? I put that in bold because I do realize most posts can get a little verbose and you guys need to cut to the chase. Clearly the 169 ms delay is the time it takes to repaint the entire layer. Ideally, this number should be knocked to down to a few ms or less.
 
    Would some of the things help:
  • Get rid of double buffering, as single buffering seems pretty smooth with this processor
  • Mess around with local redraw, draw once, and force opaque; there are a lot of combinations here so some guidance would be greatly appreciated
  • Start tossing out default settings in MHC like Bounds clipping, color conversion, etc.
  • Can entire portions of the tree, like a panel and its children, be preloaded into DDR?
  • DDR Memory is running at 200 MHz as per the coffee maker demo settings, maybe boost this to the max of 400?
post edited by bblessing - 2018/01/05 09:18:04
#9
bblessing
Super Member
  • Total Posts : 596
  • Reward points : 0
  • Joined: 2008/12/04 06:44:21
  • Location: Cincinnati, OH
  • Status: online
Re: MPLAB Harmony 2.05 GFX 2018/01/05 10:45:07 (permalink)
0
So with all of this in mind, I can drop the setup above down to 7 ms IF I set Draw Once for Layer 1. Doing this means that the buttons will not clear out, but the speed improvement is enormous. Here is another question then. If I have the gradient widget background on one layer, and I use the ClearScheme technique above to make the second top layer appear like it has no background, and the panel that contains the buttons has no background, then why does the renderer have to redraw those areas that have not changed? To the user, it appears like there are only two buttons on a gradient background. When those buttons are moved out of the screen, via moving the entire panel, then it's clear the renderer is redrawing the entire panel area when only the areas that the buttons appear need to change. How do I make the driver "know" that only the button areas need to change, even though I'm moving the entire panel? Does that make sense?
#10
bblessing
Super Member
  • Total Posts : 596
  • Reward points : 0
  • Joined: 2008/12/04 06:44:21
  • Location: Cincinnati, OH
  • Status: online
Re: MPLAB Harmony 2.05 GFX 2018/01/05 12:52:34 (permalink)
0
I've dropped down to a single buffer for each layer AND I have enabled the GPU. This yields worst case times of 3 ms, which I can live with. The problem now is the artifacts that the GPU leaves with the buttons. If this problem is cleared up I think we will have a winner, as moving a screen sized panel would take about 14 ms. Since I would be moving smaller panels, I should be able to keep everything under 10 ms.
 
Can anyone at Microchip suggest where to look to fix the GPU driver? Is it possible there is a bug in the GPU itself?
#11
Ed@Microchip
Junior Member
  • Total Posts : 41
  • Reward points : 0
  • Joined: 2017/04/06 09:39:29
  • Location: 0
  • Status: offline
Re: MPLAB Harmony 2.05 GFX 2018/01/05 12:53:44 (permalink)
0
Hi bblessing,
 
   I am hoping that having the GPU work at 90 degree orientation will give you the performance boost without having you jump a lot of hoops in your design, so I have attached a sample v2.05 MHGC project that has 2 screens at 90deg, both with 2 double-buffered layers using PNG images preprocessed as RAW in DDR. There is a button that is used to switch between the screens.
 
   There were changes needed to be made to the 2D GPU wrapper (libnano2D_hal.c) to fix the orientation - the same changes that was posted here: http://www.microchip.com/forums/m1010433.aspx. I have also attached the updated wrapper file for v2.05. This is a temporary patch while we decide on a cleaner fix for v2.06.
 
   Please take a look and see if these would help get your project running with the GPU.
 
Thanks,
 
Ed
#12
Ed@Microchip
Junior Member
  • Total Posts : 41
  • Reward points : 0
  • Joined: 2017/04/06 09:39:29
  • Location: 0
  • Status: offline
Re: MPLAB Harmony 2.05 GFX 2018/01/05 12:59:17 (permalink)
0
bblessing
I've dropped down to a single buffer for each layer AND I have enabled the GPU. This yields worst case times of 3 ms, which I can live with. The problem now is the artifacts that the GPU leaves with the buttons. If this problem is cleared up I think we will have a winner, as moving a screen sized panel would take about 14 ms. Since I would be moving smaller panels, I should be able to keep everything under 10 ms.
 
Can anyone at Microchip suggest where to look to fix the GPU driver? Is it possible there is a bug in the GPU itself?




Hi bblessing - Looks like your post came in right when I was about to post my previous reply. Good to know that you are now able to use the GPU. What kind of artifacts are you seeing? The project that I attached in my previous post uses images for buttons and I didn't see any artifacts.
 
#13
bblessing
Super Member
  • Total Posts : 596
  • Reward points : 0
  • Joined: 2008/12/04 06:44:21
  • Location: Cincinnati, OH
  • Status: online
Re: MPLAB Harmony 2.05 GFX 2018/01/05 13:16:27 (permalink)
0
Ed,
 
    Thanks again for replying so swiftly and, more importantly, putting up with me getting more surly as the day goes on :-). I will try this immediately. I am using the stock buttons, so perhaps image buttons will help. In fact, I should probably go ahead and do that as they'll be images anyway.
 
Edit: While typing and waiting for this to compile and load, I typed up the above. I am still seeing artifacts on the buttons. I will attempt image buttons instead. Is it possible that the LCD that I'm using isn't capable of doing this or the GPU is too fast for it?
#14
Ed@Microchip
Junior Member
  • Total Posts : 41
  • Reward points : 0
  • Joined: 2017/04/06 09:39:29
  • Location: 0
  • Status: offline
Re: MPLAB Harmony 2.05 GFX 2018/01/05 13:23:09 (permalink)
0
Hi bblessing - I'm seeing some flickering/shaking of the buttons/images if I put them on the third (topmost) layer. It looks like this is due to bus contention between the GPU and the GLCD. I had the GLCD pixel clock running at 25MHz (Timing Prescaler = 4, in Display Manager), so I lowered it down to 16.6MHz (Timing prescaler = 6) and that seemed to help and I don't see the flickering. I'm not sure if the artifacts that you are seeing is the same as what I saw, but you can try lowering down the GLCD pixel clock and see if it helps with the artifacts you see.
#15
bblessing
Super Member
  • Total Posts : 596
  • Reward points : 0
  • Joined: 2008/12/04 06:44:21
  • Location: Cincinnati, OH
  • Status: online
Re: MPLAB Harmony 2.05 GFX 2018/01/05 13:37:15 (permalink)
0
Ok, so you're using a different chip than I am (PIC32MZ2064DAG169, not that it should matter). I tried to add an image via Graphics Composer (GC), but it's crashing my program. The editor looks correct with my image in place of the button's stock, released image. All that I did was go to Asset->Images, add an image (PNG is default), and enabled preprocessing. After that I selected the image as the released image for one of the buttons. It's crashing at this point. Do I have to add the old method of preloading the images in App_Init or something?
 
Edit: I have a ton of memory set up for the heap (208,400). It's reflected in the estimator.
 
Edit2: How did you get the Asset->Images dialog to set the image memory address correctly? It defaults to 0 and I added a high number (A88F1820, like I saw in your configuration) and now it works in the sense that it's not crashing. However, the images have artifacts.
post edited by bblessing - 2018/01/05 13:47:01
#16
Ed@Microchip
Junior Member
  • Total Posts : 41
  • Reward points : 0
  • Joined: 2017/04/06 09:39:29
  • Location: 0
  • Status: offline
Re: MPLAB Harmony 2.05 GFX 2018/01/05 13:53:15 (permalink)
0
MHGC does some things automatically now if pre-processing is enabled, but the address to which the pre-processed images are stored in DDR have to be manually put it. This is the "Address" property in the "Preprocessing" section of the image asset properties window.
 
The addresses need to be manually calculated, as we are still working on an automatic way to calculate this in MHGC. So I just use a spreadsheet that calculates the address for each image. You may also need to enable "Padding".
 
I have attached the spreadsheet that I used for the project that I sent you, if you would like to use it. I put in the "Orig Width" and "Orig Height" for each image and the spreadsheet calculates the start addresses. The first image starts near the end of the 6th frame buffer (at 0xa88D1800).
 
 
post edited by Ed@Microchip - 2018/01/05 14:02:46
#17
bblessing
Super Member
  • Total Posts : 596
  • Reward points : 0
  • Joined: 2008/12/04 06:44:21
  • Location: Cincinnati, OH
  • Status: online
Re: MPLAB Harmony 2.05 GFX 2018/01/05 14:15:52 (permalink)
0
Padding didn't help; I'm still getting the artifacts, even with the image. FWIW, the artifacts seem random. I've attached my configuration. Let me know if anything jumps out at you. I'm excited about this as we're so close!!! Just this one last hurdle.
#18
Ed@Microchip
Junior Member
  • Total Posts : 41
  • Reward points : 0
  • Joined: 2017/04/06 09:39:29
  • Location: 0
  • Status: offline
Re: MPLAB Harmony 2.05 GFX 2018/01/05 14:36:24 (permalink)
0
Hi bblessing - I tried your config and as far as I can tell, the image looks okay. See attached image. What do the artifacts look like? Does it only show up if you're using the GPU?

Attached Image(s)

#19
bblessing
Super Member
  • Total Posts : 596
  • Reward points : 0
  • Joined: 2008/12/04 06:44:21
  • Location: Cincinnati, OH
  • Status: online
Re: MPLAB Harmony 2.05 GFX 2018/01/05 14:38:10 (permalink) ☼ Best Answerby MikeinAZ 2018/01/05 15:22:19
0
Ok, here is one for you: it must be that the GPU is just that fast. I dropped the pixel clock back on my LCD and the button that DOES NOT have an image seems to be displaying without artifacts. This is very strange as the gradient, at least to my eyes, looks perfect. Wouldn't the GPU be drawing that?
 
Quick edit: VICTORY!!!!!!! I reduced the PLL on my internal DDR memory. The coffee maker demo is at 200 MHz for 2.05, but was 220 MHz for 2.04. I scaled this back to 150 MHz, but left my preemption level at 2. Everything seems to work perfectly and I have no delay worse than 3 ms. Now I need to tinker around to figure out just how fast I can go without upsetting the apple cart. Ed, thank you very, VERY much!!!
#20
Page: 12 > Showing page 1 of 2
Jump to:
© 2018 APG vNext Commercial Version 4.5