• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 626 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C1299NCZAD: LCD timing parameter: ui8ACBiasLineCount

Janet Shen
Expert 7795 points
Part Number: TM4C1299NCZAD

Dear Champs,

Our customer use raster LCD control on our TM4C129x and use raster_displays.c code to refer it.

But met one problem, we do not know why this value is 0 on tRasterDisplayInfo -->sTiming in     uint8_t ui8ACBiasLineCount; of tLCDRasterTiming.

const tRasterDisplayInfo g_sOptrex800x480x75Hz =
{
"800x480 at 75Hz on Optrex T-55226D043J-LW-A-AAN",
30000000,
SYSCTL_CFG_VCO_480,
120000000,
{
(RASTER_TIMING_ACTIVE_HIGH_PIXCLK |
RASTER_TIMING_SYNCS_ON_RISING_PIXCLK),
800, 480,
2, 30, 8,
10, 10, 8,
0
},
0
};

Because we could see the timing in datasheet, we see many LCDLP counts before LCDAC set, 

 

And see the register description ACBP in TRM, should we give a value on ui8ACBiasLineCount?

If you have any suggestion or good explanation, please feel free to let me know.

Thanks a lot.

  • 0
    TI__Guru**** 158815 points

    Hi Janet,

      The ACBF can be from 0 to 255. The raster_display. c is only an example. You can certainly try different values if you want to suit your application and your chosen LCD display for optimal operation. If the value is 0 then it will signal the LCD to invert the polarity of the power supplies every line clock. 

  • 0 in reply to Charles Tsai
    Guru 117850 points

    Hello (friend) Charles,

    If I may - as one w/some/slight 'display background' may I note:

    • the Display's Timing Chart & Specifications are ALWAYS - the controlling legal authority
    • the Driving MCU (or FPGA or ...) must 'Bend to the Will/Spec' of the Display's Timing chart & specs
    • by counting the number of 'H_Syncs' - it should be possible to note if the 'Display's 75Hz rate' is being (properly) satisfied
    • in my experience - a 'mid-range setting' for that 'ACBF' - followed by (very) close LCD observation - proves a good initial setting
    • carefully observe the display for: 'Tearing, Streaking, Ghost Images, Dark Lines, and Image Bleeding.'   (all of which appear - on my new sport car's dashboard - these are the (usual) indicators of 'flawed  display drive.')
    • in addition - power supply 'sequencing' may be demanded - again the display's data sheet - NOT that of the MCU - 'demands' TOP Priority.
    • it is possible (even likely) to create clever 'Display Test Patterns' - which quickly identify multiple of the earlier listed - display/drive scheme 'defects.'
    • as w/any (relatively) high speed digital system - interconnect lengths should be 'Short and Direct' and must avoid (any) nearby 'high frequency' and/or power carrying traces/wires/cable - which are (almost) guaranteed - to 'Distort and/or Disrupt' the displayed image...

    I would ask as well - at this MCU's (relatively) low clock rate - "Can an '800x480 Pixel, Multi-Byte/Pixel, color image - be first generated - and then sustained - at the listed 75Hz"?  

  • 0 in reply to Charles Tsai
    TI__Expert 7795 points

    Dear Charles,

    Thanks for your reply.

    Take below case as example:

    const tRasterDisplayInfo g_sOptrex800x480x75Hz =
    {
    "800x480 at 75Hz on Optrex T-55226D043J-LW-A-AAN",
    30000000,
    SYSCTL_CFG_VCO_480,
    120000000,
    {
    (RASTER_TIMING_ACTIVE_HIGH_PIXCLK |
    RASTER_TIMING_SYNCS_ON_RISING_PIXCLK),
    800, 480,
    2, 30, 8,
    10, 10, 8,
    0
    },
    0
    };

    If ui8ACBiasLineCount is not 0, how do we calculate the equation for pixel clock?

    Is 75*(800+2+30+8)*(480+10+10+8+ui8ACBiasLineCount)?

    If ui8ACBiasLineCount = 6 LCDLP, the result is larger than 30000000.

    What is the right equation?

    If you have any suggestion, please feel free to let me know.

    Thanks a lot.

  • 0 in reply to Janet Shen
    TI__Guru**** 158815 points

    Hi Janet,

      I don't understand your equation. Why are you adding the ui8ACBiasLineCount into pixel clock calculation? The ui8ACBiasLineCount is the number of line clocks to count before inverting the polarity to the power supply using the LCDAC pin. I don't think the ACBF should be included in the pixel clock calculation. 

    With ui8ACBiasLineCount = 0, you will need 75*(800+2+30+8)*(480+10+10+8) = 32Mhz pixel clock. Please note that the pixel clock is derived from SYSCLK. In order to support the 75Hz refresh rate you will need to configure CLKDIV to 2 so that the fLCDCP is equal to 60MHz. You will need to check your LCD display spec and find out the proper input clock frequency. If 60MHz is too fast for the LCD display then you need to reduce it to 30MHz. However, at 30MHz your refresh rate can not attain 75Hz but rather 70.3Hz only. 

  • 0 in reply to Janet Shen
    Guru 117850 points

    Somehow - the following 'Checklist' emerges ...  when a (dreaded) 'Non-Champ' (even one w/'focused expertise') informs/advises:

    • Draw-Bridge UP ... √
    • Moat stocked w/Hungry Crocs ... √
    • Diplomacy, 'Cast to the Curb' ... √

    Our firm has succeeded in driving a 'near twin' of this exact Optrex Display - via (another's) M4 & also M7.

    We'd prefer a, 'Walk thru burning coals' - rather than, 'assisting further!'      And - as staff here is 'overwhelmingly young & female' - that proves (beyond) 'telling!'     Pity!

  • 0 in reply to Charles Tsai
    TI__Expert 7795 points

    Dear Charles,

    Thanks for your clear explanation.

    As datasheet Figure 5-59, I still think the calculation is 75*((2+30+8)+800*(480+10+10+8)) = 30483000 ~30.5MHz.

    But I agree it based on LCDCP, we could select a similar LCDCP to achieve the pixel clock.

    Others, could I ask what is the working scenario if ui8ACBiasLineCount is not 0? Is LCD Raster-Mode Passive?

    If you have any suggestion, please feel free to let me know.

    Thanks a lot.

  • 0 in reply to Janet Shen
    TI__Guru**** 158815 points

    Janet Shen said:
    Others, could I ask what is the working scenario if ui8ACBiasLineCount is not 0? Is LCD Raster-Mode Passive?

    Janet, 

      AC Bias control applies to passive matrix LCD. See below excerpt from the datasheet. As far as what ui8ACBiasLineCount to use, this is going to be dependent on the LCD display you use. I certainly cannot answer this question. Your customer will need to run experiments to find out. Please refer to the various suggestions made by cb1_mobile (Thanks to cb1_mobile) as he has extensive experience in this area. He said "in my experience - a 'mid-range setting' for that 'ACBF' - followed by (very) close LCD observation - proves a good initial setting". 

  • 0 in reply to cb1_mobile
    TI__Expert 7795 points

    Dear cb1,

    Thanks for your experience sharing.

    After I started to assist customer tuning the LCD display, I finally got your reminder.

    I will follow your tips to tune it because of some LCD module spec is not clear.  

    Thanks a lot.

  • 0 in reply to Charles Tsai
    TI__Expert 7795 points

    Dear Charles,

    Thanks for your clear explanation.

    I think I have fully understood the description of LCD section on datasheet and TRM. 

    Will explain to customer and use raster_displays.c to help customer build up the testing code.

    Thanks a lot.

  • 0 in reply to Janet Shen
    Guru 117850 points

    Janet Shen said:
    After I started to assist customer tuning the LCD display, I finally got your reminder.

    Young, primarily female staff here - is 'glad' that you, 'finally got their 'Airplane Pilot's Checklist (style) guidance.'    Yet they ask - "HOW could such detailed guidance - have 'sat unrecognized' - for so long?" 

    It should be noted that Display Manufacturers produce such 'Specification Tables' under the most 'ideal' of laboratory conditions - and these specifications are aimed at specific displays - operated under 'exacting conditions.'   (which again - should be well listed.)

    This explains the 'WHY' for our 'pilot's checklist' posting - it was (and remains) our belief - that 'Adhering to such list provides the greatest likelihood for the Display User's success!'    (and thus properly 'disturbs' - due to much 'wasted time/effort' - when completely ignored...)

    Dealing w/'other' or 'single issues' - not resident upon such listing - often proves, 'eased (even) corrected & resolved' - via 'compliance w/those listed guidelines.

    Our time here is brief - we have had a 'brief window' to visit here (forum) - and now must exit due to vastly increased workload demands!    (i.e. key  clients have 'deeply considered - then adopted our best tech suggestions' - and now our 20' long reflow oven 'comes to life' - once more...)