Jak stworzyć prosty interfejs graficzny na wyświetlaczu LCD 320x240 ILI9341 z Raspberry Pi?

Tue Nov 15, 2016 9:17 am   

Nie miałem do tej pory żadnych doświadczeń z obsługą wyświetlaczy
graficznych na Raspberry Pi, dlatego chciałbym zapytać od której strony
to ugryźć.

Wyświetlacz to prosty LCD 320x240 na ILI9341. Jest już podłączony do
RasPi przez SPI, system widzi go jako /dev/fb1. Testowo udało mi się na
nim wyświetlić konsolę. Moim celem jest jednak generowanie na nim
prostego interfejsu graficznego: trochę tekstu, jakieś paski postępu,
może jakieś proste grafiki z plików. Nie chcę na tym odpalać pełnego
interfejsu okienkowego.

Główne pytanie brzmi tak: czy wśród standardowych bibliotek dostępnych
na Linuxa (Raspbian Jessie) znajduje się coś, co pozwalałoby w prosty
sposób rysować na wyświetlaczu, wykorzystując pisząc bezpośrednio do
framebuffera, z pominięciem całego systemu okienkowego?

Tue Nov 15, 2016 9:22 am   

On 15/11/2016 08:17, Atlantis wrote:


pod pythonem uzywam Adafruit_ILI9341

https://github.com/adafruit/Adafruit_Python_ILI9341

Tue Nov 15, 2016 9:47 am   

W dniu 2016-11-15 o 09:22, cezar pisze:


1) Jeśli nie muszę, nie używam Pythona. Preferuję standardowe C,
ewentualnie C++.
2) Z tego co widzę, to ta biblioteka dostarcza swój własny sterownik i
nie korzysta z framebuffera. Skoro już udało mi się skomunikować
wyświetlacz z jądrem Linuksa, to wolałbym iść tą drogą. Szukam
biblioteki, która dostarczy mi przynajmniej najbardziej podstawowe
funkcje graficzne, ale sama będzie pisała do framebuffera.

Tue Nov 15, 2016 3:28 pm   

On Tue, 15 Nov 2016 09:47:19 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

Ciekawe czy coś znajdziesz, po co ktoś miałby coś takiego tworzyć
skoro jest x11?

--
Marek

Tue Nov 15, 2016 5:12 pm   

Dnia 15.11.2016 Marek <fake@fakeemail.com> napisał/a:

Tworzono. Najbardziej rozbudowaną był DirectFB. Cairo bodajże do dziś
wspiera ten backend. Był port GTK2.
https://www.cairographics.org/backends/

Działał pod tym Gimp, Firefox (gdzieś tak do 3.6), webkit. Sam używałem
klienta VNC, mplayera, prostych przeglądarek graficznych, pdf (mupdf
fbdev), przeglądarki internetowej netsurf, links.
Dziś Linux Frame-Buffer jest w kompletnym zamrożeniu. Nie dodaje się już
nowych driverów. Zachęca się do przejścia na DRM/KMS, który oferuje
pewną formę emulacji fbdev.

Firmy które to wykorzystywały w swoich projektach często tworzyły swoje
własne rozwiązania.

Tue Nov 15, 2016 6:12 pm   

On Tue, 15 Nov 2016 15:12:36 -0000 (UTC), grapeli23
<grapeli23@googlemail.com> wrote:

Ale to na pewno system.okienkowy z menadzerem? Bo to, że można
interfejs jednej aplikacji wyświetlić na fbdev to jasne, sdl też.
chyba umiał korzystać z fb. Atlatisowi chyba chodziło o środowisko a
nie pojedynczy interfejs

--
Marek

Tue Nov 15, 2016 6:20 pm   

On 2016-11-15 09:17, Atlantis wrote:

Jesli widzisz to jako framebuffer to możesz zainstalować sam serwer X-ów
do FB, bez managera okien. Wtedy napiszesz aplikację w czymkolwiek (ja
np. w Javie mam dobre doświadczenia ale równie dobrze może być Qt,
Python, whatever) i będzie ona dzialać fullscreen. Uzyskasz tanim
kosztem efekt całkiem przyzwoity.

Tue Nov 15, 2016 7:28 pm   

Dnia 15.11.2016 Marek <fake@fakeemail.com> napisał/a:

https://en.wikipedia.org/wiki/DirectFB

Tue Nov 15, 2016 9:13 pm   

W dniu 2016-11-15 o 18:20, Sebastian Biały pisze:


A jak będzie wyglądała kwestia zużycia zasobów? Bo zastanawiam się, czy
to przypadkiem nie będzie strzelanie z armaty do komara. Tak naprawdę
potrzebuje czegoś bardzo prostego, przypominającego rozwiązania z
Arduino. To ma być typowe urządzenie embedded, a wyświetlacz ma
zapewniać dostęp do paru podstawowych informacji i ustawień.

Na dobrą sprawę mógłbym sobie napisać funkcję put_pixel() operującą na
/dev/fb1 i potem podpiąć do niej jakieś biblioteki z Arduino. Sądziłem
po prostu, że może coś takiego już istnieje, biorąc popularność Linuksa
w zastosowaniach wbudowanych...

