Witam

Ma ktoś jakieś doświadczenie w pisaniu *prostego* GUI dla
mikrokontrolerów z wyświetlaczem dotykowym monochromatycznym?
Potrzebuję zrobić coś takiego (rysowanie przycisków, okienek, bitmap
itp) na podstawie istniejących funkcji (linia, bitmapa, tekst) no i
nie wiem, w jakiej strukturze najlepiej to zorganizować, żeby łatwo
było to wyświetlać, tworzyć jak i obsługiwać ("kliknięcie")? System
pracuje pod FreeRTOS'em, piszę w C. Trzeba zapewne stworzyć listę
obiektów, np. w kolejności rysowania... Ale jak to zrobić, żeby się
później nie narobić?? Problemy które widzę, to:
-elementy są różnego typu, każdy posiada inne cechy szczególne...
-trzeba jakość obsłużyć "klikanie" na element, a różne elementy są
obsługiwane przez różne wątki...
-nie wiem, czy przydatna nie byłaby pewna hierarchiczność zaszyta w
tej strukturze (możliwość usunięcia, przesunięcia, ukrycia całej grupy
elementów).

Ja to widzę tak - tworzę listę elementów, każdy element opisuje:
- położenie i rozmiar (X,Y,W,H)
- typ obiektu (bitmapa, tekst, przycisk...)
- wskaźnik na kolejkę (queue), do której należy wysłać informację np.
o kliknięciu na dany element
- wskaźnik do dodatkowych ifnformacji o danym elemencie...
- wskaźnik na następny element
Tylko, że nie wiem, czy to najlepsze wyjście... może lepiej to trochę
pozmieniać? Może mniej danych wystarczy, może przyda się więcej?? Wolę
sobie wcześniej zaprojektować taką strukturę, niż potem wszystko robić
trzykrotnie... Bo się okażę, że czegoś nie przewidziałem, że apetyt
rośnie w czasie jedzenia itp itd...

Będę wdzięczny za wszelkie uwagi do mojego pomysłu :).

Pozdrawiam
Konop

do góry

"Ja to widzę tak - tworzę listę elementów, każdy element opisuje:
- położenie i rozmiar (X,Y,W,H)
- typ obiektu (bitmapa, tekst, przycisk...)
- wskaźnik na kolejkę (queue), do której należy wysłać informację np.
o kliknięciu na dany element
- wskaźnik do dodatkowych ifnformacji o danym elemencie...
- wskaźnik na następny element
Tylko, że nie wiem, czy to najlepsze wyjście... może lepiej to trochę"

Ja nie rozumiem, po co stosować takie objekty?
Przypomina to Windows, który od 20 lat "ładuje się",
każdego dnia po kolei, często widać jak pojawiają się w rządku te same
ikony.
Raz na 2 miesiące jakąś dodam, a może raz na tydzień jakaś mi się przesunie
przez pomyłkę.
Pamiętam kiedyś przeniosłem z pół pulpitu do katalogu "stare" :-)

Dlaczego komputer po każdym włączeniu nie może wyswietlić bitmapy z
ostatniego dnia
lub obrazu startowego w postaci panelu użytkowego, a nie reklamy,
ale musi po kolei coś uruchamiać?
Potem dorobić obsługę naciśnięcia [X;Y] i porównać ją z zakresem dostępnych
w danej chwili działań.

Ja tak bym napisał.


--
pozdrawiam
Sylwester Łazar
http://www.alpro.pl
http://www.rimu.pl -oprogramowanie do edycji schematów
i projektowania PCB

do góry

W dniu 2010-12-29 13:32, Konop pisze:

>
> Będę wdzięczny za wszelkie uwagi do mojego pomysłu :).
>
> Pozdrawiam
> Konop

Ja zrealizowałem to w taki sposób:
Całość podzieliłem na wirtualne ekrany. W strukturze między innymi mam
zapisane takie parametry jak położenie, wielkość, parametr czy ekran
jest widoczny, wskaźnik kolejki komunikatów/zdarzeń oraz kolejną tablicę
struktur która opisuje konkretne kontrolki na tym ekranie. W strukturze
kontrolek mam to piszesz plus wskaźniki konkretnych funkcji
odpowiedzialnych za rysowanie, rysowanie po kliknięciu itd. Dzięki temu
struktura jest uniwersalna i zawsze taka sama dla różnych typów
kontrolek. Każdy ekran to osobny wątek i osobna kolejka komunikatów. Do
tego stworzyłem szereg funkcji typu: CreateScreen, ShowScreen,
HideScreen, CreateButton, CreateBitmap itd... Nie wiem czy to najlepsze
rozwiązanie w każdym razie działa i nie jest upierdliwe jak trzeba dodać
coś nowego.

