Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Gui pisan u c
#1
Dali je neko zainteresovan za pisanje GUI-a u C jeziku na raspberry pi u kombinaciji sa libgd i dispmanx? Imam jedan davni i prvi projekat gde sam uspeo da napisem gui u ovoj kombinaciji sa dispmanx i libgd https://www.youtube.com/watch?v=7ZL5ZhLg3Zw ali nije optimizovan tj nisam radio u multitreadingu pa je iskoriscenost cpu-a skoro 100%, malo sam to pokusao srediti i sveo na nekih 50% ali je nemoguce prepraviti jer u startu nisam zapoceo kako treba i sve zakomplikovao. Novu implementaciju sam u startu zapoceo na multitreadingu, odradio sam touch screen evente, gpio evente i sve skupa sam sveo na apsolutnu nulu iskriscenosti procesora koristeci se polling funkcijama. Hocu da pisem novi gui zasnovan na dispmanx i libgd. Idea je da napravim neke osnovne gadgete tipa on-off dugme, rotaciono dugme, progress barove... da to moze kasnije lako da se prepise u neki potreban gui. Pitate se zasto ne koristim raylib... jednostavno ne svidja mi se raylib, isto tako embedded wizard, tesko ga je razumeti... itd, najvise bi voleo da napisem od starta te osnovne gadgete da ne budu komplikovani a da grafika bude u png, da bude lepa i da moze jednostavno da se menjaju skinovi jednostavnom zamenom png slika. Kompletan gui moze da se odradi prvo u php pa se to jednostavno prekopira i prevede u c. U atacmentu je stara i prljava implementacija koju sam odradio za jbc lemnu stanicu (video gore), ako nekoga zanima libgd + dispmanx


Attached Files
.c   jbc_old.c (Size: 94,46 KB / Downloads: 2)
Reply
#2
Nova implementacija koju radim za audio uredjaj, moze se videti da je svedeno na apsolutnu nulu iskoriscenosti cpu resursa. Ovde sad treba da odradim dobru gui implementaciju. Tu vam je i fm radio implementacija, IR kontrola, CT7302PL... itd i to sve radi na nula iskoriscenosti cpu-a, nema laga niti bilo cega. Danas sam malo poceo nesto ali me nesto mrzilo da idem do kraja, u check_button funkciji sam pokusao da vidim kako se ponasa touch screen event kada rotiram dodir na tach skrinu, video sam da funkcionise, to mi je bilo bitno, kasnije moze da se pise i neka grafika recimo neka png slika koja ce da se rotira kao neki volume knob na ekranu... itd, i to bi moglo da se odradi sa https://libgd.github.io/manuals/2.3.3/fi...terpolated , samo treba malo volje i vremena Smile


Attached Files
.c   saviola.c (Size: 33,79 KB / Downloads: 0)
Reply
#3
Znam da ne moze u realnom vremenu i na recimo 60 fps da se generise slika u libpgd, ali moze recimo da se prilikom boot-a aplikacije predefinise tj generise par slika za rotaciju recimo 12 slika iz nekoliko uglova i te slike smeste u memoriju za kasnije manipulaciju sa dispmanx... itd, tako moze da bude brzo na ekranu i bez laga, to mi je trenutna zamisao. Znaci napraviti par korisnih gadgeta u libgd, recimo neko rotiranje, tih 12 slika iz memorije mogu da se ucitavaju u dospmanx da na ekranu izgleda kao da se rotira nesto, ili recimo neko on-off dugme je jednostavno odraditi, progress bar... itd, ima vec i primera kako radi rotacija u dispmanx recimo ovo https://github.com/AndrewFromMelbourne/r...aster/game
Reply
#4
Ovo ce da posluzi, da okacim da nebi zagubio


Attached Files
.txt   rotate.java.txt (Size: 7,76 KB / Downloads: 2)
Reply
#5
Sa libGD sam radio samo statično generisanje slika dok sam programirao u PHP.

