Call to arms | Teensy + SDRAM = true

[defragster]

Seems in like with the application notes

Yes 3X, that posted somewhere some few dozen or hundred(s) back in this long thread

 

[theboot900]

So using dogbones board im driving a controllerless 800x480 display from buydisplay.com

I've made an adaptor pcb with a constant current driver for the backlight as well as a 40 pin ziff connector (had to hand solder, forgot to click the stencil option)

So running in dotclock mode (using hsync, vsync and enable) im running a 20mhz pixel clock with a screen refresh rate of 50hz. A front and backbuffer is in sdram, and these are both being driven out to the lcdif pins via the lcd engine.

This works fine so far (except im missing the first 4 rows of lines being displayed) ive tested using a 32 bit buffer (with 3 bytes per pixel) and rgb 565 16 bit buffer.

The lcd engine actually does alright getting the buffer out of sdram into its own buffer in a timely manner.

Without the lcd engine running, In sdram using a for loop to fill uint32_t 384000 element array was about 4 milliseconds. When running the lcd engine outputting to the display and filling this array - this only increased slightly to an extra half a millisecond (I expected worse - sdram read to lcd buffer must be quicker than sdram read to cpu)

However there's 1 problem I can't solve. The display uses ST7277 to drive the actual pixels.

Whether im in 16 bit mode or 24 bit mode, if I have full white in the buffer the display goes wierd. It has to be full white. The whole display can be the colour 255,255,254 and its fine

If I add 5 rows of 255,255,255, those rows will have black artefact lines randomly flashing through.

If I add 40 rows of white, the artifscts are worse, and every couple seconds the display will randomly flash with junk colours.

Yet as long as there's no full white pixels everything is fine. It's extremely strange.

 

[sndsgd]

However there's 1 problem I can't solve. The display uses ST7277 to drive the actual pixels.

I'm also driving an 800x480 display with the ST7277. I had issues similar to what you described but was able to resolve it.

Here are the settings I ended up with:

  static constexpr uint32_t kHeight = 480;
  static constexpr uint32_t kVerticalFrontPorch = 14;
  static constexpr uint32_t kVerticalSyncWidth = 2;
  static constexpr uint32_t kVerticalBackPorch = 14;
  static constexpr uint32_t kWidth = 800;
  static constexpr uint32_t kHorizontalFrontPorch = 6;
  static constexpr uint32_t kHorizontalSyncWidth = 3;
  static constexpr uint32_t kHorizontalBackPorch = 6;
  static constexpr uint32_t kPixelClockNumerator = 25;
  static constexpr uint32_t kPixelClockDenominator = 24;
  static constexpr uint32_t kVsyncPolarity = 0;
  static constexpr uint32_t kHsyncPolarity = 0;

And then I needed to set the dot clock polarity bit in the LCDIF_VDCTRL0 register:

LCDIF_VDCTRL0 = LCDIF_VDCTRL0_ENABLE_PRESENT |
     LCDIF_VDCTRL0_VSYNC_PERIOD_UNIT |
     LCDIF_VDCTRL0_VSYNC_PULSE_WIDTH_UNIT |
     LCDIF_VDCTRL0_VSYNC_PULSE_WIDTH(config_.verticalSyncWidth) |
     config_.vsyncPolarity |
     config_.hsyncPolarity |
     LCDIF_VDCTRL0_DOTCLK_POL;

Hope this helps!

 

[theboot900]

Hope this helps!

It sure did!!!!

10 hours of trouble shooting this and you have just solved it.

i needed to set the DockCLK Polarity.

I also needed to reverse the polarity on the Vsync and HSync to get it to work

LCDIF_VDCTRL0 = LCDIF_VDCTRL0_ENABLE_PRESENT |
LCDIF_VDCTRL0_VSYNC_PERIOD_UNIT |
LCDIF_VDCTRL0_VSYNC_PULSE_WIDTH_UNIT |
LCDIF_VDCTRL0_VSYNC_PULSE_WIDTH(verticalSyncWidth) |
LCDIF_VDCTRL0_VSYNC_POL |
LCDIF_VDCTRL0_HSYNC_POL |
LCDIF_VDCTRL0_DOTCLK_POL;

I was starting to think the ST7277 was faulty. All the data signals where coming out correctly on the scope yet the screen was a mess as soon as i had full white pixels on it.

I seem to be missing the first row of pixels, but ill see if playing around with the porches will fix that

 

[theboot900]

Are you running 24bit or 16bit?

I like the speed of 16bit. However from what i can understand having 16bit padded input and 24bit data, it will do the conversion and just pad the lower bits of data with 0's. I dont think this gives as good as a colour range as doing a normal RGB565 to RGB888.

I think you can get the pixel pipeline to pull from a 16bit buffer, do the conversion to rgb888 and feed it straight to the lcdbuffer to output (Without needing to do memory to memory)

 

[jmarsh]

I'm pretty sure eLCDIF can extend 16-bit data to 24-bit on its own, copying the highest bits into the lowest to maintain proper range. The ST7277 datasheet says it upconverts the same way, although I would have doubts on a screen that small having a full 8 bits of range anyway.

 

[theboot900]

I'm pretty sure eLCDIF can extend 16-bit data to 24-bit on its own, copying the highest bits into the lowest to maintain proper range. The ST7277 datasheet says it upconverts the same way, although I would have doubts on a screen that small having a full 8 bits of range anyway.

I'm pretty sure it just pads the lowest bits as 0's for each colour. So in the 565 format if you had 5 bits of red, when converted to 888 the lower 3 bits would be 0 (1111 1000)

This is a lot smaller dynamic range then if doing a proper conversion. 5 bits of red should convert to 1111 1111

*edit*

So im wrong, the padding was for the conversion going from 24 bit colour data to 16 bit output.

From the imxrt1062 data sheet

LCDIF_CTRL[WORD_LENGTH], eLCDIF will perform RGB to RGB color space
conversion. For example, if the input frame has fewer bits per pixel than the display, as in
a 16 bpp input frame going to 24 bpp LCD, eLCDIF will pad the MSBs of each color to
the LSBs of the same color for each pixel. If the input frame has more bits per pixel than
the display, for example, 24 bpp input frame going to 16 bpp LCD, eLCDIF will drop the
LSBs of each color channel to convert to the lower color depth

 

[jmarsh]

I'm not sure what type of content you're displaying but if it's basic stuff that doesn't use too many colors, there's also an 8-bit palette mode (pixels specify a byte index into a 24-bit color palette). It's handy for UIs if you want to support custom colors or simple brightness changes.