pozdrawiam

do góry

http://www.linuxfordevices.com/c/a/Linux-For-Devices
-Articles/Embedded-
Linux-Graphics-Quick-Reference-Guide/

cos znajdziesz, jest od wxWidgets po podełko zapałek czy GPE

do góry

Konop wrote:

> Witam
>
> Ma ktoś jakieś doświadczenie w pisaniu *prostego* GUI dla
> mikrokontrolerów z wyświetlaczem dotykowym monochromatycznym?
Watpie, zasadniczo to widze dwie drogi :
1. Jak w poscie ponizej - statyczny obrazek w postaci mapy bitowej oraz
napisane z palca psedo-widgety typu np. 3 cyfry w stalym miejscu ( nie ma
mowy o zadnych oknach a tym bardziej historiach typu mysz, przesuwanie
okien czy zdarzenia).
2. Uzycie istniejacego mikro-GUI - patrz ponizej.

> Potrzebuję zrobić coś takiego (rysowanie przycisków, okienek, bitmap
> itp) na podstawie istniejących funkcji (linia, bitmapa, tekst) no i
> nie wiem, w jakiej strukturze najlepiej to zorganizować, żeby łatwo
> było to wyświetlać, tworzyć jak i obsługiwać ("kliknięcie")? System
> pracuje pod FreeRTOS'em, piszę w C. Trzeba zapewne stworzyć listę
> obiektów, np. w kolejności rysowania... Ale jak to zrobić, żeby się
> później nie narobić?? Problemy które widzę, to:
> -elementy są różnego typu, każdy posiada inne cechy szczególne...
> -trzeba jakość obsłużyć "klikanie" na element, a różne elementy są
> obsługiwane przez różne wątki...
> -nie wiem, czy przydatna nie byłaby pewna hierarchiczność zaszyta w
> tej strukturze (możliwość usunięcia, przesunięcia, ukrycia całej grupy
> elementów).
>
> Ja to widzę tak - tworzę listę elementów, każdy element opisuje:
> - położenie i rozmiar (X,Y,W,H)
> - typ obiektu (bitmapa, tekst, przycisk...)
> - wskaźnik na kolejkę (queue), do której należy wysłać informację np.
> o kliknięciu na dany element
> - wskaźnik do dodatkowych ifnformacji o danym elemencie...
> - wskaźnik na następny element
> Tylko, że nie wiem, czy to najlepsze wyjście... może lepiej to trochę
> pozmieniać? Może mniej danych wystarczy, może przyda się więcej?? Wolę
> sobie wcześniej zaprojektować taką strukturę, niż potem wszystko robić
> trzykrotnie... Bo się okażę, że czegoś nie przewidziałem, że apetyt
> rośnie w czasie jedzenia itp itd...
>
> Będę wdzięczny za wszelkie uwagi do mojego pomysłu :).
Po lekturze powyzszych wymagan moge stwierdzic iz to "proste" GUI w
implemntacji bedzie calkiem rozbudowanym projektem.
Zasadniczo w takej systuacji polecam wykorzystanie istniejacego tworu lub
chociaz spojrzenie pt. "Jak to robia inni" aby uniknac wywazania otwartych
drzwi.
Jakis czas temu poszukiwalem jakiegos embedded GUI i z projektow open source
jak na razie znalazlem tylko Nano-X -> http://www.microwindows.org/ ale
obawiam sie iz port dla FreeRTOS'a bedzie wyzwaniem - jest on oparty o
architekture klient-serwer co powoduje iz komunikacja odbywa sie przez
sockety BSD na localhostcie :)
Z komercyjnych ciekawie wyglada C/PEG ->
http://swellsoftware.com/products/cpeg.php aczkolwiek tez ne ma portu dla
FreeRTOS'a.
Polecam tez spojrzec na GUI systemiku Contiki -> http://www.sics.se/contiki/
oraz biblioteke graficzna PW dla wyswietlaczy monochromatycznych ->
http://sourceforge.net/projects/pwlib/ (jest on blizsza "podejsciu
mikrokontrolerowemu" niz Nano-X).

do góry

