Please DO NOT attach a ">5 Mpixel" photo here. Some folks will be bankrupted by it! If you must ... provide a link to it so those who don't mind its size can examine it.
That is no problem. I got a ILI9320 running in SPI mode quite nicely. It is obviously slower than native 8-bit or 16-bit mode. However it is faster than some Arduino TFT 16-bit libraries!
I would never bother with 16-bit unless I was using a 16-bit (or 32-bit) chip. 8-bit only costs you a SBI,CBI sequence. --- 4 cycles.
I layed out a board to connect my display to a Mega 1284. I arranged it for 16 bit. Now, I either etch one here and hand connect many jumpers on the bottom side, or send out. Laying it out was beyond my 1 sided home etching abilities. I included a connector for a NRF24L01, a power supply to run from 2 AA batteries and a boost converter to run the backlight LEDs.
Maybe I'll read again on 8 bit. Perhaps that will simplify the board enough I can make one here. That would also free up some pins on my 1284.
Wonder what it takes to use the touch sensor. It has X+, Y+, X- and Y- connections.
Oh. So you just read it with the A/D. That's handy.
#define T_YU PE7 // Pin 37 can be a digital pin
#define T_XL PE6 // Pin 38 can be a digital pin
#define T_YD PF3 // Pin 39 must be an analog pin, use "An" notation!
#define T_XR PF2 // Pin 40 must be an analog pin, use "An" notation!
Can you interpret T_YU, T_XL, T_YD and T_XR for me? These are where you connected the Y+, X-, Y- and X+ lines?
The largest known prime number: 282589933-1
It's easy to stop breaking the 10th commandment! Break the 8th instead.
I can now clear 320x240 pixels in 10mS and I can draw (diagonal) lines with Bresenham at an average of about 40 ticks per pixel.
That IS impressive. I have the Adafruit library doing a fillscreen() in 52ms and drawing a diagonal line in 172us. - with a SST1289 8-bit on an UNO.
Mind you, I removed a fillscreen optimisation for some reason or other. I might put it back and see the difference.
David.
p.s. I removed the optimisation because it does not work with SPI. The theoretical best time for fillscreen() would be 9.6ms. You achieving 10ms is really good! The theoretical best with SPI is 76.8ms.
Anyway, I don't see fillscreen() as the most important benchmark. Blitting real data from a bitmap or JPEG is more useful test. After all, how useful is a uniformly coloured blank screen?
Posted by andrewm1973: Fri. Apr 12, 2013 - 08:49 AM
1
2
3
4
5
Total votes: 0
Quote:
Anyway, I don't see fillscreen() as the most important benchmark. Blitting real data from a bitmap or JPEG is more useful test. After all, how useful is a uniformly coloured blank screen?
Well - I am waiting for frame flyback, clearing the screen and then drawing a scene once every 1/30 of a second. So in my application that doesn't show JPGs clear screen is pretty important :D.
Quote:
That IS impressive. I have the Adafruit library doing a fillscreen() in 52ms and drawing a diagonal line in 172us. - with a SST1289 8-bit on an UNO.
Is 172uS a typo? A diagonal line across the screen (0,0,319,239) is 400 pixles long. That only works out at 7 clocks per pixel at 16Mhz.
Mine takes 692uS for a full diagonal line (avg 28 clocks/pixel) using Bresenham. I did experiment with run length line algos, but most of my lines are short and the DIV kills RLL. Even still I don't think I would get down to sub 7 clocks.
Edit: Oops that 692uS was with some other things happening. It's 608uS at 25clk/pixel. Still a long way from 7.
I have tested three SPI solutions that seems to correspond to your problem.
The first one can be faster than parallel mode, and the 2 others are compatible with a restricted budget :
1) A $16.99 Sainsmart 3.2" 16-bit touch screen with a SSD1289 controller.
I have used a MCP23S17 I/O expander to provide a SPI connection with an atmega328.
There's a great benefit with the I/O expander : you don't have to send again the 16 bits of data when it remains the same.
For a fillscreen (or fill windows), you simply have to send the color data onece and then to toggle CS for each pixel.
An unoptimized fillscreen takes 9.6ms. And with a 30 levels loop unrolling optimization a fillscreen takes 5,2 ms.
It's based on a ILI9320 controller. Performance is low due to SPI limitations but yon can improve it by using your own SPI implementation.
Standard implementation relies on such a transfer function :
/// Transfers one byte over the SPI bus and receives one byte from slave
/// @param[in] data to send
/// @return received data
static uint8_t Transfer(uint8_t data)
{
DataRegister::Assign(data);
while (!TransferCompleted()) {}
return DataRegister::Get();
}
/// Tests if the last transfer is complete
/// @return true if last transfer is complete
static bool TransferCompleted()
{
return (StatusRegister::TestBits(1<<SPIF));
}
Defining a simpler asynchronous function :
/// Transfers one byte over the SPI bus without waiting for completion
/// @param[in] data to send
static void TransferAsync(uint8_t data)
{
DataRegister::Assign(data);
}
gives a good opportunity to perform graphics computations during the SPI transfer completion.
3) A $6.99 EastRising 2.8" SPI LCD Module
This module is based on a ILI9341 controller.
It's a very affordable solution but with it's tiny FPC-connector, I had a lot of difficulties to connect it and to make it work reliably.
treat
1..8 as 0..7
and
10..17 as 8..15
You'll be fine :)
- Log in or register to post comments
TopBTW - I note pin 21 is listed as N/C as usual.
If you give some nice high res photos of both sides of the FPC (like >5 Mpixel and clear) we can work out what the hidden pins are.
- Log in or register to post comments
TopPlease DO NOT attach a ">5 Mpixel" photo here. Some folks will be bankrupted by it! If you must ... provide a link to it so those who don't mind its size can examine it.
Cheers,
Ross
Ross McKenzie ValuSoft Melbourne Australia
- Log in or register to post comments
TopOh. Mystery solved. In 16 bit mode, you don't use DB0 or DB9.
If I make a big photo, I'll upload it somewhere, not attach it.
Attachment(s):
The largest known prime number: 282589933-1
It's easy to stop breaking the 10th commandment! Break the 8th instead.
- Log in or register to post comments
TopDave, I've pirated your thread. Sorry.
And don't order this one, it's not SPI, but it looks like I can use it.
The largest known prime number: 282589933-1
It's easy to stop breaking the 10th commandment! Break the 8th instead.
- Log in or register to post comments
TopThat is no problem. I got a ILI9320 running in SPI mode quite nicely. It is obviously slower than native 8-bit or 16-bit mode. However it is faster than some Arduino TFT 16-bit libraries!
I would never bother with 16-bit unless I was using a 16-bit (or 32-bit) chip. 8-bit only costs you a SBI,CBI sequence. --- 4 cycles.
Have you got everything working now?
David.
- Log in or register to post comments
TopI layed out a board to connect my display to a Mega 1284. I arranged it for 16 bit. Now, I either etch one here and hand connect many jumpers on the bottom side, or send out. Laying it out was beyond my 1 sided home etching abilities. I included a connector for a NRF24L01, a power supply to run from 2 AA batteries and a boost converter to run the backlight LEDs.
Maybe I'll read again on 8 bit. Perhaps that will simplify the board enough I can make one here. That would also free up some pins on my 1284.
Wonder what it takes to use the touch sensor. It has X+, Y+, X- and Y- connections.
Pretty impressed with what 10 bucks got.
Attachment(s):
The largest known prime number: 282589933-1
It's easy to stop breaking the 10th commandment! Break the 8th instead.
- Log in or register to post comments
TopJohn Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
- Log in or register to post comments
TopOh. So you just read it with the A/D. That's handy.
Can you interpret T_YU, T_XL, T_YD and T_XR for me? These are where you connected the Y+, X-, Y- and X+ lines?
The largest known prime number: 282589933-1
It's easy to stop breaking the 10th commandment! Break the 8th instead.
- Log in or register to post comments
TopDavid, You are obv. not a lunatic like I am. I am chasing every clock-tick I can :D
I can now clear 320x240 pixels in 10mS and I can draw (diagonal) lines with Bresenham at an average of about 40 ticks per pixel.
- Log in or register to post comments
TopYou supply power to 2 legs and read the "wiper", then do the same for the other "pot".
By the way should we split the thread away from the original SPI version?
David may want to comment on this too.
John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
- Log in or register to post comments
TopThat IS impressive. I have the Adafruit library doing a fillscreen() in 52ms and drawing a diagonal line in 172us. - with a SST1289 8-bit on an UNO.
Mind you, I removed a fillscreen optimisation for some reason or other. I might put it back and see the difference.
David.
p.s. I removed the optimisation because it does not work with SPI. The theoretical best time for fillscreen() would be 9.6ms. You achieving 10ms is really good! The theoretical best with SPI is 76.8ms.
Anyway, I don't see fillscreen() as the most important benchmark. Blitting real data from a bitmap or JPEG is more useful test. After all, how useful is a uniformly coloured blank screen?
- Log in or register to post comments
TopWell - I am waiting for frame flyback, clearing the screen and then drawing a scene once every 1/30 of a second. So in my application that doesn't show JPGs clear screen is pretty important :D.
Is 172uS a typo? A diagonal line across the screen (0,0,319,239) is 400 pixles long. That only works out at 7 clocks per pixel at 16Mhz.
Mine takes 692uS for a full diagonal line (avg 28 clocks/pixel) using Bresenham. I did experiment with run length line algos, but most of my lines are short and the DIV kills RLL. Even still I don't think I would get down to sub 7 clocks.
Edit: Oops that 692uS was with some other things happening. It's 608uS at 25clk/pixel. Still a long way from 7.
- Log in or register to post comments
TopI have tested three SPI solutions that seems to correspond to your problem.
The first one can be faster than parallel mode, and the 2 others are compatible with a restricted budget :
1) A $16.99 Sainsmart 3.2" 16-bit touch screen with a SSD1289 controller.
I have used a MCP23S17 I/O expander to provide a SPI connection with an atmega328.
There's a great benefit with the I/O expander : you don't have to send again the 16 bits of data when it remains the same.
For a fillscreen (or fill windows), you simply have to send the color data onece and then to toggle CS for each pixel.
An unoptimized fillscreen takes 9.6ms. And with a 30 levels loop unrolling optimization a fillscreen takes 5,2 ms.
2) A $14 Thaoyu Electronics 2.8" SPI touch screen (model HY28A LCDB)
It's based on a ILI9320 controller. Performance is low due to SPI limitations but yon can improve it by using your own SPI implementation.
Standard implementation relies on such a transfer function :
Defining a simpler asynchronous function :
gives a good opportunity to perform graphics computations during the SPI transfer completion.
3) A $6.99 EastRising 2.8" SPI LCD Module
This module is based on a ILI9341 controller.
It's a very affordable solution but with it's tiny FPC-connector, I had a lot of difficulties to connect it and to make it work reliably.
- Log in or register to post comments
TopThe ILI9341 is a lovely controller. It handles rotation seamlessly.
With the ILI9320, ILI9325 you have to transform your X, Y coordinates in software.
Have you looked at the http://www.ebay.co.uk/itm/1PC-2-2-Inch-SPI-TFT-LCD-Serial-Port-Module-Display-ILI9341-5V-3-3V-New-/380708838265?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item58a403db79 modules?
Ok, there is no touchscreen but you get a SD Card socket.
As far as I can see, all makes of TFT controller have multiple interface types. However, you can't always get at the IM# configuration pins.
I can't see any point in using a SPI bus-expander when you could use native SPI on the controller in the first place !
But yes, you can do the "fillScreen" optimisation if you can provide the colour on a 16-bit parallel bus.
David.
- Log in or register to post comments
TopYes, I have one of these modules but I have paid twice your price !
- Log in or register to post comments
TopI have two of those modules. I paid more for the first one. (but not 2x)
David.
- Log in or register to post comments
TopPages