'Getting started' with pitft for GUIs rather than X

[Maxx2206]

Hi,

i recently purchased a pitft plus 480x320 Display after already owning a smaller rpi-display.
now i am having a slightly hard time getting started using them.
i used to build Hardware based on AVRs and later learned to like using arduinos for prototyping and the easyness of using additional Hardware like Displays and various sensors with them.

now im totally excited about the possibilities of the pi 2, especially thinking about the GUI powered aspects for some Project ideas.
but heres where iget stuck... almost all Basic tft Setup guides explain how to set up raspberry Systems to use the tiny Displays as replacement Display for booting and using x on them. but thats not really what i was aiming for.
i rahter wanted to program the Display directly, e.g. for GUIs or to draw what the project was built for (graph Displays of analog Inputs for data logging/Monitoring pujrposes).

unfortunately my Little Linux experience is already quite dusty, plus i wasnt able to easily find any references about how to just set up such Displays and start programming them with drawing functions etc. without launching x and using window based apps etc.

so far my understanding is that you install a Framebuffer Driver (or use a recent raspbian Image which has fbtft included). then in your code (still new to python, maybe i'll just try to get along with the c i know ^^) you just open a handle to this Frame buffer and use appropriate libs (or revert to pygame if anything else Fails) and their draw functions o directly Access the Display Memory.
is that basically correct? and if so... does anyone know any good places for pi beginners to get deeper into the Basics of this Topic?
specifically how to enable the Display for a start in raspbian (maybe minibian as many project dont really require a fully Features os and it would be a waste of space and Startup time to boot a full raspbian) and get Basic Access to it.

while the original notro/fbtft repository states that the 3,5" adafruit Display isnt supported i already had a look into the repository of whats included in the raspbian Distribution and it seems the hx8357 Driver made it into it.

im still really excited about the pi and the nifty Hardware available for it, but ist a bit frustrating if you have to start from scratch and realize that certain Topics arent widely covered for beginners or "cross platform" switchers :(

maybe someone can help me over the initial "obstacles" so i can start working on some of the many project ideas that would be using this (or similar) Displays.

thanks in advance.

PS. please forgive the weird casing in my post.. apparently my browser switched to spell checking mode in forms which messes up all english Posts and i have yet to remember where to disable it :)

[Bel_Z_Bub]

pythons pygame is an easy way to make a nice GUI on the piTFT. python is also quite easy to learn. you can find many examples in the learning system of this website that can help you get started. or maybe this link or maybe this one also shows how to make a GUI in steps.

[Maxx2206]

Hi,

thanks a lot.
These look like very good places to start getting into the actual python/pygme/GUI topic indeed.

Now i just need to fiddle a bit with the initial activation/framebuffer/setup part. I am still a bit confused as almost every display seems to be based on different display controllers...plus some examples set up their displays using display names (e.g. "sudo modprobe fbtft_device name=adafruit22") while in the actual sources all i can see is display controller names (like the hx8357d which should be the one used by adafruits 3.5" display).

for a general understanding of the "bare" setup...
- i have to make sure spi is enabled
- the display driver needs to be registered (by "sudo modprobe fbtft_device name=XXX" where from my current understanding
XXX is either a clear name like adafruit22 which includes the required params or will i have to setup anything manually for the
3.5" pitft with its 8357d chipset?)
"sudo modprobe fbtft_device name=list" should (hopefully) give me clarification since i cant find anything bigger than the adafruit2.2" tft
on the fbtft wiki pages nor any reference to the hx8375d controller used on the 3.5" display although the corresponding source
file is listed on the source code page.
thats about the most confusing part at the moment :(
- if successful, the framebuffer will be accessible via /dev/fb1 from my code

does that sounds right or am i wrong about anything so far?

thanks in advance...

[Maxx2206]

hi,

ok.. just checked... neither is there a pitft35 or adafruit35 like device in the supported fbtft list, nor a generic hx8357d :(

right now i'm sort of stuck... i even went back to plugging the 2.8" rpi-display in which has a dedicated driver withing fbtft but except for a single short "blink" upon activation it doesnt seem to work either. running the linked menu-py script after activating the driver opens on the x desktop rather than the tft display..

kinda BANNED tbh...

[Bel_Z_Bub]

why not use the adafruit kernel? works great with the 3.5" for me. its based on notros stuff and tweaked by adafruit for their own products so you can't go wrong really. see if you can get the console displaying on the screen. go from there. dont start x at all, control the pi from the command line or ssh

That said, the 3.5" is the slowest of all screens and also a resistive screen which shares the SPI for touch and display. with complicated interfaces with lots of buttons (e.g an onscreen keyboard) this will reduce the framerate you can run your GUI on. on a pi2 its not that much of a problem but on older pi's it is for sure. most people dont notice this because they use the same example that does everything on mousedown with a debounce timer. but if you want to program more complicated stuff like sliders etc that use mousemove and mouseup you will have better results on a smaller resolution screen or a capacative pitft that uses i2c for touch and spi for display.

[Maxx2206]

hi,

well... my main goal for projects using small displays is to use them to display just the required UI used for interaction... examples would be a oscilloscope-like circtui that reads analogue values and displays their waveforms... sort of a data monitor for a measuring system to check if its working within specifications (typical 1Vpp signal).
with these kind of projects in mind theres no need for much user input... so its mainly a display.

nevertheless, i had no idea this display is one of the slower (slowest?) ones.. thats a bit BANNED to hear now in fact :/
anyway.. should still be way fast enough for the starter projects... if i need anything faster or fancier later i can always get hold of other displays.

since im not planning to use it as a general display replacement thats also the reason i dont like the adafruit kernel idea...
i would like to keep things as generic as possible.. using the default raspbian image for all the development work and a slimmed down image for the final project just to make sure only the stuff thats actually needed is loaded reducing overall system load and boot time.

right now i have a whole bunch of different displays... the watterott 2.8" rpi display (320x240).. but i wanted a slightly bigger one so i went for the adafruit 3.5" 480x320.
meanwhile i also found links to sites utilizing older arduino displays like a sainsmart 3.2" or several watterott mi289qt whatever which i also happen to own from my arduino "era".

being able to quickly switch between these displays just by activating the corresponding fbtft driver would be a very useful feature to have.

however... kept trying to get any sign of life out of these 2 pi displays but im still struggling... the fbtft_device/FRAMEBUFFER commands create the /dev/fb1 device but trying to get even the simple menu.py example to work still fails.
at first i thought it was because the script is requiring SDL even tho there is no error indicating anything missing when i run it so i manually installed libsdl1.2-dev anyway.

lets see where this leads to... i was expecting a bit of work to get into using the pi and especially such displays but i didnt expect that there is so little basic explanations. providing prebuilt images can be quite handy. .but for actual developing reasons its also very limiting IMHO.

[Bel_Z_Bub]

I repeat, try a fresh raspbian install. then install the adafruit kernel and try one of the projects in the learning system that works for your display and go from there. I'm also really a noob if it comes to linux etc but the adafruit kernel hasnt limited me yet so far.

don't get me wrong, its not a bad screen, its the higher resolution that makes it slow really. but that also has some pros of course. and if you don't make much moving stuff in your gui it will run fine on a lower framerate and you wont notice the difference at all. and on a pi2 its much better. if you want a bigger 320x240, take a look at the new 3.2"pitft. I bet its a lot if not the same as the sainsmart you talk about

[Maxx2206]

Hi,

thanks for your patience and ideas...

and i agree, trying the supplied image is an option i will try... but the main problem still remains:
i was wondering what the minimum requirements are to use any kind of supported (AKA included in fbtft which is already part of the latest official raspbian image/rpi-update either natively (by name) or at least by its controller (like the hx8753d which is the controller of the 3.5" adfruit pitft afaics).

i was under the impression that with a fully up to date raspbian/rpi firmware loading the module with modprobe (or manually by editing etc/modules with the "fbtft_device name=xxx") followed by activating the "FRAMEBUFFER=/dev/fb1" already does it.
that way it would be easy to quickly switch between any of the displays i currently (or in the future) own.

in case of the 3.5" i think theres still the problem that its not natively supported apparently, which means i will still have to tell fbtft which GPIOs are used for backlight etc., right?

natively supported displays like my watterott rpi-display automatically show the used GPIO pins with "dmesg" once the module is loaded (but still i dont even get THAT working manually.
using their (watterott) supplied image works like a charm... which most likely will be the case with adafruits image, too i am sure... but that keeps me from being able to easily switch between displays or (which i my main goal) slim the raspbian image down to the bare minimum once the project is getting into the final stage so it only loads whats really needed - and for projects like a web radio, simple data monitor etc. you simply dont need a full specced 2-3gig big os including desktop GUI etc.

its the minimum operating requirements for displays in general (and the 3.5" adafruit pitft plus in particular) i am after at this point.

cyas

[Bel_Z_Bub]

right you dont need much for a simple radio for personal use but to make a finished product someone could use without knowledge of SSH, editing files on linux etc is a whole lot of work without a proper GUI api. I was however able to hand this radio to my gf, she took it home and could start using it without any help. but its way from finished if you look at it critically.

Everything is sorted. the adafruit kernel has a "virtual" backlight pin for the resistive displays, 508, to turn it on/off. And most newer piTFT's also have a pin 18 option, that you can use to control the backlight with pwm or to turn it on/off.

you can also easily switch display's by using the adafruit-ptft-helper tool. i bet that 3.2" arduino screen also runs on it if you connect it right. but haven't looked at it, might be close to the new 3.2 pitft. anyway, why not switch sd card/usbdrive with the needed kernel along with switching the screen.

I can't offer much help on fbtft I'm afraid. I wasnt aware that the fbtft was taken up in the raspbian kernel officially. I have only messed arround with it and a 1.4" sainsmart before piTFT was out. I had to compile a kernel with absolutly no knowledge and had to combine two tutorials as I had to compile it on the pi itself as I didnt have another linux machine for cross compiling and all tuts are based on that. I'm still surprised I woke up the next day and it worked the first try. So I'm quite happy with the adafruit screens and kernels.