W dniu 2010-12-29 13:32, Konop pisze:
> Będę wdzięczny za wszelkie uwagi do mojego pomysłu :).

Rzuć okiem na bibliotekę microchipa
http://www.microchip.com/stellent/idcplg?IdcService=
SS_GET_PAGE&nodeId=2680&dDocName=en543091

do góry

> Dlaczego komputer po każdym włączeniu nie może wyswietlić bitmapy z
> ostatniego dnia
> lub obrazu startowego w postaci panelu użytkowego, a nie reklamy,
> ale musi po kolei coś uruchamiać?
> Potem dorobić obsługę naciśnięcia [X;Y] i porównać ją z zakresem dostępnych
> w danej chwili działań.
>
> Ja tak bym napisał.

Fakt, można... chodzi tylko o wygodę :). Pomyśle nad tym, bo to kurcze,
proste jest, mało pamięci potrzebuje i w ogóle ;)... Fajne :)...
Muszę tylko samemu dokładnie określić na czym mi zależy... W Twoim
wydaniu przesunięcie przycisku np. przycisku to kupa roboty - trzeba
przerobić bitmapę na kompie, trzeba ją przekonwertować i dołączyć do
programu, w programie zmienić obszar, na którym ten przycisk obowiązuje.
W przypadku takiej struktury po prostu zmieniam wartości X i Y i
przycisk się sam przesuwa :)...
Problem pojawia się po prostu w momencie, w którym chce mieć różne
elementy... na starcie chcę widzieć pulpit z paroma ikonkami i tyle...
potem przechodzić dalej. Czasem mieć klawiaturę numeryczną itp.. czyli
kilka bitmap, które trzeba podmieniać i się w tym nie pogubić :). I tak
muszę stworzyć sobie taką "listę obszarów", gdyż w jednym momencie
danemu (X,Y) przyporządkowany będzie przycisk A, a w innym momencie,
będzie to przycisk B... itd...
Tak więc nie wiem, jak to w sumie wyjdzie :)...
Ale pomysł na pewno wart jest przemyślenia. Uwzględniając istniejące
opóźnienie w projekcie, nie wiem, czy się jednak nie skuszę :)...

--
Pozdrawiam
Konop

do góry

W dniu 2010.12.29 15:22, brak pisze:
> Konop wrote:
>
>> Witam
>>
>> Ma ktoś jakieś doświadczenie w pisaniu *prostego* GUI dla
>> mikrokontrolerów z wyświetlaczem dotykowym monochromatycznym?
> Watpie, zasadniczo to widze dwie drogi :
> 1. Jak w poscie ponizej - statyczny obrazek w postaci mapy bitowej oraz
> napisane z palca psedo-widgety typu np. 3 cyfry w stalym miejscu ( nie ma
> mowy o zadnych oknach a tym bardziej historiach typu mysz, przesuwanie
> okien czy zdarzenia).

Pisząc o "oknach" miałem na myśli coś na czymś - to się nie musi
przesuwać ani nic, ale NA PEWNO będę potrzebował kilka różnych
"ekranów"... więc w sumie mała różnica , czy nowy ekran zajmie cały
wyświetlacz, czy będzie nałożony na poprzedni i obramowany (okno :)).

> 2. Uzycie istniejacego mikro-GUI - patrz ponizej.
> Po lekturze powyzszych wymagan moge stwierdzic iz to "proste" GUI w
> implemntacji bedzie calkiem rozbudowanym projektem.

No właśnie, wymagania są małe - proste GUI. To, co napisałem później, to
był efekt mojej analizy ;D...

> Zasadniczo w takej systuacji polecam wykorzystanie istniejacego tworu lub
> chociaz spojrzenie pt. "Jak to robia inni" aby uniknac wywazania otwartych
> drzwi.
> Jakis czas temu poszukiwalem jakiegos embedded GUI i z projektow open source
> jak na razie znalazlem tylko Nano-X -> http://www.microwindows.org/ ale
> obawiam sie iz port dla FreeRTOS'a bedzie wyzwaniem - jest on oparty o
> architekture klient-serwer co powoduje iz komunikacja odbywa sie przez
> sockety BSD na localhostcie :)
> Z komercyjnych ciekawie wyglada C/PEG ->
> http://swellsoftware.com/products/cpeg.php aczkolwiek tez ne ma portu dla
> FreeRTOS'a.
> Polecam tez spojrzec na GUI systemiku Contiki -> http://www.sics.se/contiki/
> oraz biblioteke graficzna PW dla wyswietlaczy monochromatycznych ->
> http://sourceforge.net/projects/pwlib/ (jest on blizsza "podejsciu
> mikrokontrolerowemu" niz Nano-X).

