DEMOS12XDT512 - trying to drive LCD, pins too slow?

[TSuereth]

I'm trying to use a DEMOS12XDT512 board (80-pin QFP S12X CPU with an XGATE coprocessor) to drive a Sony TFT LCD. The LCD takes a clock input, and 9 bits of input per pixel (rrrgggbbb) every time the clock ticks (there are other inputs but those aren't pertinent at the moment). The suggested clock frequency is 4 MHz, but according to the timing diagrams anything above 1.6 MHz should be more than enough for 30+ frames per second.

My plan was to use a Periodic Interrupt Timer, with the service routine running in parallel on the XGATE, to tick the clock and load data from a frame buffer into GPIO (I'm using ports A and B) pins. The board has a 4 MHz oscillator, and I can crank the PLL multiplier up to over 20x without losing stability, so I figured it should be no problem writing the pins at ~4 MHz. But after testing my plan, it looks like the setup times on the GPIO pins are way too slow. Switching the clock pin and the nine pixel pins in the ISR yields a maximum frequency of less than 1 MHz, and that's not accounting for a lot of the other outputs and calculations the routine will need to handle. I've run a bunch of trials and it's clear that the pin write time is the bottleneck.

Is there a way to speed up these pins? Or alternatively, are there any other pins I can use for output (available in the 80-pin package) that will run faster?

[kef]

PORTA and PORTB registers are PRR registers. Access to these registers takes 2 bus cycles. Check MC9S12XDP512 datasheet. I have Rev2.15 at hand, page 645, Table 17-23. PRR Listing.

Port T, P, S, J, M, ATD port registers aren't PRRs and they must be faster.

[imajeff]

The way I would speed it up is using the Enhanced Capture Timer (ECT) to pre-load a state for the timer pins. When a timer channel triggers based on the hardware timer, the output changes immediately without waiting for software. OC7 can be configured to trigger up to 8 pin states at once, in case that helps.

But this would not help you if your software is already unable to update it between the events.

[TSuereth]

I ran several timing tests on pins in PORTS and PORTAD0, and they are faster, but only slightly (my tests show a flat gain of 400 KHz over comparable PORTA tests, regardless of what the PLL multiplier is).

Is there anything else I can do or set to get faster GPIO?

[Nabla69]

Hello,

The code must be the cause.
The difference in access speed between registers and PRR is at least double, and up to 5 times quicker on Register than PRR. (worst ratio is 5 cycles with XGATE Write on PRR on odd cycle against 1 cycle on XGATE Write on Register also on odd cycles)

For maximum performances, only the XGATE should access the Register in question. Otherwise, the CPU12X has priority on the access and will make the XGATE wait.

Alfred.