User avatar
PeterO
Posts: 5024
Joined: Sun Jul 22, 2012 4:14 pm

Adafruit LCD on 8bit interface

Sat Aug 23, 2014 10:26 am

After a bit of "fafing about" I've got an Adafruit 2.8" LCD display running on its 8bit parallel interface rather than its SPI interface.
Image

In the picture (*) the Pi is running Life on a 64x64 grid which is being displayed as a 192x192 image by simple x3 pixel expansion. If you were at last weekend's Southend on Sea Jam you may recognise this as the same code that was driving my 64x64 LED display.

Code wise I started with the Arduino drivers just to get an initialisation sequence that is known to work. As a side effect I've now got a set of C routines which perform efficient "byte-wise" read and writes on a set of GPIO pins.

Details on the display here -> https://learn.adafruit.com/adafruit-2-d ... 2/overview

PeterO

(*) The more observant readers may notice resistors in the 8 databus lines. These are there as a safety precaution while I was developing the code. Initially there was a chance I had got the control signals inverted as the Adafruit documents are particularly bad at labeling signals that are active low. So to prevent any damage to the PI or the LCD caused by them both trying to drive any data lines in opposite directions I added the resistors. In fact they were helpful as I hadn't realised the Read signal is not ignored when the Chip Select line is inactive !
Last edited by PeterO on Sat Aug 23, 2014 6:29 pm, edited 1 time in total.
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

User avatar
mahjongg
Forum Moderator
Forum Moderator
Posts: 12238
Joined: Sun Mar 11, 2012 12:19 am
Location: South Holland, The Netherlands

Re: Adafruit LCD on 8bit interface

Sat Aug 23, 2014 1:47 pm

[modded, increased picture size]

toxibunny
Posts: 1382
Joined: Thu Aug 18, 2011 9:21 pm

Re: Adafruit LCD on 8bit interface

Sat Aug 23, 2014 5:18 pm

Oh, cool. Any chance of a framerate increase doing it this way?
note: I may or may not know what I'm talking about...

User avatar
PeterO
Posts: 5024
Joined: Sun Jul 22, 2012 4:14 pm

Re: Adafruit LCD on 8bit interface

Sat Aug 23, 2014 6:25 pm

toxibunny wrote:Oh, cool. Any chance of a framerate increase doing it this way?
At the bottom of this page https://learn.adafruit.com/adafruit-2-d ... g-and-test it say parallel is 2 to 4 times faster than SPI, but the trade off is more GPIO pins. Also doing the GPIO pin twiddling in user space software means there is a high CPU load, where as I would imagine the SPI interface could be DMA and Interrupt driven thus reducing CPU load.

I'll make some frame rate measurements.

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

User avatar
PeterO
Posts: 5024
Joined: Sun Jul 22, 2012 4:14 pm

Re: Adafruit LCD on 8bit interface

Sat Aug 23, 2014 6:50 pm

A full 320x240 screen update from an array of 320x240 16 bit colour values is taking ~19 ms, so that would give ~50 frames/second but that leaves no CPU time to update the image !

Calculating the next Life generation and updating the pixel data at 320x240 takes ~11ms, so a generation takes 11+19 = 30ms which is giving ~33 frames/second.

Peter.
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

User avatar
PeterO
Posts: 5024
Joined: Sun Jul 22, 2012 4:14 pm

Re: Adafruit LCD on 8bit interface

Sun Aug 24, 2014 5:48 pm

I've now got the LCD display working with the gpu_fft code to produce a new version of my panadapter.
Image

Looking at a "sync" signal on my 'scope it is taking ~9ms to draw the 320 vertical lines that make up the spectrum graph seen above.
It takes less than 0.5ms to compute the FFT, so with a sound buffer period of 42ms there is plenty of time spare !

I'll take some video later on.

I've put a better picture in here... It shows an AM broadcast station with its carrier in the centre and the two sidebands on either side. At the time the picture was taken a presenter was speaking.

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

notro
Posts: 695
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: Adafruit LCD on 8bit interface

Mon Aug 25, 2014 4:58 pm

