SPI vs SPI and a TFT display

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've seen people say they can write pixels out to a TFT display faster using SPI than 16 bit parallel. This sounds incredulous to me.

 

Is it because, by the time I've output both bytes, set the write pin low, then back high, SPI has finished sending the 2 bytes and is waiting impatiently for all this other bit twiddling to finish?

 

My 16 bit code:

	LCDDataHighPort.OUT = dat>>8;
	LCDDataLowPort.OUT = dat & 255 ;
	LCDWRPort.OUTCLR = 1<<LCDWRPin;
	LCDWRPort.OUTSET = 1<<LCDWRPin;

I'm using xMega, so I can set or clear a bit with one instruction rather than having to read the port, set the bit and write it back out.

 

What would the appropriate SPI code look like? Perhaps:

 

	while(!(SPIC.STATUS & (1<<7)));
	SPIC.DATA = data>>8 ;
	while(!(SPIC.STATUS & (1<<7)));
	SPIC.DATA = data & 0xff;

Perhaps, if there's other code in the output loop, I could do some of it between the to SPIC.DATA outputs while the first byte is being sent?

 

So, who made up the list of "Application Tags?" None of them seem to have any relation to the subject.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Torby wrote:

I've seen people say they can write pixels out to a TFT display faster using SPI than 16 bit parallel. This sounds incredulous to me.

 

please be nice.

 

 

I have no special talents.  I am only passionately curious. - Albert Einstein

 

Last Edited: Sat. Sep 20, 2014 - 12:22 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A regular UNO has no 'entire' 8-bit port.   So Shields tend to use D8, D9 and D2-D7.    This means you have to do a few ANDs and ORs to drive an 8-bit 8080 interface.    A UNO has no chance of finding 16 GPIO pins for a 16-bit interface.

 

So yes,   an 8MHz SPI is 'comparable' but slower than 8-bit 'mixed' port pins.

 

Now if you are using digitalWrite() for each pin on an Arduino,    the hardware SPI wins every time.

 

Likewise,    the FRDM or NUCLEO boards with MBED are crippled by random bits.    And since STM32 and Kinetis chips have different GPIO,    it is easier to use the MBED BusOut or BusInOut class.    So even a 100MHz M4 is slower than an AVR.

 

Of course,   an Arduino MEGA has 2 straight 8-bit ports.    So can write to a TFT very fast.     And the MEGA has b*ggered the SPI pins.    So as bit-bashed SPI is really bad news.    (and the MEGA seems to have omitted the XCK pins from every USART_MSPI port)

 

Oh,   and many M0+, M3 and M4 chips have DMA.    As does the Xmega.    So if you have straight parallel ports or regular SPI,    the DMA can ease the work.

 

David.

Last Edited: Fri. Sep 19, 2014 - 11:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:

A regular UNO has no 'entire' 8-bit port.   So Shields tend to use D8, D9 and D2-D7.    This means you have to do a few ANDs and ORs to drive an 8-bit 8080 interface.    A UNO has no chance of finding 16 GPIO pins for a 16-bit interface.

 

If you don't need the hardware UART (D0 & D1), then portD gives you a full 8-bit port.

 

I have no special talents.  I am only passionately curious. - Albert Einstein

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use xMega chips, not arduino.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you are using Xmega,   you can write as fast as the TFT chip can manage.    e.g. OUT VPORT0,hi / OUT VPORT1,lo / OUTCLR wr / OUTSET wr.

I make that 4 cycles @ 32MHz = 125ns.

16MHz SPI is going to take 1000ns.   i.e. 2 bytes x 500ns.

 

Untested.    But it looks like 8x faster to use parallel rather than SPI.

Even 8-bit parallel is only 6 cycles.

 

Of course,   there is significant time involved in fetching the data and housekeeping.    If you use USART_MSPI,   the hardware is looking after blitting the SPI while you are doing your housekeeping.     This still can't keep up with parallel.

 

Regarding PORTD.0 and PORTD.1 on a UNO.     Yes,   you can write to these bits and 'win' against the USB chip.    You run into difficulties when reading the TFT bus.

 

David.

Last Edited: Sat. Sep 20, 2014 - 06:41 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Torby wrote:
I've seen people say they can write pixels out to a TFT display faster using SPI than 16 bit parallel.

But in what context did "they" say that?

 

This sounds incredulous (sic?) to me.

I think you mean "incredible" (as in "not credible") ?

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So if your hardware is lame and can't put out 16 bits in two cycles, SPI is faster.

 

My hardware is fast, though perhaps still lame

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No,    I am just stating the theoretical limits.    e.g. an AVR doing a 16-bit parallel write or SPI @ F_CPU/2.

This does require some care when writing the code.   e.g.  avoiding function overheads.

 

I have personal preferences.    e.g. minimal wiring,   reasonable speed.

I also like to have straightforward code.

 

If you use the Arduino digitalWrite() or MBED PinName() classes,   you get appalling performance.

Since you always know your wiring in your own projects,    you can hard-code it at Compile-time.

 

In which case you can get reasonable results while still getting the comfortable Arduino or MBED environment.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So if your hardware is lame and can't put out 16 bits in two cycles, SPI is faster.

How can that be? Even at X2 speed the SPI can only send out a byte in 16 cycles.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hardware being lame enough you have to scramble the bits to different pins on different ports.

 

I'll stick with 16 bit parallel and 4 cycles.

 

In a few places, I have intervening instructions to figure out which color to put out. I'll have to tinker a bit to find which way is faster. Hmm. It appears I haven't been executing the code I've been editing. No wonder my result was confused.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Inspect your generated ASM.    There can be a big difference with "valid translation" and "best possible".

Mind you,   GCC is pretty good for producing efficient code both with and without shoes and socks!

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

scramble the bits to different pins on different ports.

I see, I had to sort of do the same thing with the LPC1114 as it only had 12 bit ports and I had to use some from another port.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly