Go Down

Topic: Help with doubling frequency. (Read 5457 times)previous topic - next topic

pYro_65

Nov 29, 2012, 04:50 amLast Edit: Mar 08, 2013, 05:32 am by pYro_65 Reason: 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.

Forum Mod anyone?
https://arduino.land/Moduino/

MarkT

#1
Nov 29, 2012, 01:11 pm
Have you considered direct port manipulation to speed up the clock pin toggling?

You can, for instance, pulse a pin with two instructions:
Code: [Select]
`  PINB = 0x01 ; // toggle pin 8 (bit 0 of port B on Uno)  PINB = 0x01 ; // toggle pin 8 back again`
[ I will NOT respond to personal messages, I WILL delete them, use the forum please ]

pYro_65

#2
Nov 29, 2012, 01:30 pm
Hey, cheers for the response, I'm already using port manipulation. Just looking to squeeze even more out of the system where possible.
Forum Mod anyone?
https://arduino.land/Moduino/

#3
Nov 29, 2012, 01:51 pm
Quote
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
Rob Gray aka the GRAYnomad www.robgray.com

pYro_65

#4
Nov 29, 2012, 02:21 pm
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.
Forum Mod anyone?
https://arduino.land/Moduino/

#5
Nov 29, 2012, 02:35 pm
Quote
The 'Write Data Setup Time' is 2.5 ns

What's the minimum pulse width?

Quote
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
Rob Gray aka the GRAYnomad www.robgray.com

pYro_65

#6
Nov 29, 2012, 03:03 pm
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.
Forum Mod anyone?
https://arduino.land/Moduino/

#7
Nov 29, 2012, 03:44 pmLast Edit: Nov 29, 2012, 03:45 pm by Graynomad Reason: 1
Quote
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
Rob Gray aka the GRAYnomad www.robgray.com

pYro_65

#8
Nov 29, 2012, 04:13 pm
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.
Forum Mod anyone?
https://arduino.land/Moduino/

MarkT

#9
Nov 29, 2012, 09:49 pm
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 ]
[ I will NOT respond to personal messages, I WILL delete them, use the forum please ]

dc42

#10
Nov 30, 2012, 01:49 am
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.
Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

pYro_65

#11
Nov 30, 2012, 02:18 am
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.
Forum Mod anyone?
https://arduino.land/Moduino/

pYro_65

#12
Nov 30, 2012, 04:05 am
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?
Forum Mod anyone?
https://arduino.land/Moduino/

krupski

#13
Nov 30, 2012, 05:56 am

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).
Gentlemen may prefer Blondes, but Real Men prefer Redheads!

dc42

#14
Nov 30, 2012, 09:24 am
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.
Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

Go Up