Regarding fps, do I understand you correctly:
1 frame / 9 ms = 111 fps ?
240x320x2 bytes / 9 ms = 16 MB/s ?

Writing directly to the hw registers from a kernel driver has given me ~4 MB/s
This is on a similar 320x240 rgb565 8-bit parallel interfaced display: https://github.com/notro/fbtft/wiki/Performance#itdb28

Here's the I/O code I use: fbtft_write_gpio8_wr

Can you share you're code?

User avatar
PeterO
Posts: 5024
Joined: Sun Jul 22, 2012 4:14 pm

Re: Adafruit LCD on 8bit interface

Mon Aug 25, 2014 5:17 pm

notro wrote:Regarding fps, do I understand you correctly:
1 frame / 9 ms = 111 fps ?
240x320x2 bytes / 9 ms = 16 MB/s ?
Sounds about right....

Writing directly to the hw registers from a kernel driver has given me ~4 MB/s
This is on a similar 320x240 rgb565 8-bit parallel interfaced display: https://github.com/notro/fbtft/wiki/Performance#itdb28

Here's the I/O code I use: fbtft_write_gpio8_wr
Your code is a bit inefficient in a few places ! :roll:
Can you share you're code?
I've spent some time this afternoon making it into a simple "parallel access" scheme for up to 16 GPIO pins. I'm just tidying it up now and I'll post a link when it is ready.

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

User avatar
PeterO
Posts: 5024
Joined: Sun Jul 22, 2012 4:14 pm

Re: Adafruit LCD on 8bit interface

Mon Aug 25, 2014 5:48 pm

It could do with a few more "range checks" etc ( but who has the time :D )

http://www.peteronion.org.uk/PiCode/PiParPort.c

You will see that everything is done in parallel, no setting/reseting individual bits at a time etc etc...

Enjoy!

PeterO

PS: You need to compile with "-O2" to get the full speed !
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

notro
Posts: 695
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: Adafruit LCD on 8bit interface

Tue Aug 26, 2014 4:09 pm

I took you're code and changed the while loop into this:

Code: Select all

    for (i = 0; i < 320*240*2*1000; i++)
    {
	parallelWrite(n & 0x3FF);
    }
then I timed it:

Code: Select all

$ time sudo ./a.out

real    0m8.787s
user    0m8.420s
sys     0m0.010s
Then I used my I/O code:

Code: Select all

#define GPIOSET(no, ishigh)           \
do {                                  \
	if (ishigh)                   \
		set |= (1 << (no));   \
	else                          \
		reset |= (1 << (no)); \
} while (0)

inline void parallelWrite(uint16_t value)
{
	unsigned int set = 0;
	unsigned int reset = 0;

	/* Set data */
	GPIOSET(bits[0], (value & 0x01));
	GPIOSET(bits[1], (value & 0x02));
	GPIOSET(bits[2], (value & 0x04));
	GPIOSET(bits[3], (value & 0x08));
	GPIOSET(bits[4], (value & 0x10));
	GPIOSET(bits[5], (value & 0x20));
	GPIOSET(bits[6], (value & 0x40));
	GPIOSET(bits[7], (value & 0x80));
	SetBits(set);
	ClearBits(reset);
}
and timed it:

Code: Select all

$ time sudo ./a.out

real    0m8.105s
user    0m7.730s
sys     0m0.040s
I haven't tested to see if it actually works, or if some part is optimized away, but it seems to be a bit faster.

But this can't be the code you use to drive the Adafruit LCD, it's missing the /WR latching?

User avatar
PeterO
Posts: 5024
Joined: Sun Jul 22, 2012 4:14 pm

Re: Adafruit LCD on 8bit interface

Tue Aug 26, 2014 4:41 pm

Yes that is just the parallel IO part of the code...
Here's the screen updater... write8() (which is inlined) also has a WR-bar toggle at the end...

I do my timings using another GPIO as a sync signal into my digital storage scope.

I assume this is kernel code so the "sys" time is the important figure ?
I expect the speed up is mostly due to using the lookup table to produce the correct bit patterns for the set/reset registers.