Trenutno se baziram za grafiku uglavno na QT5 framework, on je glomazan ali ima sve što treba i radi dobro.
OpenCV sam koristio u nekim drugim projektima za procesiranje slike sa kamere sa dodatkom VTK specificnog framework koji predvidjen kao dodatak za procesiranje slika u medicini.
Tu je i RayLib, "gejmerska" biblioteka, solidna, brza sa veoma malim footprint.

Sva tri spomenuta frejmowork imaju resen mulithread i renderovanje koje je sinhronizovano sa osvezavanjem "scene", prakticno na tebi je samo da postavis vizuelne objekte a kada se oni renderuju i osvezavaju to brine interno sam framework.

Takodje sva tri podrzavaju OpenGL ES koji se koristi na RPi i to radi veoma dobro.
Reply
#6
Najlepse od svega, sve spomenute grafičke biblioteke mogu bez problema da se indegrišu u Forth, skoro sam pisao o QT5 + Forth ovde:
https://forum.yu3ma.net/thread-674-post-...#pid121853

Jezgro aplikacije je u C/C++, samo se doda Forth konzola u posebnom procesu (thread, ima C source) i preko nekoliko osnovnih funkcija/reči poveže objekte i kontrole (buttons, listbox itd) da rade akcije tipa "click", "show", "hide", "select" i nadalje onda kombinuješ Forth i C/C++ kontekst gde Forth radi osnovne logičke operacija a ispod haube su povezane kontrole na nižem nivou, sve interaktivno u letu radi i to veoma veoma brzo preko steka za minijaturnim zauzećem memorije, tipa 64KB da me podseća na Comodore 64 i od toga potroši 2 KB Smile
Reply
#7
Ne mogu da savladam ni sta mi treba da pocnem u qt5, odakle da krenem? Dali je dovoljan Qt Design Studio za gui ? Dali je gui-u potreban x file system? Dali moze bez X da radi? Dali postoji C podrska i kakva mu je podrska u C? Itd pitanja. C++ ne volim nesto niti imam volje da ga ucim. Znas sta mi je jos bitno, da mogu da napravim static binary i da ne zavisim od X file sistema, znaci da aplikacija moze da radi nezavisno od operativnog sistema. Open embeded mi je vrh ali tesko mi je da se snadjem u njemu, probao sam neku dugmad, znam to da lako odradim, cim zahteva nesto ozbiljnije ne mogu da se snadjem u onim njihovim tipovima "pure" itd neke budalastine, a ne znam ni kako bi povezao nativni source code radjen u C, ima tako nekih primera kako i to odraditi, videcu jos sta cu i sta mi je jednostavnije, da je zanimljiv zanilmljiv je open embeded
Reply
#8
QT5 je C++ 11, isključivo koristi objektno programiranje sa templejt i interfejs klasama spojen sa specifičnim makroima koji uvode pojmove poput SIGNAL-a i SLOT-ova koji se koriste kao mehanizam za medju-objektnu komunikaciju.
U suštini je kompleksan i zahteva C++ znanje.

Ni meni u početku QT nije bio privlačan ali samo zato što u tom trenutku nisam znao dobro C++, specifično C++11 i onda sam se našao u situaciji da ja hteo ne hteo nekako sam morao da uzmem i to jednom da "račivijam" i krenem da radim sa tim, stim što mi je ogromnu ali zaista ogromnu pomoč odradio CLion IDE i pomogao u pisanju ispravnog i čistog C++ code-a po CLang specifikaciji sa posebnim osvrtom na CMake build sistem i sada napredniji Nija koji je kompatibilan sa CMake.

Kada sam generalno prešao na CLion IDE, počeo sam da pravim aplikacije "za sve platforme" i "bilo kakve namene", mogu da kombinujem bilo kakve biblioteke i framework-ove, to ide dotle da se "zezam" i spajam QT5 sa Forth a NE RADIM u QT-Designer-u nego u CLion + Cmake samo sa uvezanim QT bibliotekama.
Predhodno sam spojio RayLib sa Forth, opet sa pomešanim kontekstima da se iz konzole interaktivno rade neke operacije.

