Hi all!
I’m trying to replace the Adafruit 2.8" piTFT with the Adafruit piTFT 3.5" (because at age of 42 I have some problems with little displays… )
In my opinion, there are two basic tasks to do it:
The kernel/module driver given by Adafruit is different for the two displays (in other words, it is not sufficient to change the line regrading the module and the resolution/refresh-rate in /boot/config.txt). So, in order to use it, I think it could be necessary to follow the installation instructions reported in https://learn.adafruit.com/adafruit-pitft-3-dot-5-touch-screen-for-raspberry-pi/detailed-install.
I think I will try today.
The resizing of the GUI. I read in another post that the GUI is fixed size at 2.8" screen resolution.
So I would like to study the possibility to have an auto-resizing GUI, depending on the screen resolution. It is a very interesting for me. Some years ago I realized at work a GUI for a Windows console which was auto-resizing (many years ago… …now as project manager I abandoned the implementation phases)… so it could be a good rentrée!
I will advise you all about the progress (which can be also not so good… )
I was experimenting with scaling the GUI up to use it with a 5 inch 800 x 480 display. This experiment is on hold while I’m building the rest of the Zynthian box. I’m not much of a Python specialist, but the gui code is quite readable & scaling the UI up by integer factors (x2…) looks ‘do-able’. RPi is a nice environment for development since you can ssh into the box & modify the python scripts directly.
The display that I’m using has HDMI input & it’s working without any kernel or driver changes…
The pitft35r overlay (driver) is not included in the current raspbian kernel/firmware, so you should follow the instructions from Adafruit. Good luck!
In the other side, the piTFT 3.5" has a resolution of 480x320, so you will have to re-scale the Zynthian GUI.
I think that auto-resizing can be difficult to optimize with small screen sizes. I think we will get better results having a different “geometric parameter set” for every resolution. So, it would be nice if we could abstract all the geometric parameters to a configuration array/file. Currently it is “more or less” hardcoded in the “zynthian_gui.py” file.
Hi @jofemodo!
Thank you for your suggestion!
I tried to install the driver of piTFT 3.5 in the kernel of current Zynthian image… but I had some problem on boot (Zynthian with installed PiTFT 3.5 displays the startup kernel initializations, and after this the display turns to black). Starting from a fresh Raspian, I think the behavior is the same, so I think the problem is connected the Raspian current version. I will investigate this.
You are right Jose, I need a lot of luck this time.
PS: I see that the HDMI solution is surely better and already working (thank you very much @Andy for suggestions), but I love challenges …so I think I will spend some night on this problem before to declare “white flag”
Zynthian GUI runs in “/dev/fb1”, while all the booting process and console ttys uses “/dev/fb0”.
You can change this in the “/etc/init.d/zynthian” init script.
Regarding HDMI, yes, it’s easy to configure, but, case-integration is more complex if you use the RBPI HDMI connector. Moreover, it’s very convenient to have the HDMI connector available for debug tasks, or, for “future uses” (VJ-ing software??
Hi @jofemodo!
Aheemmm …I readt this on another discussion,but I didn’t remember it!Thank you very much again!
Well,you are right about HDMI…using SPI is surely more safe for future needs. I was thinking also to a possible use of DSI displays connector…but…I don’t know…what do you think about this?It could be a good alternative to SPI?
Well…anyway I would prefer use SPI display, so I will study on this direction.
Cheers,
Marco
Of course, DSI is the best way of connecting a display to the RBPi, because it connects the display directly to the GPU, avoiding the framebuffer, and accessing to all the acceleration functions, but, as you probably know, the RBPi GPU documentation is partially closed to the community. Broadcom don’t want to open this subsystem to the public, avoiding 3rd party developments that uses the DSI connector. So, as far as i know, the only working DSI display for the RBPi is:
Hi @jofemodo!
Mhhhhh…I don’t like closed solutions.
So I think SPI (also if not so optimized) for me is the best way!
Thank you very much for the clarification Jose!
Ciao!!
Marco
Hi @jofemodo!
After some experiment with Adafruit piTFT 3.5" starting from your Zynthian image I had no good result…
I applied the kernel patch from Adafruit for piTFT 3.5, but I obtained that 3.5 display is flickering and, the strangest thing is that Zynthian error splash screen appears (sometimes during flickering).
Connecting the box with ssh, I stopped Zynthian software with /etc/init.d/zynthian stop, and then I restarted the service, so I saw there are some error tied to the GPIO which cannot be initialized.
Doing the same actions (stop/start zytnhian service) with a box with original zynthian system onboard (and with 2.8 tft connected) no error appear on GPIO iniziatialization (so all works correctly).
…The problem is that the Adafruit procedure does a kernel patch and I have no control on it.
So, I started to study the notro/FBTFT driver in order to patch the kernel and install modules on myself to have a more clear view of the problem (and to solve it if necessary).
A question… I see that you also used the Adafruit automatic kernel patch to enable piTFT 2.8 in the setup script setup_system_rbpi_wheezy.sh (using curl -SLs https://apt.adafruit.com/add | sudo bash and sudo apt-get install -y raspberrypi-bootloader ), but these two lines are commented in the new setup script setup_system_rbpi_jessie.sh . Why?
Is the piTFT 2.8 support provided natively in Jessie distribution or I’m loosing some detail?
Thank you very much for your support!
Cheers,
Marco
PS: you was right… I need a lot of luck to solve this trick!
Thank you very much for your suggestion dear @jofemodo!
My investigation continues… I started from the modded kernel by Adafruit, then I started to apply all your changes and installations reported in your script setup_system_rbpi_jessie.sh.
But it is a loooooong process, so I’m working on it in several parts…
I will update you when I will have some result!
Bye!
Did anyone ever manage to make the piTFT 3.5" work? Seems like the current DT Overlays do not include a way to switch the touch sensor axes. Any ideas? Info would be greatly appreciated.
We have a customization tree, where we can add customized config files & scripts for every device (displays, soundcards, etc). To be concrete, i think you could find something useful here:
This is the script used by the PiTFT 2.8" for adjusting the orientation of touch device
Hi Jo,
I’m trying to get the Adafruit 3.5’ working right now. Saw your post about the configuration file - how do I go about installing it? Do I need to use the webconfig tool?
Welcome to the Zynthian community!! I never tried the PiTFT 3.5", only the PiTFT 2.8". Anyway, there is a configuration for the PiTFT 3.5" available from the webconf tool. It should work, at less the video, not sure of the touch device.
Please, test it and tell me if it works or you get a blank screen or the touch device oesn’t work.
)
…now as project manager I abandoned the implementation phases)… so it could be a good rentrée! 
)
…now as project manager I abandoned the implementation phases)… so it could be a good rentrée! 
)