Code: Select all

void update320x240(uint16_t *buffer)
{
    int x,y;
    uint8_t hi,lo;
    uint16_t *bp;

    CS_ACTIVE;
 
   writecommand(ILI9341_CASET); // Row addr set
    writedata(0);
    writedata(0);     // XSTART
    writedata(0x1);
    writedata(0x3F);     // XEND

    writecommand(ILI9341_PASET); // Column addr set
    writedata(0);
    writedata(0);     // YSTART 
    writedata(0x0);
    writedata(239);     // YEND
    
    writecommand(ILI9341_RAMWR); // write to RAM
  
    CD_DATA;
  
    bp = buffer;
    y = 240;
    while(y--)
    {
        x = 320;
        while(x--)
        {
            lo = *bp & 0xFF;
            hi = (*bp++ >> 8) & 0xFF;
            write8(hi);
            write8(lo);

        }
    }
    CS_IDLE;
}

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

notro
Posts: 695
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: Adafruit LCD on 8bit interface

Tue Aug 26, 2014 6:25 pm

Maybe I wasn't clear enough:
I took my kernel I/O code logic (not mine really), put it into you're parallelWrite() and it was a bit faster than you're code.

With you're code I did 1000x full frame (320x240x2) which took ~8.8 seconds, that is 8.8 ms per frame. The same as you got on your scope: 9ms.
What I don't understand is how you get 9 ms per frame when you also have to toggle /WR for each byte?

User avatar
PeterO
Posts: 5024
Joined: Sun Jul 22, 2012 4:14 pm

Re: Adafruit LCD on 8bit interface

Tue Aug 26, 2014 9:43 pm

Ok, where you have gone wrong is to assume the 9ms was for a normal frame draw. It is not. :!:

It was (as it says in the post) for drawing the 320 column bar graph in the associated picture. That does not require changing the databus between writes as the pixels are only either white (for bottom part of each column) or black (for the top part of each column).

For a full 320x240 x 16 bit frame update from a memory buffer my code takes 19ms per frame. Using your method of building the bit patterns each time (rather than using a precomputed lookup table) slows it down to 33ms per frame.

These timings were taken by observing the activity on the WR-bar line while running my panadapter code drawing a waterfall spectrum display.

Something odd is happening because we can't both come to the conclusion that ours is the fastest code :lol:

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

danjperron
Posts: 3402
Joined: Thu Dec 27, 2012 4:05 am
Location: Québec, Canada

Re: Adafruit LCD on 8bit interface

Tue Aug 26, 2014 11:01 pm

Just wonder?

I did look at the parallel write function from previous post and I just thing that it could be faster if we write really in parallel mode.


The version I saw was creating set and reset mask bit by bit until the full 8 bit bus was set. But if we use bits that are in sequence order, we should be able to write the bus way faster.

So if bit0 .. bit3 are set to BCM8 to BCM11 and bit4 to bit7 are set to BCM22..BCM25, two simple 32 bit write to Set And Reset the GPIO will do the thing and it should be faster.

Code: Select all

#define PAGE_SIZE (4*1024)
#define BLOCK_SIZE (4*1024)

int  mem_fd;
void *gpio_map;

// I/O access
volatile unsigned long *gpio;

// GPIO setup macros. Always use INP_GPIO(x) before using OUT_GPIO(x) or SET_GPIO_ALT(x,y)
#define INP_GPIO(g) *(gpio+((g)/10)) &= ~(7<<(((g)%10)*3))
#define OUT_GPIO(g) *(gpio+((g)/10)) |=  (1<<(((g)%10)*3))
#define SET_GPIO_ALT(g,a) *(gpio+(((g)/10))) |= (((a)<=3?(a)+4:(a)==4?3:2)<<(((g)%10)*3))


#define GPIO_SET *(gpio+7)  // sets   bits which are 1 ignores bits which are 0
#define GPIO_CLR *(gpio+10) // clears bits which are 1 ignores bits which are 0
#define GPIO_READ  *(gpio + 13)


void setup_io()
{
   /* open /dev/mem */
   if ((mem_fd = open("/dev/mem", O_RDWR|O_SYNC) ) < 0) {
      printf("can't open /dev/mem \n");
      exit(-1);
   }

   /* mmap GPIO */
   gpio_map = mmap(
      NULL,             //Any adddress in our space will do
      BLOCK_SIZE,       //Map length
      PROT_READ|PROT_WRITE,// Enable reading & writting to mapped memory
      MAP_SHARED,       //Shared with other processes
      mem_fd,           //File to map
      GPIO_BASE         //Offset to GPIO peripheral
   );

   close(mem_fd); //No need to keep mem_fd open after mmap

   if (gpio_map == MAP_FAILED) {
      printf("mmap error %d\n", (int)gpio_map);//errno also set!
      exit(-1);
   }

   // Always use volatile pointer!
   gpio = (volatile unsigned long *)gpio_map;

} // setup_io


write8Bits(unsigned  char value)
{
 // assume bit 0..3   BCM8..BCM11
 // assume bit 4..7   BCM22..BCM25
// GPIO_SET/CLR  Will  set/reset the corresponding bit from the 32 bits input value 

//   1098 7654 3210 9876 5432 1098 7654 3210
//   0000 0011 1100 0000 0000 1111 0000 0000
 unsigned long Mask= 0x03C00F00
  unsigned long  GPIOBit;
// move bit0..bit3 to bit8..bit11, bit4..bit7 to bit22..bit25
  GPIOBit = (((unsigned long) (value & 0xf)) << 8) | \
            (((unsigned long) ( value & 0xf0)) <<18);

 GPIO_CLR(Mask);
 GPIO_SET(GPIOBit);
}
Daniel
Last edited by danjperron on Wed Aug 27, 2014 12:42 am, edited 5 times in total.

toxibunny
Posts: 1382
Joined: Thu Aug 18, 2011 9:21 pm

Re: Adafruit LCD on 8bit interface

Tue Aug 26, 2014 11:07 pm

If you don't mind me butting in for a second, I have a question...


The youtube vids demonstrating the various LCD screens seem to me to show excellent performance when running MAME stuff or emulating NES games, while other vids showing the desktop or full-screen-video look a lot choppier.

Am I just imagining that..?
note: I may or may not know what I'm talking about...

User avatar
PeterO
Posts: 5024
Joined: Sun Jul 22, 2012 4:14 pm

Re: Adafruit LCD on 8bit interface

Wed Aug 27, 2014 7:23 am

danjperron wrote:Just wonder?
I did look at the parallel write function from previous post and I just thing that it could be faster if we write really in parallel mode.
Both mine and notro's code do the actual port writes in parallel.
The version I saw was creating set and reset mask bit by bit until the full 8 bit bus was set. But if we use bits that are in sequence order, we should be able to write the bus way faster.
Yes that is correct
So if bit0 .. bit3 are set to BCM8 to BCM11 and bit4 to bit7 are set to BCM22..BCM25, two simple 32 bit write to Set And Reset the GPIO will do the thing and it should be faster.
That would certainly be faster that building the bit set/reset patterns one bit at a time, but without trying it I'm not sure if it will be faster than using the precomputed lookup table. The table method does retain the flexibility of being able to use an arbitrarily chosen set of GPIO pins.

I will try your method later and post some timings but I have some other things to do first....

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

User avatar
PeterO
Posts: 5024
Joined: Sun Jul 22, 2012 4:14 pm

Re: Adafruit LCD on 8bit interface

Wed Aug 27, 2014 7:29 am

toxibunny wrote:If you don't mind me butting in for a second, I have a question...
Since you asked, yes I do mind ;) Please start new a thread with an appropriately descriptive title for unrelated questions.
PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

User avatar
PeterO
Posts: 5024
Joined: Sun Jul 22, 2012 4:14 pm

Re: Adafruit LCD on 8bit interface

Wed Aug 27, 2014 9:31 am

Daniel, your method with a slight change to use a global for the Mask = 17ms.

I noticed you reset all the bits each time rather than just resetting the appropriate ones. If I make my code do that as well mine speeds up to 17ms. :roll:

I have not compared the assembler code that the compiler produced for our two methods yet.

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

danjperron
Posts: 3402
Joined: Thu Dec 27, 2012 4:05 am
Location: Québec, Canada

Re: Adafruit LCD on 8bit interface

Wed Aug 27, 2014 11:17 am

Yes PeterO,

The precompile Table to set and reset GPIO bits is a good alternative and the GPIO bits could be out of sequence.

I don't know which one will be faster?

As you said , an assembly listing will show it.

Daniel

User avatar
PeterO
Posts: 5024
Joined: Sun Jul 22, 2012 4:14 pm

Re: Adafruit LCD on 8bit interface

Wed Aug 27, 2014 1:08 pm

danjperron wrote:Yes PeterO,
The precompile Table to set and reset GPIO bits is a good alternative and the GPIO bits could be out of sequence.
I don't know which one will be faster?
Maybe I didn't make it clear, they are the same (to the accuracy that I can read from my scope screen.
As you said , an assembly listing will show it.
Daniel
I doubt it will give an accurate answer as too many other things to take into account other than just the instruction sequence....

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

notro
Posts: 695
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: Adafruit LCD on 8bit interface

Wed Aug 27, 2014 4:42 pm

Ok, where you have gone wrong is to assume the 9ms was for a normal frame draw. It is not.
"LCD", "320 vertical lines" and "~9ms" made me think that one full frame on the LCD took 9ms.
I've now got the LCD display working with the gpu_fft code to produce a new version of my panadapter.
Looking at a "sync" signal on my 'scope it is taking ~9ms to draw the 320 vertical lines that make up the spectrum graph seen above.

User avatar
PeterO
Posts: 5024
Joined: Sun Jul 22, 2012 4:14 pm

Re: Adafruit LCD on 8bit interface

Sat Aug 30, 2014 8:46 am

I'm now down to 14ms per frame (and no use of assembly!) 320x240x2 / 14ms = 10.5 Mbytes/sec :D

By studying the spec sheet for the ILI9341 I realised that the write sequence could be simplified.

Before

Clear databus bits
Set appropriate databus bits
Clear Write bit
Set Write bit

Now

Clear Databus AND Write bit
Set appropriate databus bits
Set Write bit

This is possible because the chip uses the rising edge of the write line to clock the data from the bus. There are 10ns Setup and Hold times which should not be a problem !
Consequently the write line can come down before the data is set and thus the clearing of the data bus and the clearing of the write line can be combined.

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

notro
Posts: 695
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: Adafruit LCD on 8bit interface

Fri Sep 05, 2014 2:44 pm

I have finally had time to test table lookup in my framebuffer driver.
I'm using a SSD1963 based 5inch 800x480 display with a 16-bit databus.

My regular code gives this (full frame update):
fb_ssd1963.0: Display update: 6347 kB/s (118.139 ms)

Adding a (256kB) lookup table gives this:
fb_ssd1963.0: Display update: 14648 kB/s (51.200 ms)

6MB/s => 14MB/s Quite an improvement I would say!