Uglavnom ta kombinacija dobrog IDE-a sa C++ čuda pravi, treba samo malo volje da se ovlada malo tom ipak naprednijom tehnikom programiranja ali zauzvrat dobijes poptunu slobodu da iskoristiš te pontencijale na bilo koji način i za bilo kakvu svrhu i da imaš mogućnost to da vrlo brzo probaš i pokreneš.

QT5 je uglavnom za desktop varijantu (open-source sa nekim izuzecima), za embedded imaju posebnu verziju koja mislim da je komercialna.

RayLib je pisan u C i može da se statično bilduje i linkuje u binarni izvršni fajl, pogledaj pre njega nego QT.
Reply
#9
Ok hvala, tako sam i mislio u vezi qt5, odmah mi je delovao da nije za embeded systems. Raylib mi se ne svidja, mislim da cu sam sebi svoju verziju gui da napravim gde cu posle lako da se snalazim kad zatreba neko dugme, neki progres bar, neji rotacioni gumb, gumb mi je zasad najkomlikovaniji ali mislim da cu da ga savladam cim malo zagrejem stolicu. Pogledacu jos jednom raylib konkretno guilib od raylib-a, da vidim dali je moguce promeniti onu ruznu grafiku od gadgeta
Reply
#10
Ima Qt for MCU i koliko se sećem besplatan je.
https://www.qt.io/product/develop-softwa...ollers-mcu

Evo par demo aplikacija za STM32:
https://www.qt.io/microcontrollers-st?hsLang=en
Reply
#11
Trial je, a i u okviru LGPL? Ne svidja mi se. Ovako cu kako sam zamislio, imam i overlay preko lightdm i ne moram da ga gasim sto ce mi biti potrebno kada mi je ulaz raspberry pi pa mogu volume level i druge stvari da overlaisem na sekund dve dok se radi neka komanda... QT for mcu bi mogao u nekom periodu kada se predje na neki stm32 ili slicno umesto rpi, za sada rpi je zakon Smile
Reply
#12
Ma da, RPi i Linux su zakon, mislim generalno na embedded linux mašine (NVIDIA i slične), sada postoje veoma moćne platforme sa GPU i AI akceleratorima i na to dodat ali VEOMA BITAN momenat i koncept što stavljaju dodatno Cortex-M jezgro nezavisno od Cortex-A jezgra na kome se vrti linux, ovaj M je idealan i praktično jedino rešenje da se neke stvari rade na HW nivou precizno i tačno dok je Cortex-A zauzet sa linuxom i grafiku radi nezavisno GPU "babaroga" koje te sličice može da vrti na nivou 1+ milion vertexa sa 60FPS u 2K možda i 4K rezoluciji preko vektor i fragment shadejra koje izmedju ostalog možeš da koristiš i za Audio DSP procesiranje Smile

