TM4C speed operation?

Hello Amit. Thanks for your quickly reply.

This is the code for TM4C123:

SysCtlClockSet(SYSCTL_SYSDIV_2_5 | SYSCTL_USE_PLL | SYSCTL_XTAL_16MHZ | SYSCTL_OSC_MAIN);

SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD);

GPIOPinTypeGPIOOutput(GPIO_PORTD_BASE, GPIO_PIN_6);

GPIOPinWrite(GPIO_PORTD_BASE, GPIO_PIN_6, 0x00);

And this is the code for TM41294:

uint32_t     ui32ClockFreq;

ui32ClockFreq = SysCtlClockFreqSet((SYSCTL_CFG_VCO_480 | SYSCTL_USE_PLL | SYSCTL_XTAL_25MHZ | SYSCTL_OSC_MAIN), 120000000);

SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOD);

GPIOPinTypeGPIOOutput(GPIO_PORTD_BASE, GPIO_PIN_6);

GPIOPinWrite(GPIO_PORTD_BASE, GPIO_PIN_6, 0x00);

If I start debug mode, "ui32ClockFreq" variable value is 120 000 000. That seems good.

Hello Amit. You right. I gain a little more frequency. I wrote without checking the right numbers. I have just repeated  the experiment and this is the results.

TM4C123GXL:

Using GPIOPinWrite with SysCtlDelay(1):  1.330 MHz

Using GPIOPinWrite without Delay:            2.347 MHz

Using HWREG with SysCtlDelay(1):            2.222 MHz

Using HWREG without Delay:                      5.650 MHz

But with HWREG without delay I expected more frequency. I would like to do a RGB TFT driver with 24-bit color but if the most quick toggle frequency is this I think I won't be able to do it working with the typical 9MHz which screen needs.

What do you think about it?

I attach some pictures with the oscilloscope results. I apology because the signals aren't perfectly square because my probes have capacitive effect.

Salvador Ballesteros said:

like to do a RGB TFT driver with 24-bit color but if the most quick toggle frequency is this I think I won't be able to do it working with the typical 9MHz which screen needs.

You seize upon GPIO toggle frequency - but is that not (just) the "tip of the iceberg?"   Along w/those 9MHz (likely 4.3" 480x272, TFT) clocks - you'll need to read & present that 24 bit pixel data - will you not?

Unmentioned - perhaps not fully considered - is "How & where" you'll store (and load) your screen data.   That memory space surely exceeds that w/in the MCU.

TFT Control ICs are marketed which "do" effectively answer these (and other) TFT & memory access considerations.   Wanting to employ the MCU as "kitchen sink" may (greatly) tap into its resources - and (still) not meet the performance of a low-grade cell or tablet!

Vendor's 129x series attempts to "approach" this issue w/external memory and wide bus outputs.   That said - comparison of 129's "results" may not fare well when measured against cells/tablets - which employ far more powerful MCU...

Luis Afonso said:

Why not use a LCD already with a SPI interface? SPI speeds of 10Mhz are very easy to use on the any of the Tivas.
The TM4C1294 has a LCD driver, would it not be enough?

 Hi Luis, using a "SPI" RGB display so called LVDI serial require a clock more faster than it can be obtained on SPI port of 123 series and 129 too.

 Anyway primary post was stating about an RGB parallel LCD; as CB1 pointed to, this device require a parallel feed of 24 bit@ rate variable from about 5 to somee tens of Mega Hertz, this case can just be addressed by 129 series thru EPI but it lose additional ram required to store raster image. Again 129 has an LCD controller on board can better solve dirving LCD, this controller is great but lack of suitable chip carrier discouraged me from usage due to high cost of ultra fine line pcb.

 So final solution was VHDL on FPGA, here detail of test bed on a cheap few US$ maxV 240 and evaluation of TM4c129 in front of 256 1mm spaced FPGA casing. 100uM lines are not a trouble but cost is not affordable other than reliability of this on a mechanical machinery.

and here is the comparison of 256 balls  1mm spaced fpga with 212 balls ultra thin tm4c129, this was the worst past issue, now I got a workhorse where all code and IPcore are on same chip.

Amit Ashara said:

Now since the requirement is to drive a parallel LCD port, TM4C129 would be a better replacement due to increased RAM (ability to interface more in form of SDRAM) and a dedicated LCD controller.

 Hi Amit, just a question, I seen no plan for new device, why not release new part just differently cased? example for 129 with LCD or not TQFP144 176 or 208 @500um pitch?

 These case are best handled in prototypes and don't require an expensive pcb technology. Also 50Ohm impedance is best matched than on actual fine pitch tqfp 128.

 This is just a curiosity.

Thanks to all of you.

I was thinking use an external SD memory as a main memory for the raster image and I'd like to create my own TFT driver for 4.3'' 480x272 TFT with uDMA with either the tm4c123 Launchpad or the tm4c1294 Connected Launchpad. Like some of you said, the TM4C129x has an LCD controller inside of it, but the TM4C1294GXL (Connected Launchpad) doesn't have any LCD controller inside, so I'd like to do a dedicate LCD controller with it.

So do you think that it isn't possible with them (tm4c123 and tm4c1294)?

Should you consider SPI - do perform a careful calculation to determine the time to perform a "CLS."   (Clear screen) 

Unfortunately cell phones & tablets (now) set the standard against which your development will be compared.   And as each employ far faster - more display focused MCU - your results may be seen as, "lacking."

As always much depends upon your application - and that's (yet) to be described.   That said - if (reasonable) screen draws & clears are required - "culling yourself" so far from the (existing) cell/tablet "herd" may not prove entirely wise...

Agreed Amit.   Users would do well to, "Test for Reality" prior to committing: time, effort, funds to a (desired) new MCU-based project.  Similarly cars, small planes - used for commuting - cannot expect to fare well when moved to the race-track or "air to air" combat!  (methinks so basic a point is too often missed - here!)

Imagination and desire have their place - yet reality may intrude with a "heaviness" - especially so when it's impact has not received full/proper consideration...

Robert Adsett said:

Or buy a module that already implements the screen drawing primitives that you send

Mais oui mon ami - c'est tres bien!   Such enables a lower grade MCU to (almost) play w/the Big Boyz!

Your later point - "Is a highly functional display needed" also deserves note.  Recall that in the past - Steve Jobs (almost exclusively) thought that users would enjoy video on a "small screen!"   And he proved "so right!"   (and this reporter - in the display biz - so wrong.)

That said - thanks to small yet capable displays - the "Walkman" (Sony) was effectively (and brutally) displaced by the "display equipped" iPod (Apple).   (the small Samsung hard drive - also - "may" have helped...)  (for sure - it did!)

When my past firm pioneered small Lcd modules - smart, fellow biz travelers asked, "Who'd need them?"   Today - better question - who does not?

Hi Amit,

Re: Give me the code!

We'd say that this (one) - out of your 10,11x post total - (may) be overlooked... (so long as this is not your "homework" assignment - or that you do not state your MCU, "Does NOT Work!"...)   We do understand that - as always - need is URGENT!