• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 1500 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.

Using Grlib in 16BPP vs. demo code of 24BPP

John Conover
Genius 4350 points
Other Parts Discussed in Thread: AM3359

Hi,

     We are using the grlib from the StarterWare example from the AM335x on our custom board (which is close to a MityARM 3359). The demo

examples use 24bpp in the graphics library's but our board uses 16bpp. Our display is very close to the Cape display used by the Beaglebone

and is 480x272. What we are looking for is some guidance about changes needed for using 16bpp. Some of the things to note below:

- There is a double display of the text. There is only supposed to be a single top line of "BASIC CONFIG". This double line showed

           up when we changed from GrOffScreen24BPPInit() to GrOffScreen16BPPInit(). When we used the 24bpp init there was only

           a single line of text.

- The font should be much larger. We are using a 32 point bold font and again when we shifted the init routines the font size changed.

- The colors are wrong. The text is supposed to be in Yellow, not white. The init routines had no effect on this.

      Because the GrOffScreen16BPPInit() only sets the the function callouts, it does not appear that our configuration of the Raster

control register of the AM3359 are far off (RASTER_CTRL Register). If we use the 24bpp init we get the right font size (text on lines

below the top line are still scrambled.)

      Has the grlib 16bpp been tested on a platform like the cape? Does anyone have suggestions/thoughts as to wether this

is more of a raster setup issue of a graphics library issue?

Thanks,

     John Conover



  • 0
    Genius 4350 points

    Here is an update:

     - The scrambling of the characters is caused by the frame buffer not being aligned. Somewhere in the grlib demo code the alignment must be done. I forced the alignment by using the attribute: unsigned char g_pucBuffer[GrOffScreen24BPPSize(480, 272, PIXEL_24_BPP_UNPACKED)] __attribute__((aligned(32768)));

    - The double text is something in the 16bpp function set called during setup (GrOffScreen24BPPInit() vs GrOffScreen16BPPInit().) I could not track the answer to this.

    - Color had to be adjusted in the grlib.h file as 16bpp uses the 565. Quick example would be that the Clear Yellow had to be changed from 0x00FFFF00 to 0xFFE0. The lower 2 or 3 bits are chopped off the color.

    The solutions are not ideal but because of the time line I'll stick with the 24bpp functions and color adjustment. If anyone from TI has better answers that would be great.

    John C.




  • 0 in reply to John Conover
    TI__Intellectual 1555 points

    Hi John,

    I may be wrong, but I guess you don't need to translate the colors when using GrOffScreen16BPPInit(). It is already implemented in offscr16bpp.c:  "GrOffScreen16BPPColorTranslate" and is used in "GrOffScreen16BPPInit".

    Did you try different configurations of the raster controller? 

    It's there:

    RasterModeConfig(SOC_LCDC_0_REGS, RASTER_DISPLAY_MODE_TFT_UNPACKED,
    RASTER_PALETTE_DATA, RASTER_COLOR, RASTER_RIGHT_ALIGNED);

    Maybe RASTER_EXTRAPOLATE instead of RASTER_RIGHT_ALIGNED ? (raster.h)

    Please check with  13.3.5.2 Frame Buffer and 13.5.10 RASTER_CTRL Register of the TRM.

    Best regards,

    Mariusz.


  • 0 in reply to Mariusz Lacina
    Genius 4350 points

    Hi Mariusz,

                 Yea we did see the color translation that was present in the 16bpp function, we just could not get past the double image that those functions were producing. It most likely has something to do with using a single frame buffer instead of two (this is how the demo code set it up.)

                 As far as trying to use RASTER_EXTRAPOLATE it does not seem the the Function RasterModeConfig() handles things any differently when using RASTER_DISPLAY_MODE_TFT_UNPACKED as the displayMode variable. The call to RasterModeConfig:

    RasterModeConfig(SOC_LCDC_0_REGS, RASTER_DISPLAY_MODE_TFT_UNPACKED,RASTER_PALETTE_DATA, RASTER_COLOR, RASTER_RIGHT_ALIGNED);

                This was out of the example code and uses RASTER_DISPLAY_MODE_TFT_UNPACKED as the display mode. If you look at the RasterModeConfig function, the code will always fall into the else portion of the if statement when checking displayMode. At that point using RASTER_EXTRAPOLATE instead of RASTER_RIGHT_ALIGNED will have no effect. I'm sure the code is written that way for a reason, but I currently don't have time to fix it or make it work for 16bpp. If you have more insight that would be great.

    Thanks,

         John C.