• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 100 subscribers
  • Views 245 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Programming Frame buffer address in DM355

Dilip
Prodigy 90 points

Hi,

I'm developing display driver DM355. I have not understood the way to write the frame buffer address in the registers VIDWINADH and VIDWIN0ADL.

My frame buffer address is 0x86000000 and the SDRAM base address is 0x80000000.

The description under the VIDWINADH register is "Video Window 0 SDRAM Source Address-High, 7 MSBs of SDRAM source address - The SDRAM source address is specified as an offset from the SDRAM base address, in units of 32 bytes. VD latches this bit." Based on the description in the data sheet of VPBE I'm writing the values to the registers VIDWINADH and VIDWINADL as shown below

Offset= 0x86000000 - 0x80000000; //(Calculating offset from SDRAM base address).

Offset /= 32; //(Offset in specified in unit of 32 Bytes).

VIDWINADH |= ((Offset & 0x7F0000) >> 16);  //Upper 7 MSBs programmed into VIDWINADH register

VIDWINADL = Offset & 0xFFFF; //Lower 16 bytes are programmed into VIDWINADL register

I'm unable to get the display driver working. I'm suspecting programming the frame buffer address is the problem. I'm not sure if I', programming the frame buffer address correctly or not. If it is wrong please tell me the correct way of programming it. Please clarify my doubt regarding the frame buffer address.

regards,

T.Dilip Chakravarthy.

 

  • 0
    TI__Mastermind 37340 points

    Dilip,

    you have two video windows on DM355; are you trying to program video window 0 or video window 1.  For video VID0, your interpretation appears to be correct.  Of course register name for the lower 16-bits is unique (not shared) for VID0 and VID1 (e.g. VIDWIN0ADL).  If you look at the video display driver inlcuded in the DVSDK, they use very similar coding (e.g. (Offset >> 16) & 0x7F for VIDWINADH) which evaluates to the same thing you have.