jrseriel
Posts: 6
Joined: Fri Mar 31, 2017 7:45 pm

Would this screen work with Raspberry Pi Zero W

Mon Apr 03, 2017 7:48 pm

Hello again,

I was wondering if this screen would work with Raspberry Pi Zero W as it does have ILI9341. Just want to be sure and that the drivers exist that could work this display, and touch.

http://www.ebay.com/itm/like/2820668197 ... noapp=true

Thank you in advance!

User avatar
bitbank
Posts: 252
Joined: Sat Nov 07, 2015 8:01 am
Location: Sarasota, Florida
Contact: Website

Re: Would this screen work with Raspberry Pi Zero W

Tue Apr 25, 2017 1:40 pm

I ordered one of those displays and am currently waiting for it to arrive. I intend to connect it to a RPi0W as well. I don't know about any available driver software. I have the data sheet and will be writing my own software (in C/ASM) to drive it from my game emulator. My idea is to make it run at 60fps by using efficient partial-screen updates and hardware scrolling to avoid sending the entire buffer for each frame. At its rated maximum SPI data rate, it can potentially update at 30-39fps. I expect the practical data rate to be less and therefore have created a system of 'dirty' tiles and scroll detection to send only the necessary changes. I'll publish my code when it's working. I've written console and coin-op emulators for many systems and would probably start by open-sourcing my GBC/NES emulators since they're unlikely to have commercial value due to Nintendo's attitude about emulation.
The fastest code is none at all :)

User avatar
bitbank
Posts: 252
Joined: Sat Nov 07, 2015 8:01 am
Location: Sarasota, Florida
Contact: Website

Re: Would this screen work with Raspberry Pi Zero W

Tue Apr 25, 2017 8:16 pm

As luck would have it, I received it today in the mail. I will be busy getting it working tonight. I'll first publish a simple C project on github with initialization and simple functions for pixels and text (similar to my oled_96 and nokia5110 projects). Next, I'll publish the code to do smart frame buffer management.
The fastest code is none at all :)

jrseriel
Posts: 6
Joined: Fri Mar 31, 2017 7:45 pm

Re: Would this screen work with Raspberry Pi Zero W

Tue Apr 25, 2017 11:30 pm

Very cool! Keep me posted on how it works out for you.

User avatar
bitbank
Posts: 252
Joined: Sat Nov 07, 2015 8:01 am
Location: Sarasota, Florida
Contact: Website

Re: Would this screen work with Raspberry Pi Zero W

Wed Apr 26, 2017 3:21 am

I've got it working by using the WiringPi interface to set up the SPI transfers, but I think there is something not optimal in the data transfers. I'm setting the data clock to 62.5Mhz, yet the screen updates appear to be much slower than that. My next move is to not use WiringPI and set up the SPI bus myself. I'm guessing that the _NO_CS mode is what I'm looking for because I'm using a GPIO pin for the chip select.

I'm happy it works, but it's currently running much too slow to do video games. More info soon...

Image
The fastest code is none at all :)

User avatar
Gavinmc42
Posts: 4292
Joined: Wed Aug 28, 2013 3:31 am

Re: Would this screen work with Raspberry Pi Zero W

Wed Apr 26, 2017 3:42 am

I thought there was a framebuffer driver for these ones.
Are they not the same chip as the Adafruit display which have a SPI device driver?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

User avatar
Gavinmc42
Posts: 4292
Joined: Wed Aug 28, 2013 3:31 am

Re: Would this screen work with Raspberry Pi Zero W

Wed Apr 26, 2017 3:51 am

https://github.com/torvalds/linux/tree/ ... ging/fbtft

Hmm, I have a 7735 1.8", support for that is there too?
Device tree stuff messing about needed?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

User avatar
bitbank
Posts: 252
Joined: Sat Nov 07, 2015 8:01 am
Location: Sarasota, Florida
Contact: Website

Re: Would this screen work with Raspberry Pi Zero W

Wed Apr 26, 2017 11:14 am

Gavinmc42 wrote:I thought there was a framebuffer driver for these ones.
Are they not the same chip as the Adafruit display which have a SPI device driver?
The point of my project is that I'm trying to work with the display in an optimal way without the use of a framebuffer driver. My goal is to maintain a screen refresh rate of 60fps for running classic video games.
The fastest code is none at all :)

User avatar
bitbank
Posts: 252
Joined: Sat Nov 07, 2015 8:01 am
Location: Sarasota, Florida
Contact: Website

Re: Would this screen work with Raspberry Pi Zero W

Thu Apr 27, 2017 11:03 pm

I still can't get fast data throughput to the ili9341, but with partial screen updates, some games can run at 60fps:

https://www.youtube.com/watch?v=tKnL1sJpcNo
The fastest code is none at all :)

User avatar
Gavinmc42
Posts: 4292
Joined: Wed Aug 28, 2013 3:31 am

Re: Would this screen work with Raspberry Pi Zero W

Fri Apr 28, 2017 2:22 am

Kernel Framebuffer will be slower?
Won't be able to play videos on the TFT?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

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

Re: Would this screen work with Raspberry Pi Zero W

Fri Apr 28, 2017 12:48 pm

> I still can't get fast data throughput to the ili9341

Do you use DMA?