Tue Nov 15, 2016 9:33 pm   

On 2016-11-15 21:13, Atlantis wrote:

Server X na framebuffer to tylko proxy do pamięci z /dev/


Problem w tym że jesli zrobisz to ręcznie czeka Cie rzeźba
*niemiłosierna* z napisaniem każdej kontrolki, systemu eventów itp.
Server X do FB jest lightweight. Używałem go na tym cudzie:

http://www.goodluckbuy.com/images/detailed_images/sku_89640_1.jpg

To jest komputer nieporównywalnie słabszy od Pi. Nie dośc że uciągnął Xy
to jeszcze Javę a w środku javy JavaScript (Rhino) w którym była
wlaściwa algorytmika sterowania maszyną. GUI na Swing wyszło za darmo bo
*był* serwer X i wyglądało profesjonalnie, cokolwiek to znaczy.
Zadziałało od razu, bez marudzenia.

Skoro to maleństwo uciągneło java+X to naprawde, bez obaw o zasoby Pi.
Managera okien bym nie stawial jesli ma być embedded, ale Xy jak
najbardziej. Jak mówie, Xy to tylko takie proxy do /dev/fb. Może dośc
pokręcone, ale co to kogo obchodzi.


Zajedziesz się. Nie warto. Postawienie X fb to kilka chwil i nagle
dostajesz dostep do masy softu działającego *wprost*, wliczając to nawet
takie cuda jak wxWidgets, QTopia, Qt gdzie można zrobić gui z grubej rury.


Xy istnieją To jest Pi więc używanie ręcznie wydziarganych algorytmów
rysowania kresek wydaje się być naciągane...

Tue Nov 15, 2016 10:41 pm   

Dnia 15.11.2016 Atlantis <marekw1986NOSPAM@wp.pl> napisał/a:

No i właśnie do takich prostych rzeczy był wykorzystywany Linux Frame
Buffer.
http://raspberrycompote.blogspot.com/2013/01/low-level-graphics-on-raspberry-pi-part.html

Jak chcesz możesz użyć wspomnianego SDL, który na nim również może
działać.
https://github.com/aduros/SDL/blob/master/README.DirectFB

Może nawet i SKIA.
https://groups.google.com/d/topic/skia-discuss/K46AR6CeuAc

Tue Nov 15, 2016 11:19 pm   

Dnia 15.11.2016 Atlantis <marekw1986NOSPAM@wp.pl> napisał/a:

Banalny przykład jak bezpośrednio rysować na framebuferze.
https://gist.github.com/FredEckert/3425429

Wed Nov 16, 2016 12:04 am   

On Tue, 15 Nov 2016 21:33:50 +0100, Sebastian
Biały<heby@poczta.onet.pl> wrote:

Eh przypomniałeś mi, że mam w szufladzie psiona 5mx pro (wersja 32MB
ram!).X był o ile pamietam też na fb. Miałem na tym debiana z
apache+mysql+php i fvwm95 (a jak). Pięknie to chodziło. Także obawa,
że raspi jest za słabe na X to gruba przesada. Ten Psion to 30Mhz
arm z 32 MB ram i z fvwm wraz aplikacjami np. z GTK śmigały.

--
Marek

Wed Nov 16, 2016 2:38 am   

W dniu wtorek, 15 listopada 2016 09:17:20 UTC+1 użytkownik Atlantis napisał:

================
Jasne, że jest banalne rozwiązanie. Lazarus. Komponenty wrzucasz na formę na zasadzie "drag and drop". Programujesz w Pascalu. Składnia podobna, tyle że bardziej czytelna. Np. w C masz coś takiego jak a||b, w Pascalu (a or b), w C a&&b, w Pascalu (a and b). Co jest bardziej czytelne? W zasadzie cała filozofia języka C i jego klonów, to tylko marketingowe pieprzenie zapoczątkowane w latach 80'tych, że jest to język wysokiego poziomu o wydajności assemblera.. Sranie w banie !! To zależy nie od sposobu zapisu (a:=a+1 vs. a++) lecz od jakości kompilatora. Pascal jest językiem mocno typowanym. I bardzo dobrze!! I zmienna musi być zadeklarowana/zdefiniowana w odpowiednim miejscu. I bardzo dobrze!! Dzięki temu nie ma burdelu i nie da się byle gdzie zdefiniować byle czego i przypisać byle czego do jeszcze bardziej byle czego (np.int a=char b). W Pascalu da się to jasne też zrobić, ale tak, żeby potem nie szukać "gdzie coś spie...liłem". Jak znasz C, to Pascala zrozumiesz w 5 minut. Gorzej w drugą stronę.

Wed Nov 16, 2016 9:17 am   

On Tue, 15 Nov 2016 16:38:38 -0800 (PST), stchebel@gmail.com wrote:

Jak się zna C absolutnie nie ma żadnego powodu by używać Pascala do
czegokolwiek.
Pascal jest wyłącznie językiem dydaktycznym (podobnie jak logo),
powstał tylko w tym celu a wykorzystywanie go w argumentach
"wyższości stusowania" poza polami dydaktycznymi to nieporozumienie.

--
Marek