However there's a drawback, and that is probably because of noise/ringing/something.
Loading a console on the framebuffer is OK ( as long as I don't start 'top' or something that updates a large part the screen)
Starting X windows quickly destroys the display initialization and the display goes white.

I have 25cm wires between the Pi (model B rev.2) and the display, which isn't helpful I guess.
I'll see if I can get a breadboard and stack the display directly on top of the Pi to cut down on those wires.

I don't have a scope so I can't see what actually happens on those wires.
Will adding a small series resistor (10 ohm) on the databus lines be helpful?

The BeagleBone Black 4" LCD cape has an onboard 74AVC32T245: 32-bit dual supply translating transceiver with configurable voltage translation; 3-state
It is used on all the LCD signals, and since both the display and the BBB works at 3.3V it doesn't act as a level shifter.
What's the purpose of this arrangement? To clean up the signals? (your display also has a 74LVC245, but the purpose here is level shifting)


Thanks for sharing your work PeterO.


Refs:
BBB LCD cape schematic: https://github.com/CircuitCo/BeagleBone ... f?raw=true
74AVC32T245 datasheet: http://www.nxp.com/documents/data_sheet/74AVC32T245.pdf
Adafruit 2.8" schematic: https://learn.adafruit.com/assets/15463
74LVC245 datasheet: http://www.adafruit.com/datasheets/sn74lvc245a.pdf


Code details

Code: Select all

	while (len--) {
		/* Start writing by pulling down /WR */
		writel((1 << par->gpio.wr),  __io_address(GPIO_BASE + 0x28));

		/* set db pins */
		out = lookup->table[*data++];
		writel(out, __io_address(GPIO_BASE + 0x1C));
		/* reset db pins */
		out = ~out & lookup->mask;
		writel(out, __io_address(GPIO_BASE + 0x28));

		/* Pullup /WR */
		writel((1 << par->gpio.wr),  __io_address(GPIO_BASE + 0x1C));
	}
Which translates to this:

Code: Select all

	while (len--) {
 2dc:	0a000012 	beq	32c <fb_ssd1963_write_gpio16_wr_4+0xbc>
		/* Start writing by pulling down /WR */
		writel((1 << par->gpio.wr),  __io_address(GPIO_BASE + 0x28));
 2e0:	ee07cf9a 	mcr	15, 0, ip, cr7, cr10, {4}
 2e4:	e59510c0 	ldr	r1, [r5, #192]	; 0xc0
 2e8:	e1a01112 	lsl	r1, r2, r1
 2ec:	e5831028 	str	r1, [r3, #40]	; 0x28

		/* set db pins */
		out = lookup->table[*data++];
 2f0:	e0d700b2 	ldrh	r0, [r7], #2
 2f4:	e5961000 	ldr	r1, [r6]
 2f8:	e7914100 	ldr	r4, [r1, r0, lsl #2]
		writel(out, __io_address(GPIO_BASE + 0x1C));
 2fc:	ee07cf9a 	mcr	15, 0, ip, cr7, cr10, {4}
 300:	e583401c 	str	r4, [r3, #28]
		/* reset db pins */
		out = ~out & lookup->mask;
 304:	e5961004 	ldr	r1, [r6, #4]
 308:	e1c14004 	bic	r4, r1, r4
		writel(out, __io_address(GPIO_BASE + 0x28));
 30c:	ee07cf9a 	mcr	15, 0, ip, cr7, cr10, {4}
 310:	e5834028 	str	r4, [r3, #40]	; 0x28

		/* Pullup /WR */
		writel((1 << par->gpio.wr),  __io_address(GPIO_BASE + 0x1C));
 314:	ee07cf9a 	mcr	15, 0, ip, cr7, cr10, {4}
 318:	e59510c0 	ldr	r1, [r5, #192]	; 0xc0
 31c:	e1a01112 	lsl	r1, r2, r1
 320:	e583101c 	str	r1, [r3, #28]

PiGraham
Posts: 3609
Joined: Fri Jun 07, 2013 12:37 pm
Location: Waterlooville

Re: Adafruit LCD on 8bit interface

Fri Sep 05, 2014 3:29 pm

PeterO wrote:This is possible because the chip uses the rising edge of the write line to clock the data from the bus. There are 10ns Setup and Hold times which should not be a problem !
So if you passed the write line through a gate delay >10ns you could complete a cycle in two writes rather than three?

User avatar
PeterO
Posts: 5024
Joined: Sun Jul 22, 2012 4:14 pm

Re: Adafruit LCD on 8bit interface

Fri Sep 05, 2014 4:04 pm

PiGraham wrote:
PeterO wrote:This is possible because the chip uses the rising edge of the write line to clock the data from the bus. There are 10ns Setup and Hold times which should not be a problem !
So if you passed the write line through a gate delay >10ns you could complete a cycle in two writes rather than three?
It would seem that way, but I've not got the data sheet infront of me right now.....
PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

Return to “Interfacing (DSI, CSI, I2C, etc.)”