• AVR Freaks

Hot!Double Buffer sync [solved]

Author
darren
Starting Member
  • Total Posts : 53
  • Reward points : 0
  • Joined: 2010/10/02 04:31:04
  • Location: 0
  • Status: offline
2019/10/15 04:20:14 (permalink)
0

Double Buffer sync [solved]

Hi,
 
I 'm using the PIC24FJ256DA210 with the MLA library. I came in need to use the double buffering. When I enabled it, the displayed didn't result as supposed to. I tried on the demo app and the result is the same (image attached).  Could this be related to wrong sync from the frame buffer to the draw buffer?
 
Note: My display is native landscape, 320x240. 
 
Thanks
post edited by darren - 2019/10/16 08:03:53

Attached Image(s)

#1

10 Replies Related Threads

    Mysil
    Super Member
    • Total Posts : 3405
    • Reward points : 0
    • Joined: 2012/07/01 04:19:50
    • Location: Norway
    • Status: offline
    Re: Double Buffer sync 2019/10/15 05:48:38 (permalink)
    0
    Hi,
    Double buffering may be tricky.
    It make updating the visible image faster, but require more RAM memory, more code and more processing,
    to keep two frame buffers with synchronized contents.
     
    It is my impression that double buffering in MLA graphics is not well tested, and may contain bugs.
     
    Many displays and in 320x240 format are designed in portrait format.
    Display controllers are usually able to transform between landscape frame buffer format and portrait display scan format, but how this is done may be individual for each display driver.
     
        Mysil
    #2
    darren
    Starting Member
    • Total Posts : 53
    • Reward points : 0
    • Joined: 2010/10/02 04:31:04
    • Location: 0
    • Status: offline
    Re: Double Buffer sync 2019/10/16 00:09:56 (permalink)
    0
    Hi Mysil,
     
    Thanks for your reply. The display I'm using is designed in landscape format. Thus, I changed the horizontal and vertical resolutions accordingly in the system_config.h file. This, together with the display timings (and commenting out GFX_CONFIG_DOUBLE_BUFFERING_DISABLE in gfx_config.h) is the only changes I've made to the demo application, thus I can't see how any of my changes could bring up this issue.  
     
    Have you ever managed to use double buffering in the MLA library? If so, are there any settings I should take care to implement (maybe related to frame and drawing buffers sync)?
    #3
    Jan Audio
    Junior Member
    • Total Posts : 92
    • Reward points : 0
    • Joined: 2018/09/24 08:12:24
    • Location: 0
    • Status: offline
    Re: Double Buffer sync 2019/10/16 01:42:50 (permalink)
    0
    320 x 240 x 2 buffers x 4 or 3 bytes for RGB info.
    Is there any PIC chip that has this memory ?
    #4
    darren
    Starting Member
    • Total Posts : 53
    • Reward points : 0
    • Joined: 2010/10/02 04:31:04
    • Location: 0
    • Status: offline
    Re: Double Buffer sync 2019/10/16 03:39:54 (permalink)
    0
    Hi Jan,
     
    I was just going to reply about this. You're right. I was still trying to use internal memory for double buffering :/. I have the DM240312 development board with the IS61LV25616AL 512kBytes SRAM. I'm trying to configure the MLA library to use the external SRAM for buffering but I'm having the same results as in my previous post. Are there any specific settings I need to set apart from defining USE_16BIT_PMP and USE_GFX_EPMP in system_config.h?

     

    post edited by darren - 2019/10/16 08:03:24
    #5
    NKurzman
    A Guy on the Net
    • Total Posts : 17918
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: Double Buffer sync 2019/10/16 05:53:26 (permalink)
    0
    1. Did you price that external RAM chip?
    2. The Graphics library in Harmony was based(copied?) from the PIC24 code. Double buffering did not work for me, and looked like it would need some real effort to fix it. So it it is possible it never worked properly on the pic24. Or Harmony botched the code.

    That said I got good results by only updating data that changed. This minimized the visible artifacts.
    #6
    darren
    Starting Member
    • Total Posts : 53
    • Reward points : 0
    • Joined: 2010/10/02 04:31:04
    • Location: 0
    • Status: offline
    Re: Double Buffer sync 2019/10/16 06:07:35 (permalink)
    0
    Hi NKurzman,
     
    Thanks for the reply. I decided that I needed double buffering when I tried to implement scrolling. I made a grid on a black background using rectangleDraw and only update the grid lines by erasing the rectangles (draw them with the background color) and draw them again at the new position. Still some flicker is shown. It is actually not exactly flicker, but more like screen tearing. Double buffering seems to solve the issue but I'm having the type of artifacts I shown in the first post. 
     
    Using an external RAM with the PIC24F is surely more costly than using a PIC32 with larger memory, but I wanted to confirm that double buffering did indeed solve the issue before start buying PIC32F development boards. I'll give it some more time, maybe someone did manage to implement double buffering. If not, I think I would go for PIC32.
     
    Back to the primary objective, do you know about standard techniques used to remove screen tearing during scrolling? Is double buffering the proper solution?
     
    Thanks
     
     
    #7
    NKurzman
    A Guy on the Net
    • Total Posts : 17918
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: Double Buffer sync 2019/10/16 06:33:37 (permalink)
    0
    The tear is caused because the screen is being redrawn during an update so part of the old and new screens are visible at the same time. Double buffering is one solution, another would be only updating when the screen is not refreshing. That would be much more elaborate. You could fix the double buffering. The concept is simple.
    Copy the current screen to buffer two. Make the changes, then swap the screens during the blanking interval. The copy would need to be HW assisted due to amount of ram to be copied.

    If you switching to a pic32 and harmony, it is using ARIA now. The library is totally different. You may not be able to reuse anything from your pic24 project.
    My point on that SRAM is that it is over 10 dollars. And external GFX chip is cheaper.
    If your plan is to move to a PIC32 and Harmony, you probably want to just do it.
    Harmony is its own learning experience. By they Have a graphical tool for doing the graphics library.
    #8
    darren
    Starting Member
    • Total Posts : 53
    • Reward points : 0
    • Joined: 2010/10/02 04:31:04
    • Location: 0
    • Status: offline
    Re: Double Buffer sync 2019/10/16 08:01:04 (permalink)
    0
    Finally found the issue. I left jumper J11 in its default position, thus PMA17 was not connected to the external RAM. Double buffering is now working correctly and the screen tearing during scrolling is removed. 
     
    Considering cost, I still think I would go for the PIC32 and start with Harmony. Having their own graphical tool make things easier too. At least, I now know that double buffering will solve these kinds of issues.
     
    Thanks for all the help. Hope this thread will be useful to someone else. 
    #9
    NKurzman
    A Guy on the Net
    • Total Posts : 17918
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: Double Buffer sync 2019/10/16 09:35:07 (permalink)
    0
    the IS61LV25616AL is only 3-4.00 USD in quantity.   So it maybe OK for you.  I have a 480*272 so that needed a Bigger Part.
    #10
    darren
    Starting Member
    • Total Posts : 53
    • Reward points : 0
    • Joined: 2010/10/02 04:31:04
    • Location: 0
    • Status: offline
    Re: Double Buffer sync 2019/10/17 02:38:37 (permalink)
    0
    You're right. I checked the PIC32MX, did some costing and actually, using the PIC32MZ may be slightly more expensive than the PIC24+ext. RAM. The product owner is anyway interested in keeping the door open for future more advanced graphics which, as far as I know, are only possible using Harmony. In this case, the PIC32 would be the option. 
    #11
    Jump to:
    © 2019 APG vNext Commercial Version 4.5