Help with doubling frequency.

Other Hardware General Electronics
1

Hi, I have an LCD that I want to speed up using an external circuit.

Data is transferred via parallel and clocked in using a digital pin. Some commands do not require new parallel data unless you need it to change, so the clock pin can simply be toggled for the number of operations in the command.

To take advantage of this feature even more, I want to speed up the toggling of the clock pin.
My schematic below is what my idea is at the moment.

I use an LCD shield so pin 'B' ( connected to shield ) would be set to input for high impedance to disable it ( hopefully ).
A spare pin 'A' is used to create a signal for a XOR gate, which is split, with one input delayed using buffers.

Is this a common way of creating a pulse on both the HIGH and LOW transitions of pin A?
Also, is this the right way to connect the two Arduino pins together allowing me to "hack" the LCD shield?

Any help is greatly appreciated.

Cheers, Chris.

2

Have you considered direct port manipulation to speed up the clock pin toggling?

You can, for instance, pulse a pin with two instructions:

  PINB = 0x01 ; // toggle pin 8 (bit 0 of port B on Uno)
  PINB = 0x01 ; // toggle pin 8 back again
3

Hey, cheers for the response, I'm already using port manipulation. Just looking to squeeze even more out of the system where possible.

4

Is this a common way of creating a pulse on both the HIGH and LOW transitions of pin A?

Yes that's a common pulse generating circuit.

But unless your buffers are very slow the pulse will be just a few nS, is that OK for the LCD? Have you checked that the likely pulse with is > the min pulse width required by the display?

What I don't get though is that LCDs are normally very slow, how does shaving 62.5nS of the clock pulse save that much? Is it a GLCD?

Rob

5

Yes, its a 320x240 262k ( running in 65k mode ).
The 'Write Data Setup Time' is 2.5 ns, hopefully I can squeeze many toggles into the 62.5ns pulse. I also have plenty of buffers to adjust timing.

I'm doing a fast graphics driver for it as the UTFT library is too slow for what I need. For the test this hardware will benefit, I have gotten full screen random colour paints down to 97ms over the UTFT 560ms with simple software changes; with the toggle frequency doubled or even quadrupled, the draw/clear speed will hopefully be much faster than manually erasing paths during animation.

I'll give a try at the circuit in a little bit, just need to find the best way of wiring the pin to the shield.

Thanks.

6

The 'Write Data Setup Time' is 2.5 ns

What's the minimum pulse width?

hopefully I can squeeze many toggles into the 62.5ns pulse

Not with a 16MHz AVR, that's the cycle time so the best you can do is double it, at least with that circuit. BUT you can't update the data in anything like that sort of time plus presumably the code has to do other stuff, so surely this pulse width is only a small part of the overall job.

I guess though that if the data remains the same, say when clearing the display, doubling the clock will help.

Rob

7

The correct value is 5ns.

The LCD runs off 16-bit parallel with 16-bit colour so for lines or filled squares where the colour information is static, all that needs to change is the clock write cycle. The screen supports windowing so X and Y address counters are maintained by the LCD.

My plan is to combine a variable frequency multiplier with a duffs-device style rendering loop to limit the number of iterations used in each loop. For now a 2x multiplier will buy me enough CPU time to start testing other features.

The system is intended to drive vector animations for a game.

8

5ns

Speedy little fellow eh?

How much hardware do you want to throw at this? You could rig up a counter to do 256, 4096 or 65k pulses at say 100Mhz. That's still only 3-5 chips.

Rob

9

I'm pretty sure the 5ns is the correct value, it was the tDHW ( Data hold time ) value.
The display controller is SSD1289 and its the 3.2" touch panel from sainsmart running on a mega via a level shifting shield.

The code I'm writing I plan to release to the forum, which will hopefully raise the bar a little bit for Arduino's gaming capacity. The code is tied to the controller, but from browsing the 'display & LCD' forum it seems many people are using the same kit I bought.

I want the hardware support to be modular so its not required for use, but a complex counter like what you describe would be amazing for parallel processing, even if it is only used to clear the screen. As most designs may only need 1 or 2 pwm for sound there are many pins left over for all sorts of fun things.

I have had all sorts of ideas brewing, I was inspired when I saw it was quicker to control than the B/W ST7920 I was using for ages.

10

The data hold time is how long the databus has to be stable before a write-strobe, its nothing to do with write cycle-time.
The write-cycle time is listed as a minimum of 100ns,
Looking at other similar device's datasheets suggests the minimum nWR low time is 50ns, minimum nWR high time is 50ns.
[ i.e. 10MHz max strobe rate ]

My practical experience with other similar TFT driver chips suggests that clocking at 10MHz is quite do-able and stable. That's 130
fps for a screen-fill at 320x240 pixels BTW.

[ The SSD1289 datasheet seems to be bogus and suggests 8080 mode write cycles are strobed using nCS, whereas the standard
8080 interface uses nWR as the strobe - I suspect a bug in the datasheet as the UTFT library assumes nWR and clearly works ]

11

