Search

Technical Discussion Group Forum

This forum is provided for user discussion. While Beacon EmbeddedWorks support staff and engineers participate, Beacon EmbeddedWorks does not guarantee the accuracy of all information within in the Technical Discussion Group (TDG).

The "Articles" forums provide brief Articles written by Beacon EmbeddedWorks engineers that address the most frequently asked technical questions.

To receive email notifications when updates are posted for a Beacon EmbeddedWorks product download, please subscribe to the TDG Forum of interest.

TDG Forum

PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 25 Feb 2006 02:36 PM by  mikea@logicpd.com
LH7A404 and CSTN LCD based on vxWorks winML
 3 Replies
Sort:
You are not authorized to post a reply.
Author Messages
samiol@126.com
New Member
New Member
Posts:


--
04 Feb 2006 08:55 PM
    Hi,
    I use a VGA, CSTN LCD to interface the LH7A404. Select the vxWorks as RTOS. Normally, the LCD image is right. But if I access the others memory such as flash, CPLD space, the image would show chaos.
    The LCDframe buffer is in the SDRAM malloced by cacheDMAmalloc(). The SDRAM is bufferable and cacheble, and the flash or CPLD memory space is not bufferable and not cacheable.
    I guess this problem is bus conflict, but the LH7A404's UG indicate the LCD AHB has priority to access the SDRAM.
    Pls help me to resolve the problem.
    Thank you!
    Best regards.
    thinkmaster@gmail.com
    New Member
    New Member
    Posts:


    --
    04 Feb 2006 10:01 PM
    Sharp SMA has on their website, an Excel spreadsheet that will help you calculate the appropriate bus threshholds for LCD usage.
    samiol@126.com
    New Member
    New Member
    Posts:


    --
    05 Feb 2006 10:23 PM
    I do not understand the document.
    How do I calculate for lh7a404 using it ?
    CPU clk=200MHz, LCD frame freq= 70Hz.
    How do I set the various clk rate for LH7A404 ?

    Thank you!
    Best regards.
    mikea@logicpd.com
    New Member
    New Member
    Posts:


    --
    25 Feb 2006 02:36 PM
    I assume this is a Dual display, where you have actually two 320x480 displays that you are writting too. (You essentially set up two frame buffers)
    If you want to know more about what I'm talking about, read Sharp's LH7A404 User Guide and the section about Dual-Panel Color STN operation.

    We have found that the LCD controller will begin tearing with external bus use when using this type of display and being so large (VGA). The data latency requirements are much heavier than normal, especially if you are attempting to run at 16bpp, which I'm not sure you are or not.

    The actual problem is related to SDRAM data latency when the LCD controller needs data and something else also wants to use the bus. (Like PCMCIA, Flash, .etc.)

    These are some things to try to do in this situation, directly from Sharp's Engineers. I probably won't be able to help you implement them, unless you want to set up a support contract with Logic. You could check out Sharp's support or local contact if you want to work it through them.
    Quote:

    Here are some things to try:
      - Use 8bpp instead of 16bpp
      - Make sure to minimize your front and back Hsync and Vsync porches, although not beyond spec. (If you are hitting the LCD spec, don't try your luck with incorrect settings)
      - Using CAS2 SDRAM will help, try running the card engine with CAS2 timings (it might already be there)
      - Make sure you are running with full bus speed (100MHz) when that display is on
      - Try relocating the frame buffer to a different location in memory (if possible), if possible, place it in bank 0
      - Make sure a frame buffer doesn't cross a SDRAM bank boundary (boundaries are at 0xc000, 0xc080, 0xc100, and 0xc180)
      - Make sure the upper and lower frame buffers are located in the same SDRAM bank
      - Avoid the use of the DMA M2M operation with large block sizes
      - Try using internal SRAM for part of your frame buffer. You can get internal SRAM to work partially with this by mapping internal SRAM as a 256MByte bank from 0xb0000000 to 0xbfffffff, and then setting the upper frame buffer to location 0xBFFFEC00 overflowing into address 0xC0000000 (SDRFAM bank 0). This would help alot with the problem. This would have the unfortunate side effect of requiring you to remap your interrupt vector table (routed via 0xfffff000) to a different SDRAM location.


    Hope this helps,
    Thanks,
    -Mike A.
    You are not authorized to post a reply.