Właściwie o tym FreeRTOSie nie potrzebnie pisałem, bo to taki system,
choćby żaden. Procek to ARM7, obecnie jadę na płytce testowej z LPC2378,
docelowo zastosuję taki, lub jego słabszy "odpowiednik" (mniej pamięci,
bajerów - zależnie od tego ile mi projekt zajmie). Generalnie nie ma tam
systemu a'la linux czy coś ;)... No ale będę się przyglądał Twoim linkom
:)...


--
Pozdrawiam
Konop

do góry

Konop wrote:

> W dniu 2010.12.29 15:22, brak pisze:
>> Konop wrote:
>>
>>> Witam
>>>
>>> Ma ktoś jakieś doświadczenie w pisaniu *prostego* GUI dla
>>> mikrokontrolerów z wyświetlaczem dotykowym monochromatycznym?
>> Watpie, zasadniczo to widze dwie drogi :
>> 1. Jak w poscie ponizej - statyczny obrazek w postaci mapy bitowej oraz
>> napisane z palca psedo-widgety typu np. 3 cyfry w stalym miejscu ( nie ma
>> mowy o zadnych oknach a tym bardziej historiach typu mysz, przesuwanie
>> okien czy zdarzenia).
>
> Pisząc o "oknach" miałem na myśli coś na czymś - to się nie musi
> przesuwać ani nic, ale NA PEWNO będę potrzebował kilka różnych
> "ekranów"... więc w sumie mała różnica , czy nowy ekran zajmie cały
> wyświetlacz, czy będzie nałożony na poprzedni i obramowany (okno :)).
>
>> 2. Uzycie istniejacego mikro-GUI - patrz ponizej.
>> Po lekturze powyzszych wymagan moge stwierdzic iz to "proste" GUI w
>> implemntacji bedzie calkiem rozbudowanym projektem.
>
> No właśnie, wymagania są małe - proste GUI. To, co napisałem później, to
> był efekt mojej analizy ;D...
>
>> Zasadniczo w takej systuacji polecam wykorzystanie istniejacego tworu lub
>> chociaz spojrzenie pt. "Jak to robia inni" aby uniknac wywazania
>> otwartych drzwi.
>> Jakis czas temu poszukiwalem jakiegos embedded GUI i z projektow open
>> source
>> jak na razie znalazlem tylko Nano-X -> http://www.microwindows.org/ ale
>> obawiam sie iz port dla FreeRTOS'a bedzie wyzwaniem - jest on oparty o
>> architekture klient-serwer co powoduje iz komunikacja odbywa sie przez
>> sockety BSD na localhostcie :)
>> Z komercyjnych ciekawie wyglada C/PEG ->
>> http://swellsoftware.com/products/cpeg.php aczkolwiek tez ne ma portu dla
>> FreeRTOS'a.
>> Polecam tez spojrzec na GUI systemiku Contiki ->
>> http://www.sics.se/contiki/ oraz biblioteke graficzna PW dla wyswietlaczy
>> monochromatycznych -> http://sourceforge.net/projects/pwlib/ (jest on
>> blizsza "podejsciu mikrokontrolerowemu" niz Nano-X).
>
> Właściwie o tym FreeRTOSie nie potrzebnie pisałem, bo to taki system,
> choćby żaden. Procek to ARM7, obecnie jadę na płytce testowej z LPC2378,
> docelowo zastosuję taki, lub jego słabszy "odpowiednik" (mniej pamięci,
> bajerów - zależnie od tego ile mi projekt zajmie). Generalnie nie ma tam
> systemu a'la linux czy coś ;)... No ale będę się przyglądał Twoim linkom
> :)...
>

arm7 to potwor w porownaniu z contiki

--
+++

do góry

W dniu 2010-12-29 13:32 Konop napisał(a):

> Będę wdzięczny za wszelkie uwagi do mojego pomysłu :).

Przyjrzyj się bibliotece Skia:
http://code.google.com/p/skia/

Na procku ARM7 powinna śmigać aż miło. Skia robi rysowanie 2D
podstawowych obiektów, dopiszesz sobie do tego jeszcze tylko obsługę
eventów (klikania) i będzie OK.

BTW: Skia leży na samym dnie Androida, poniżej jest już tylko driver LCD.

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

do góry