Port Sitara LCD to Tiva

Hi Amit,

Thank you for your prompt reply. I have stared looking into porting the firmware from Sitara to Tiva. The header connections are also being taken care of.

My biggest obstacle at this moment is finding correct timing parameters. The datasheet for my LCD is not very helpful, but I was told that these parameters are highly dependent on the controller/driver being used. My LCD uses OTD9960/OTA7001 driver IC (a Frida FRD700740 - datasheet attached). On page 11 and 12 of the PDF are the timing diagrams.

I had a very easy time extracting timing parameters for one of the examples provided in the /peripherals/lcd/ folder (the Formike KWH070KQ13-F02) as it had a table with all these values in the datasheet. However, the Frida datasheet does not explain this information very clearly at all. Knowing that the LCD uses the OTD9960/OTA7001 driver IC, what other LCD's use this driver and have a clear enough datasheet? If you could help me with that, I would be very grateful.

I'm looking for the following parameters:

1. Pixel Clock Frequency
2. Horizontal Front Porch
3. Horizontal Back Porch
4. Horizontal Sync Width
5. Vertical Front Porch
6. Vertical Back Porch
7. Vertical Sync Width

Frida_FRD700740.pdf

I must have not been paying attention, but, upon searching for "OTA7001,OTD9960" on Google, the first link (www.sqm4.com/frd7040tp-t-rgb-tft-lcd-7-inch-embedded-display) allows the user to see data sheets for the OTA7001 and the OTD9960.

Timings can be obtained from there for both Horizontal and Vertical, Front and Back porches as well as Pulse Widths.
Ex: DClock Frequency - 30MHz

Hi Amit,

Yes, you are right and that is what I'm trying to do now. With the timing parameters done, I have opened the raster_example.c file in "/examples/peripherals/lcd" and I'm going through it line by line, checking everything against the TM4C129XNCZAD data sheet and re-writing a new file. It's going to take a while but I should be able to match all the GPIO's and registers from Sitara to Tiva.

May I ask, if the Sitara Newhaven LCD and my Frida LCD have different controllers, will the timings be the only thing that is different? I.e. assuming 1) the hardware adapter works and 2) I port everything else correctly from Sitara to Tiva and 3) I got the timings correct, should this thing work?

Thank you, Amit. You guys are awesome!

Best regards,
Horatiu

Hi guys,

I'm trying to set up SDRAM for my 800x480 LCD screen. The example present in the "examples/peripherals/lcd/" folder attempts a 64MB SRAM initialization (through EPI), but I don't have external RAM attached to the board, only the 256k embedded in it.

How can I get around this obstacle? I understand my current RAM size cannot not support the full 800w x 400h x 24bpp / 8 = 1125kB of buffer needed to start this example, but I don't know how else to proceed. A colleague suggested that my only choice is to send the image in chunks but I would like an example to follow in order to do this.

Best regards,
Horatiu

Hello Horatiu

Is the external panel a Raster Mode Panel or a LIDD Mode Panel?

Regards
Amit

Horatiu said:

examples/peripherals/lcd/" folder attempts a 64MB SRAM initialization (through EPI), but I don't have external RAM attached to the board, only the 256k embedded in it.   How can I get around this obstacle?

You cannot - and you've known - or should have known - of this from the get-go.  There is "good reason" that TFT Controllers (which embed adequate RAM w/in) exist!

Amit's earlier suggested that you reduce your memory requirement - by employing just a single color.  Such will - at minimum - confirm your pixel timing and verify screen addresses.  And yield glorious mono-chrome!   Colleagues suggestion of sending, "partial image" makes no sense (other than verifying your signal handling & timing) - we'd ask why you chose a pixel-laden TFT if you can support only a fraction of those pixels?

If the display world solves such issues w/massive, external SRAM - why would you deviate?   (and then complain here!)   Hard to feel sympathy when pain is both quite predictable - and totally "self-inflicted!"

If proper (speed, size, type) external SRAM is to (remain) rejected - "getting around your self-created obstacle" is achieved by employing a TFT w/appropriate, in-built - TFT Controller & Frame buffer...

Thank you cb1_mobile!
I want to see if I can get to properly talk to the screen before investing in SRAM. With that said, I will try monochrome - thank you for this idea. I'm fairly new to Tiva boards but from this point on, I imagine the following:
- I have to initialize the screen without initializing EPI and
- make sure the image buffer is set inside the 256k RAM available on the Tiva board

Another question I have is: On the datasheet, my TFT has a source driver and a gate driver (OTA7001/OTD9960). Is this the same thing as a controller & frame buffer combination you are talking about? The source driver is a 1200-something channel device and it works with resolutions higher than available on the TFT.

Thank you!

Hello cb1_mobile!
I finished porting the LCD - 800 x 480 x 1 pbb. The timings is the next issue I'm colliding against. My screen is either all black or all white, depending on how I fill the initial frame buffer, and then I get thrown into an Frame Synchronization Lost Enabled Interrupt and Clear.

The datasheet of the OTA7001A source driver says the following:
Clock Frequency: 30MHz
H Line Width: 928
H Display Area: 800
H Front Porch: 40
H Back Porch: 88
H Pulse Width: Min - 1, Typ - 48
V Period Time: 525
V Display Area: 480
V Front Porch: 32
V Back Porch: 13
V Pulse Width: 3

From what I noticed, in this datasheet...
Line Width = Display Area + Front Porch + Back Porch

...but in other specifications (for other drivers/controllers), Line Width = Display Area + Front Porch + Back Porch + PULSE WIDTH

I have tried running configurations with the above settings, with H Pulse Width set to '1', and with H Pulse Width & V Pulse Width set to '0'. None of them have worked so far.

Any help would be appreciated.

Best regards,
Horatiu

Problem solved. As mentioned in the TM4C129XNCZAD datasheet, the frame error is caused by either 1) invalid frame buffer address (display buffer too small?) or 2) invalid BPP value. I was using a buffer size too small.

The fomula to calculate buffer size is:
WIDTH x HEIGHT x (BPP / 8) + HEADER;

I was using:
(WIDTH x HEIGHT x BPP)/8 + HEADER;

The two formulas are equivalent only if allowed to use floating point math, otherwise they are not. When using BPP values of less than 8, the result of the two formulas differs.

Thanks,
Horatiu

Horatiu said:

The two formulas are equivalent only if allowed to use floating point math

First off - glad you persisted and got some positive results.   Had you tried my suggestion of tieing all bits (but MSb) of ONE color only to ground - and the MSb to logic high?   Such should yield (either) a red, green, or blue dot fill.

I don't agree that "floating point" resolves the "parenthesis" location issue.   Recall that our small tech firm has designed, produced, sold such displays (in volume) long prior to "floating point's" becoming available for "normal" MCUs.   Your compiler's handling of math - or settings (optimizations) - may also impact.

Without any changes now - you may wish to attempt to alternate "pixel/bit On/Off" and note results.  This test/verifies your pixel clock.  Always useful to continue this test across a 2nd pixel row - to insure that you properly manage "row to row" transitions.

Should that work - you may graduate to 3 bits/pixel (you connect only to MSbit of R, G & B) all other data bits are @ ground potential.  Should proper colors - and color sequences now emerge - your controller (appears) to be well mated to your candidate display...