I can do 30fps with a 320x240 RGB565 display: viewtopic.php?f=44&t=178291&p=1136425#p1136425

Non DMA transfers get a gap byte that can be removed: viewtopic.php?f=44&t=181154

The fbtft kernel drivers which supports many of these displays has 2 shortcomings (in this context):
- Can't control when flushing happens
- Can only do partial flushing the whole width of the display

tinydrm which is the fbtft successor adresses both these issues, but there's no mainline support for this 2.2" display.
https://github.com/notro/tinydrm/wiki

User avatar
Gavinmc42
Posts: 4292
Joined: Wed Aug 28, 2013 3:31 am

Re: Would this screen work with Raspberry Pi Zero W

Fri Apr 28, 2017 1:23 pm

Thanks notro
For the tinydrm link, not that it make sense to me yet :oops:
My apps are baremetal, sort of. I want to get the TFTs running in Ultibo.

Probably should get it going in Linux first, Raspbian then piCore.
Then Laz/FPC, then Ultibo?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

User avatar
bitbank
Posts: 252
Joined: Sat Nov 07, 2015 8:01 am
Location: Sarasota, Florida
Contact: Website

Re: Would this screen work with Raspberry Pi Zero W

Fri Apr 28, 2017 3:20 pm

notro wrote:> I still can't get fast data throughput to the ili9341

Do you use DMA?

I can do 30fps with a 320x240 RGB565 display: viewtopic.php?f=44&t=178291&p=1136425#p1136425

Non DMA transfers get a gap byte that can be removed: viewtopic.php?f=44&t=181154

The fbtft kernel drivers which supports many of these displays has 2 shortcomings (in this context):
- Can't control when flushing happens
- Can only do partial flushing the whole width of the display

tinydrm which is the fbtft successor adresses both these issues, but there's no mainline support for this 2.2" display.
https://github.com/notro/tinydrm/wiki
Most of the time, I'm sending 512 bytes in each write (16x16 tiles). I did some more testing today and found that the PIGPIO code can transfer data fast enough for my needs, but the wiringPi (or Linux file handle access) are about 3x slower. I'm able to use the PIGPIO version in a little sample app (running as root), but when I link it into my larger app, it gives an "unhandled signal 27" when I call the gpioInitialise() function. Is there any way to get faster access without running as root?

Can you describe how DMA affects the transfers and how to enable it?

I'd like to avoid using the framebuffer driver because this code may run on various baremetal devices and I have more control over latency by optimizing the display writes myself.
The fastest code is none at all :)

User avatar
bitbank
Posts: 252
Joined: Sat Nov 07, 2015 8:01 am
Location: Sarasota, Florida
Contact: Website

Re: Would this screen work with Raspberry Pi Zero W

Fri Apr 28, 2017 6:07 pm

I switched to the bcm2835 library and it's faster than wiringPi, but slower than PIGPIO. The good thing is that my emulator app works running as root when using the bcm2835 code. Is the speed difference because DMA mode is not enabled by default in the bcm2835 code?
The fastest code is none at all :)

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

Re: Would this screen work with Raspberry Pi Zero W

Fri Apr 28, 2017 9:35 pm

I don't know the spi userspace libraries, but afaik only the spi-bcm2835 kernel driver uses dma.
If the bulk of your transfers are 512 bytes, I'm not sure if there will be much/any gain in using DMA.
The best way to know for sure is to look at the MOSI signal and see if there are gaps that you don't utilize.

User avatar
bitbank
Posts: 252
Joined: Sat Nov 07, 2015 8:01 am
Location: Sarasota, Florida
Contact: Website

Re: Would this screen work with Raspberry Pi Zero W

Mon May 01, 2017 12:49 pm

Latest news...

The DMA/no-DMA issue doesn't seem to have any real effect on performance. Different hardware has a large effect. PIGPIO is the performance winner on all platforms, but was causing signal 27 problems when running inside my game emulator. I rebuilt PIGPIO with the EMBEDDED_IN_VM define to disable logging and that solved the signal 27 problem. This causes a new problem - if you don't properly shut down the PIGPIO library (e.g. your program quits in the middle or you kill it with ctrl-z), it will leave running threads and prevent you from initializing it again.

As far as performance...
When running on my RPi 3B, and setting the SPI bus to 32Mhz, filling the framebuffer with a solid color (writing in large blocks) is able to achieve 17FPS. On my RPi 0W, the same code is able to achieve 34FPS. It seems odd that a slower machine is able to run twice as fast. I remember reading somewhere that someone else had encountered the same problem. Maybe someone here can shed some light on it.

I added hardware scrolling support to my code and it works quite well. I'm going to add it to my game emulator this week and see if side scrollers like super mario would see improvement by using it.

My ili9341 project now includes support for working with the display in portrait or landscape mode (including text and tile drawing). The scrolling is only possible in the portrait direction due to the simple hardware implementation.

I'll publish my ili9341 code soon and shortly after my game emulator. It's coming along well and shouldn't take too much more time.

Here's a video of Super Mario Brothers (NES) running at 60fps without hardware scrolling support. There is a slight lag when the title banner is scrolling, but otherwise holds a steady framerate. Once I enable hardware scrolling, this will be rock solid 60fps.

https://goo.gl/photos/A93iA4GPy2rB8jhU9
The fastest code is none at all :)

Return to “Other projects”