Realnost je ta da Cortex-M generalno nije predvidjen za grafiku već za vremenski-kritične zadatke procesiranja signala i takodje je realnost ta da Cortex-A (RPi i slični) nije previdjen za vremenski kritične zadatke i nikako ne može da radi stvari koje moze Cortex-M da radi "opušteno" ali zato barata drugim stvarima i posebno grafikom veoma efikasno.
Reply
#13
Sa novim gpio https://elinux.org/images/9/9b/GPIO_for_...Makers.pdf sada mogu precizno rise i fall time da se rade, daleko brze mogu neke stvari da se odrade a pritom da se odrade preko poll funkcija Smile
Reply
#14
Nemoj mnogo da računaš na te GPIO sa kontrolom iz Linuxa, rade sve ok ali kada kreneš da te GPIO recimo sinhronizuješ sa pisanjem na SPI počinje da se pokazuje "tamna strana" tog pristupa, toliko je problematično da na kraju obično ljudi predju na Cortex-M što externi ili interni jer ne može lepo i precizno da se stvari sinhronizuju, vremenska odstupanja tj "jitter" je 1000x veći i to je baš problematično.
Reply
#15
Znam, za ovo sto mi treba oko ui bice dovoljno. Zna li neko kako da resim ovo. Imam lightdm x okruzenje, preko dispmax napravim layer preko x okruzenja i tu imam dugmad na koje klikcem, ali imam problem sto touch screen eventi gde god da kliknem reaguju i na x okruzenje, recimo na overlay kliknem na neko dugme koje je sa xy kordinatom na neki shortcut na x okruzenju, tako mi se na x okruzenju otvori recimo brovser jer sam kliknuo na njega. Ja to resavan tako sto zaustavim lightdm servis, ali to mi nije resenje jer mu treba par sekundi da se opet pokrene onda imam lag sa ovom mojog grafikom kada prelazim sa overlaja na x okruzenje. Dali postoji mogucnost da u letu zaustavim touch screen evente da imaju uticaj na x okruzenje samo kada je overlay aktivan bez da stopiram lightdm? Znaci kada overlay nije aktivan touch eventi reaguju na x okruzenju, a kada je overlay aktivan zaustavljam evente na x okruzenju i imam evente onda na overlay, kako ovo da izvedem? Inace dispmanx je mocna stvar, ima sve potrebno za izradu gadgeta, od movinga, do sprite, do rotacije... odlican.
Reply
#16
Tačno znam šta ti se desava ...
Na RPi sam radio sa RayLib bez X servera, šta će mi to, ne treba mi, može i bez toga i nema nikakvih problema ... Smile
Povezao sam i neki custom DSI IPS ekran, pisao kernel drajvere i proradilo sve kako treba.

Stim što tu imam druge probleme, nije sa X nego sa DSI interfejsom gde hoću da priključim dva ekrana na jedan port, u teori je moguće a da li je izvodljivo na RPi je pitanje na koje još nemam odgovor Smile

Reply
#17
ja to dobijam preko rc.local pokrenem moj program koji odradi "service lightdm stop" , aplikacija radi bez X preko dispmantx koji koristi nativnu grafiku. Ali ne mogu da se resim ovih klikova kada mi u isto vreme radi i x window system, on mi treba jer rpi mi je jedan od ulaza, kada ulaz nije rpi nego nesto drugo program opet odradi lightdm stop, i kada je iulaz opet rpi odradi lightdm start da pokrene x windows sistem, i to me nervira sto mu treba par sekundi da startuje X. Kada bi mogao nekako da zaustavim lightdm neki breakpoint ili ne znam ni ja kako bi to moglo da se odradi da ne moram da ga stopiram
Reply
#18
Da se ne zagubi, ima veze sa temom tj sa ekranima i DSI/DPI protokolom za ekran koji je polu-otvorene specifikacije, kolega i poznanik Mike je pokušao da to iztraži, brdo korisnih informacija ...

Reply
#19
Zanimljivo je da kada pokrenem ovu komandu sa --grab da x window sistem vise ne reaguje na touch Smile

Code:
evtest --grab /dev/input/event1

Edit:
Da to je to, mogu da zaustavlm touch na X na 10s, sad je samo pitanje dali sam zaustavio i na overlay, pretpostavljam da je sada touch ogranicen samo na aplikaciju Smile

Code:
ioctl(touch_fd, EVIOCGRAB, 1);
usleep(10000000);
ioctl(touch_fd, EVIOCGRAB, 0);
Reply
#20
Upeo sam ceo userland libs da kompilujem staticki pa i cela aplikacija je sada staticki upakovana. Pocecu da pravim i prve gadgete uskoro, za pocetak napravicu on-off slajd dugme, trudicu se da mu ubacim i neki efekat
Reply


Forum Jump:


Users browsing this thread: 8 Guest(s)