Rather than using a couple of inverters to delay the signal, if might be better to get a longer and more controlled delay by using a delay line, for example http://para.maximintegrated.com/en/search.mvp?fam=del_line&295=Tapped&hs=1. Alternatively, use 2 of the inverters in a 74HC14 with an R-C network connected between them.

12

Yeah, i'm not sure if it is accurate either,

The UTFT and others aren't taking advantage of the displays hardware capabilities ( not in data sheet either ), they set data into the the parallel outputs ( colour info ) then pulse WR once. This 'set colour & strobe' is repeated for the fill. In mine, WR is simply pulsed.

I'm already pulsing the LCD as fast as the mega can write. Which is why even, without a frequency doubler I want to use a low-order port to provide the pulse as the high-order ports ( lcd shield connection ) require atomic blocking, effectively halving the toggle speed.

I'll start to de-solder the shield pin now, to see if a simple pin change has any effect, then I'll at least give frequency doubling a go.
I'm curious to see it run even close to 130 fps.

I'll post on how it goes.

Just saw your post dc42, will check it out.

13

Seems the WR line is already on a low order port. And wouldn't 130 fps require the MCU to run at 20 mhz so it can clock out pixels at 10Mhz on single instruction pin changes?

14

pYro_65:
Hi, I have an LCD that I want to speed up using an external circuit.

First of all, an LCD has it's own internal processing time. No matter how fast you pulse the enable pin, the LCD can only work as fast as it's able.

Secondly, the physical response time of an LCD screen is slow (in the millisecond range). What benefit do you get from accessing it faster?

Lastly, if you know your clock speed, you can make a delay circuit of about 1/2 the period of the clock then XOR the two together and get a 2X clock.

It all seems pointless though (unless I'm missing something).

15

Are you using the SPI pins for anything? If you use the SCLK pin as your WR line, you can get a hardware clock from it at half the crystal frequency by doing a dummy SPI transfer.

16

I have an update, plans have changed,...

Are you using the SPI pins for anything? If you use the SCLK pin as your WR line, you can get a hardware clock from it at half the crystal frequency by doing a dummy SPI transfer.

I'm not up to date with the mega, however, if the SPI is in the double row header then for now it is used as I have an LCD shield.

Krupski:
First of all, an LCD has it's own internal processing time. No matter how fast you pulse the enable pin, the LCD can only work as fast as it's able.

Secondly, the physical response time of an LCD screen is slow (in the millisecond range). What benefit do you get from accessing it faster?

Lastly, if you know your clock speed, you can make a delay circuit of about 1/2 the period of the clock then XOR the two together and get a 2X clock.

It all seems pointless though (unless I'm missing something).

You and others are quite right about the processing time,

I managed to optimise the writes up to 7 instructions per pixel. The UTFT overhead was writing the colour every pixel even when not needed. The code below ( operation for each pixel, other design differences too ) cleared the screen in 81ms down from 97ms, far quicker than the original 560ms.

//Pseudo code
wr low;
nop;
nop;
nop;
nop;
nop;
wr high;

The required timing is somewhere in the last nop instruction. As you can see this is no where near the speeds I'm after. I know it can be written to faster as it says its an animation display, which isn't possible at these speeds ( possible, but lacking in frame rate ).

After getting frustrated I went hunting and managed to find a more complete datasheet ( still lots missing though ). I went through and completely modified the initialisation routine, it now uses more power and high internal clock frequencies ( less screen flicker ). It enabled me to get the pixel code to 5 instructions:

//Pseudo code
wr low;
nop;
nop;
nop;
wr high;

This runs at 68ms per refresh, or ~14.7fps. Unfortunately this speed still sucks. I was about to give up when I decided to mess with the control algorithms. Then something strange happened:

In drawing a rectangle, it would normally be under filled by a significant portion if toggled too fast causing pixels to be lost. However it was suddenly drawing more pixels and causing corruption drawing in -ve regions ( unsigned rollover ).

So I simply halved the duration of my loop, this caused the rectangle to be full apart from a short few pixels, so I added 1 more iteration to the loop for a perfect fill.

Moment of relief, I found what I was looking for.

The few pixels unfilled turns out they where used as a synchronisation pattern for a high speed RAM update. This allowed an amazing output of 2 pixels per 4 instructions, with a huge result of 19.7ms per full screen clear to random colour, or ~50.76fps.

The pins are different depending on what they where doing previous, but is basically this pattern:

pin1 low:
pin2 high;
pin2 low;
pin1 high;

Which is as fast as the Arduino is going to do it at 16Mhz. The great thing about this is the initialisation routine now sets up the high speed updates to be clocked using the data control lines. That's what the synchronisation pattern is used for.

So now I need to create a dual pulse circuit to drive two lines at once. I'll be messing with the code for a bit, but I'd like to hear further ideas, I'll post when/if I have some success.

Just exciting as this primitive hardware acceleration may make a game possible even without an external circuit .

17

pYro_65:
I'm not up to date with the mega, however, if the SPI is in the double row header then for now it is used as I have an LCD shield.

http://arduino.cc/en/Hacking/PinMapping2560

The SPI pins are 50, 51 and 52, also pin 53 must be configured as an output.