Это видео недоступно.
Сожалеем об этом.
fbcp-ili9341 ported to ILI9486 WaveShare 3.5" (B) SpotPear 320x480 SPI display
HTML-код
- Опубликовано: 25 май 2018
- Ported my fbcp-ili9341 Raspberry Pi 3 Model B SPI LCD display driver to work on the ILI9486 based WaveShare 3.5" (B) SpotPear 320x480 SPI display. This video is side by side comparison against the stock spi-bcm2835+fbtft+fbcp display driver set, running on Raspberry Pi 3 Model B.
Some games run well, others a bit less so.
Visit github.com/juj... to get fbcp-ili9341 for your Raspberry Pi + SPI display combo.
Wow amazing! I have a 3.5 inch Elecrow display that I think is ILI9486, I will try this as soon as I get back from work, this is exciting!
Awesome driver, works very well :D
Working with an Elecrow RR035 on a Raspberry Pi B+ v1.2
Oh, thank you Jukka for this great job!
ISO KIITOS!
Awesome! You're a genius, Jukka!
I have the Waveshare 3.5 pixel IPS version 480x320 and it runs smoothly. It took my a while to get it working with good resolution and refresh rate, but it wasn't even hard, it was lack of experience on my side.
Very nice to hear! I'd be curious to know what was the best refresh rate you are able to run with, to chart a bit the manufacturing variances on performance. Is it higher or lower than the 31.875MHz that the display on video is able to run at?
I wish I had the knowledge to give you a technical answer. On emulators it shows around 59.400MHz +- going up and down on a 0.100MHz+- threshold. I don't know how to show the numbers like you do on the video, I'm fairly new to the raspberry world. In fact I didn't answer before because I didn't know how to install the game. I did it today, and recorded the first run and the game runs smoothly.
I made a video to show you. If you want me to show the numbers like you do, tell me how you do it and I can upload a second one with numbers to show you. As for the screen I haven't done much other than modifying config.txt with instructions I found on forums, specifically 5 lines, so not really technical.
First run of opentyrian
/watch?v=nANS9qS0MuU
What I see on your video is that you have the composite version while I have teh HDMI version, that could be the reason.
I have to say that despite the refresh rate being around 59.500MHz+- some ghosting is noticeable while emulating (tried on my PC monitor and this doesn't happen) on GBA I don't see it that much, but emulating some NES games the ghosting is quite noticeable and annoying. I'm trying to see if there is something I can do to fix it, but I doubt it.
I'd like to know if you have the same problem with the composite version.
Hmm, the statistics numbers should be displayed by fbcp-ili9341 by default. Though there was a bug a week or two ago that made them not appear unless explicitly enabled, so if you git cloned while the bug was still present, then that might be the cause. Try `git pull`ing the repository code to latest, and/or build with CMake option -DSTATISTICS=1 to force-enable statistics numbers display, or even use -DSTATISTICS=2 to show more detailed frame timings chart. See doc notes about -DSTATISTICS here: github.com/juj/fbcp-ili9341#configuring-build-options .
I am not sure what you are referring to by composite vs HDMI? My WaveShare display was not via composite, but it goes through the GPIO pins (SPI). Is your Waveshare display connected to the Pi via a HDMI cable?
Oh sorry, I was confused that you would be using fbcp-ili9341 here, but now I see in ruclips.net/video/nANS9qS0MuU/видео.html that there seems to be the HDMI connector present on the top edge of the display. When you connect a WaveShare HDMI display to the Pi, fbcp-ili9341 is not used, but the Pi GPU drives the display directly. fbcp-ili9341 works for displays that use the SPI protocol over the GPIO bus, so no HDMI connection at all. WaveShare produces both HDMI and SPI versions of their displays, see the SPI variant at www.waveshare.com/product/modules/oleds-lcds/raspberry-pi-lcd/3.5inch-rpi-lcd-b.htm , and the HDMI variant at www.waveshare.com/product/modules/oleds-lcds/raspberry-pi-lcd/3.5inch-hdmi-lcd.htm . (I don't think they produce a composite version).
I cannot see ghosting on your video with HDMI, and also not with my SPI display when driven via fbcp-ili9341, perhaps it is more visible outside the camera. Though I do see tearing happen on your video, exactly like what happens on my KeDei 3.5" 320x480 HDMI display, video at ruclips.net/video/1yvmvv0KtNs/видео.html . Sadly, these HDMI based 480x320 displays do not seem to implement vsync.
Pls make a tutorial, I tried to do your tutorial several times with my generic 3.5 "display (without brand, 480x320 and based on ili9486) and I never get that kind of results, please
Sorry, missed this comment, quite while ago. For anyone else stumbling to this, it is possible that the max bus speed of the display is not particularly fast. See these links for installation help: @t, @ or @ or @
Will HDMI output be still working?
Wow, good job! do you know if you can get the same result with the Waveshare 3.5 inch RPi LCD (A) model? Thanks
My understanding is that the (A) and (B) models would be the same controller wise, so should work on (A) as well. I don't have one to test though.
Jukka Jylänki Can you create a video whit the step? Thanks
I can not make a video now, but you can find installation instructions at github.com/juj/fbcp-ili9341/blob/master/README.md#installation
after a day of compile text have image but still have vertical refresh, thanks.
Question: the color go very clear, is this fixable?
Thank you!
Awesome!!
Is this something that still works on the Pi5 with newest bookworm release? If so I'm going to try this.
Unfortunately Raspberry Pi Foundation no longer supports DispmanX and does not provide a functional replacement with the KMS driver, so fbcp-ili9341 strategy is no longer possible with Pi5 and forwards.
Your display looks incredible! I have your own screen (but Rev. 2) but my colors are a little bit corrupted. My gray seems to be like a kind of green, why can it be like that? Even if I determine my bus clock to 300, that continues happening.
Hard to say, I'm afraid. It is possible that different revisions of the display require subtly different initialization sequences for the display. ILI9486 initialization sequence can be found here: github.com/juj/fbcp-ili9341/blob/master/ili9486.cpp . (Interface Pixel Format, Power Control, VCOM Control, Gamma Control might have an effect here) One thing to check may be to try out the official driver that WaveShare advertises - and if that driver does not have the issue, then it most certainly is that something is different with the initialization sequence that the different revision requires. (If so, then the needed initialization sequence will probably need to be snooped off the hardware bus, since WaveShare keeps their display schematics a closed secret and does not publish any hardware/controller protocol information)
I have the same screen but the max SPI value I can get is 25mhz.
Awesome work! Btw what's the racing game around 5:40 called again?
Thanks! That one is Outrun, played via a remake in Cannonball Engine (reassembler.blogspot.com/p/cannonball-open-source-outrun-engine.html)
@@jukkajylanki4769 of course, thanks! Never played it, but looks amazing, I'm gonna see if I can find a copy :)
Is it possible to change the vertical interlacing to horizontal one?
The current code does not support that, but it would be technically feasible to develop if you want to write the code.
There may be some inefficiency caused by flipping the interlacing direction due to the direction that the write cursor naturally progresses (like reading a book first in horizontal order, then advancing to next scanline), that would have to be changed to an explicit vertical order write.
@@jukkajylanki4769 Ahhh, so the display is actually rotated 90 degrees to one side here, OK, doing it this way makes total sense to me now.
By the way theoreticaly those displays should work at 40mbps, because datasheet states the write cycle is 50ns.
Probably overhead from the 'SPI' implementation by Waveshare causes it to crap out at higher rate than ~32mbps?
@@akkudakkupl That might be. It is hard to say about the internals on the individual controllers. Some displays, like the ST7789 I recall were able to operate much faster than the cycle periods mentioned in the data sheets, so reality vs theory did not much meet either direction there.
Hey Jukka, can you tell me what are the exact params you are using to compile the driver?
Sorry, I do not have the display set up any more to recall the exact cmdline I used to build when making this video, but if my memory serves correctly, it would have been this command line: github.com/juj/fbcp-ili9341#build-example , but on the cmake line, for the WaveShare ILI9486 display, instead have "cmake -DWAVESHARE35B_ILI9486=ON -DSPI_BUS_CLOCK_DIVISOR=8 .."
Hi, how do you handle front and backbuffer for 320x480 ?, where did you get the RAM ? thanks
The display buffers of Raspberry Pi GPU are managed via snapshotting using DispmanX API. The driver remembers the previous snapshotted buffer (old framebuffer, what is currently being displayed on the SPI screen), and the current snapshotted buffer (what is going to be uploaded on to the SPI screen next). fbcp-ili9341 does not read the RAM/framebuffer memory of the SPI display at all, but the old framebuffer is essentially a memory of what is being currently displayed on the SPI screen at any given time, so it's practically a tracked Pi CPU-side copy of the SPI display memory contents.
Hi i actually use a RCA monitor and i want switch to the 3,5 LCD SPI, i actually use some pin for mk_arcade gpio controller driver, can i use the free pins changing it in the driver?
Check out the documentation here: github.com/juj/fbcp-ili9341#if-you-wired-the-display-to-the-pi-yourself . About half way of that paragraph, there is a section "pass the following to customize the GPIO pin assignments you used", which lists the pins that you can change. The other pins are fixed and must connect to the hardware SPI pins of the Pi.
How's the touch support? From what I've read on the GitHub repo, it's not implemented, is that the case or am I just understanding it wrong?
That is correct. The repository juj/fbcp-ili9341 does not have touch support; but developer kpishere has been working on touch support over on his fork at kpishere/fbcp-ili9341. I have not tested that however, but might be worth checking out if it works for your display as well.
@@jukkajylanki4769 Cool, thanks for the info. I was trying to get OctoPrint TouchUI to work on the SPI TFT, and it's pretty much almost unuseable, the way the standard drivers do refreshing, and not being able to use the touchscreen would kinda kill the whole point of the display in the first place.
so, will this work with the kuman 3.5 inch screen as well? I know the kuman screen works with lcd-show. but the display lag is real, even getting it up to a stable 30fps would be a godsend.
If you are referring to this display www.kumantech.com/kuman-35quot-inch-480x320-rgb-tft-lcd-pixels-touch-screen-with-touch-pen-for-raspberry-pi-3-2-model-b-b-a-a-module-spi-interface-sc06_p0014.html, then it is not something that is supported or tested. That display looks like it is a 3-wire SPI display, since there is no DC (Data/Command) line present. Kuman does not publicize what display controller the screen has, so you will need to reverse engineer the controller by sniffing the protocol from hardware lines, or identify the controller from the board if they have left visual markings on the chips/board. If you are able to find out what controller it has, and if it is something that is supported by fbcp-ili9341, you can try your luck the experimental 3-wire SPI support that was added just recently. (by specifying -DGPIO_TFT_DATA_CONTROL=-1 to CMake, see details in GitHub page)
@@jukkajylanki4769 I'm fairly new to all this, the screen was given to me with a coupple of pi3s that i bought from someone who wasnt using them. But the board looks like this: drive.google.com/file/d/1Fki2C9HkC9Cj9baXr1D_SD5EoDAzOIqy/view?usp=drivesdk
After a bit of tinkering with the options I'm at a loss. I'll probably just pick up a screen that's known to be compatible at some point. My eyes are kind of sucky in the first place so I can barely read the numbers on the individual chips on the back of this screen. It's awesome to see this regardless of whether or not I can personally make use of it though, so cheers to you for the work put into it all.
@@RedMageGamingThe Waveshare display that I have looks like this: imgur.com/a/KJxYkqN . That one is an ILI9486, and looks quite similar. None of the chips actually read out ILI9486, so not sure if it helps correlate or identify the board. Probably only way is to try and see, or try to dig deep in internet forums if someone might have been able to identify the controller. (If it does turn out to be ILI9486, I estimate it will likely not work with fbcp-ili9341 if it is 3-wire SPI connected - only 4-wire ILI9486s do, though don't have hardware to test)
@@jukkajylanki4769 Yea, I tried just about every combination I could, it tried to display to the screen but it was all garbage data, The screen still works fine for a mini console display but does nothing for video despite the kuman site saying otherwise lol
Hi, i don't understand how to install, can you help me?
See the documentation at github.com/juj/fbcp-ili9341, or see a tutorial video at ruclips.net/video/KciKqGX8g94/видео.html or ruclips.net/video/xOPVlq4kM9c/видео.html or ruclips.net/video/6C1kVnGUAY0/видео.html . Those have great information on how to proceed with the installation.
@@jukkajylanki4769 can you pass the image of your retropie?
it's more easy
xd
great job, now make a turtorial video because your github prj is hard to follow, especially that cmake cmd line
nuh-uh-uh! you're forgetting the magic word!
@@keropon He can't. He's an entitled brat whose had everything handed to him. He doesn't know how to ask politely, only demand.