Obsługa ekranu LCD na Raspberry Pi

pod pythonem uzywam Adafruit_ILI9341

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

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

Tworzono. Najbardziej rozbudowaną był DirectFB. Cairo bodajże do dziś wspiera ten backend. Był port GTK2.

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

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

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.

Dnia 15.11.2016 Marek snipped-for-privacy@fakeemail.com napisał/a:

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...

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

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...

Dnia 15.11.2016 Atlantis snipped-for-privacy@wp.pl napisał/a:

Banalny przykład jak bezpośrednio rysować na framebuferze.

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.

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ę.

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.

W dniu 2016-11-15 o 21:33, Sebastian Biały pisze:

Pytałem o zużycie zasobów, bo RaspberryPi posiada GPU. Jak rozumiem układ ten nie jest wykorzystywany podczas prostych operacji na framebufferze wyświetlacza podłączonego przez SPI. A jak wygląda sytuacja podczas korzystania z serwera X? System będzie się wspomagał procesorem graficznym, odciążając CPU?

Co mógłbym poczytać, żeby trochę zorientować się w sytuacji? Nigdy nie pisałem niczego pod X-y pod Linuksem. Od czego zacząć? Co zainstalować przez apt-get, żeby nie ściągnął mi się cały system okienkowy? Jak przeprowadzić konfigurację i co najważniejsze - jak napisać i odpalić program rysujący coś na ekranie? Są dostępne jakieś tutoriale?

BTW gdzieś natknąłem się na informację, że OpenGL ES można skonfigurować do pracy bezpośrednio na framebufferze. Czy to też jest sensownym, alternatywnym podejściem?

zainstalować

Oczywiście, że są. Pytanie czy chcesz oprócz rysowania prymitywów (pixel, linia, itp) robić jakiś interfejs aplikacyjny (menu itp). Jeśli to drugie to polecam np. gtk. Jest też w wersji skryptowej. Jeśli tylko to pierwsze to wystarczy użyć czystego xlib (apt-get libx11-dev). Możesz wtedy bezpośrednio rysować prymitywy na X serwerze. Kiedyś popełniłem symulator sterownika lcd pod X11 takiego jak ten Twój IL-cośtam. Zamiast testować interfejs graficzny na pic32+lcd kompilowałem sobie cały kod pod x11 podstawiając w kodzie ten driver do x11 zamiast oryginalnej biblioteki lcd (lcd było w okienku, jak każda aplikacja). Odezwij się na priv, to Ci podrzucę ten driver.

Użytkownik "Marek"

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.

Nie, choć GPU może pracować bez wyświetlacza. Nie wiem jakie ma mozliwości, ale skoro akceleruje dekodowanie mpeg2/4 to powinien dać radę móc coś policzyć ogólnie. Pytaj googla, ja się w małych GPU nie orientuję.

Od nie pisania pod Xy. Weź Qt jesli znasz C/C++. Weź wxWidgets jeśli znasz tylko C. Ostatecznie w pythone sobie zrobisz gui, a jak będziesz chciał szybko i tanio to w swingu w javie.

Zdecyduj w czym bedzie Ci wygodniej. Nie, reczne rysowanie kresek nie jest wygodne. Naprawdę. Ono tylko się wydaje wygodne na początku. Potem to droga przez mękę.

Miliardy. Z powodu szybkości developowania na PC i odpalania na Pi sugerował bym Javę. Wtedy będa pasować książki o pisaniu GUI w Swingu, czyli prawie każda '90<>2010.

Ale co on ma niby dawać? Chcesz jakieś efekty 3D uzyskać?

Dlaczego? Atlantis chce coś lekkiego, wyczuwam, że chce wykorzysta8 jakąś grafikę napisaną pod arduino, a tam tylko rysuję się na prymitywach. Podstawi wraper x11 i już ma lekkiego klienta.

Od kiedy w Qt można pisać w C? Nie ma czegoś takiego jak programowanie.C/C++. Albo C albo C++. "Specjalistom" od C++ piszącym de facto w C dziękujemy.

Rotfl, ~ 500 MB jvm w RAMie by narysować parę kresek na pewno go ucieszy :-)).

W dniu 2016-11-17 o 00:32, Marek pisze:

Dokładnie. Na chwilę obecną chodzi mi o prosty program, który będzie pokazywał na wyświetlaczu aktualny status MPD (aktualny utwór, status odtwarzania, głośność, jakiś pasek postępu itp.). Głównie tekst, ewentualnie jakaś prosta ikonka. W przyszłości ewentualnie dodam do tego jakieś menu. Jednak biorąc pod uwagę fakt, że nie mam tam ekranu dotykowego, a do sterowania posłużą dwa przyciski i enkoder obrotowy (ewentualnie pilot), nie potrzebuję złożonego interfejsu graficznego.

Na chwilę obecną byłbym wdzięczny za kilka podstawowych informacji. Pytania pewnie wydadzą się banalne, ale w morzu informacji poświęconych programowaniu interfejsów graficznych pod Linuksem nie mogę się doszukać jednoznacznej odpowiedzi...