Budowa MENU w sytemie z uC
Budowa MENU w sytemie z uC
Cześć.
Może troche naiwne pytanie, a może trochę nie przystoi o to pytac, ale wcześniej sie nad tym nie zastanawiałem, az do tej pory.
Powiedzmy, że budujecie jakiś układ z uC AVR. Niech to będzie np zegar. Wiadomo że trzeba jakś ustawić jego funkcje tj. godzinę, datę.
Jak rozwiązujecie problem menu. Jak go tworzycie? Nie chozi mi to o to co ma byc wyświetlone na poszczególnych pozycjach, a raczej o to jak ma ono wygladac od strony porgramowej. Czy jest to np niekończona pętla, a w niej jest np zmienna i w zalezności od jej wartości wyświetlana jest dana pozycja menu? Czy moze bardziej skomplikowane z użyciem funkcji ze wskaźnikami? Czy może jeszcze jakoś inaczej?
Możecie cos podpowiedzieć?
Może troche naiwne pytanie, a może trochę nie przystoi o to pytac, ale wcześniej sie nad tym nie zastanawiałem, az do tej pory.
Powiedzmy, że budujecie jakiś układ z uC AVR. Niech to będzie np zegar. Wiadomo że trzeba jakś ustawić jego funkcje tj. godzinę, datę.
Jak rozwiązujecie problem menu. Jak go tworzycie? Nie chozi mi to o to co ma byc wyświetlone na poszczególnych pozycjach, a raczej o to jak ma ono wygladac od strony porgramowej. Czy jest to np niekończona pętla, a w niej jest np zmienna i w zalezności od jej wartości wyświetlana jest dana pozycja menu? Czy moze bardziej skomplikowane z użyciem funkcji ze wskaźnikami? Czy może jeszcze jakoś inaczej?
Możecie cos podpowiedzieć?
Sprawa interfejsu użytkownika w systemie mikroprocesorowym jest bardzo istotna. Z jednej strony obsługa urządzenia powinna być intuicyjna a z drugiej uniemożliwiać wybór nieaktywnych funkcji czyli być "głupoto odporna". Wiele zależy od struktury jak i skomplikowania menu. Nie mniej istotna jest część sprzętowa umożliwiająca wybór funkcji czy jakby nie patrzeć wprowadzanie danych do urządzenia. W przypadku klawiatury zależnie od jej komplikacji tzn. multipleksowana/niemultipleksowana trzeba zapewnić od-kłucanie drgań styków jej przycisków. Przed wczytaniem danych z klawiatury należy (zależnie od urządzenia) wyświetlić jakiś "prompt". Zwykle wczytuję zmienną (zmienne w przypadku gdy przycisków jest więcej niż osiem) w przerwaniu od timera, Zmienna jest porównywana ze zmienną tymczasową jeżeli obie zmienne się różnią to zapamiętywana jest w zmiennej tymczasowej jeżeli są jednakowe to znaczy że naciśnięto przycisk (przyciski) i ustawiana jest flaga "zgody na przetwarzanie" wczytanej zmiennej i blokowana klawiatura. Flaga "zgody na przetwarzanie" jest ustawiona i w pętli głównej programu warunek interpretacji zmiennej jest spełniony. Instrukcja selektywnego wyboru interpretuje zmienną wczytaną z klawiatury na podstawie porównania jej z szeregiem stałych reprezentujących poszczególne funkcje menu. W tym miejscu następuje wyświetlenie stosownego komunikatu (np. potwierdzenie wybranej funkcji, rezygnacja z niej itp.), zapamiętanie poziomu menu przy menu wielo-poziomowym. Każde wykonanie pod-instrukcji resetuje flagę "zgody na przetwarzanie" i odblokowanie możliwości wczytywania danych z klawiatury. W przypadku bardziej złożonych systemów może zajść potrzeba sygnalizacji dźwiękowej naciśnięcia przycisku, blokady przycisków nieaktywnych w danym menu itp. Zagadnienie jest dość złożone aby mieć jeden uniwersalny sposób na realizację menu choć zwykle przytoczony powyżej szkielet obsługi menu jest przeze mnie stosowany.
No własnie. Pytałem o to, ponieważ spotkałem się z taką budową Menu, że każda pozycja tzw. submenu było wywoływane jako funkcja i dopiero w niej były podejmowane odpowiednie reakcje np wywołanie kolejnej funkcji zwiekszającej lub zmiejszającej daną zmienną ustawianą. Wydało mi sie to troche bardziej złożone niz myślałem, zwłaszcza operowanie na wskaźnikach do funkcji.
Ale chyba nie mam jakiegoś standardu, ma działać i tyle. Czy mniej więcej tak?
Ale chyba nie mam jakiegoś standardu, ma działać i tyle. Czy mniej więcej tak?
-
rezasurmar
- Użytkownik
- Posty: 626
- Rejestracja: 19 kwie 2009, 15:59
- Lokalizacja: Tychy
- Kontakt:
Poszukaj informacji na avrfreaks.net o tinymenu, na elce też było o tym sporo. Tinymenu ma bogatą dokumentację
, tj. jest na tyle proste, że łatwo można przerobić do własnych potrzeb.
Sam się dopiero uczę programować w C, ale już od początku nie zamierzam pisać pseudo-programów. Dobrze by menu było napisane na zasadzie wskaźników oraz czegoś w stylu klas, tzn. piszesz jedną uniwersalną procedurę, którą potem wywołujesz wielokrotnie, zależnie od poziomów menu etc. Oszczędzasz na miejscu w programie, a i sam program jest bardziej czytelny. Używasz jak by biblioteki "menu". Coś na kształt gotowych menu z Borlanda Buildera.
Sam się dopiero uczę programować w C, ale już od początku nie zamierzam pisać pseudo-programów. Dobrze by menu było napisane na zasadzie wskaźników oraz czegoś w stylu klas, tzn. piszesz jedną uniwersalną procedurę, którą potem wywołujesz wielokrotnie, zależnie od poziomów menu etc. Oszczędzasz na miejscu w programie, a i sam program jest bardziej czytelny. Używasz jak by biblioteki "menu". Coś na kształt gotowych menu z Borlanda Buildera.
-
rezasurmar
- Użytkownik
- Posty: 626
- Rejestracja: 19 kwie 2009, 15:59
- Lokalizacja: Tychy
- Kontakt:
np. tu http://www.avrfreaks.net/index.php?modu ... pe=project
Albo artykuł w EP9/2003
Wrzuciłem w załączniki.
Albo artykuł w EP9/2003
Wrzuciłem w załączniki.
- Załączniki
-
- MicroMenu.zip
- (3.53 KiB) Pobrany 510 razy
-
- tinymenu.rar
- (18.1 KiB) Pobrany 470 razy
-
- wielopoziomowe menu w c.rar
- (91.81 KiB) Pobrany 634 razy
Widzę koledzy rozpisują się tu o menu, a tak naprawdę, to zagadnienie te jest zależne od urządzenia które programujemy, bo w prostym zegarku z budzikiem, nikt nie będzie robił skomplikowanego menu, tylko wszystko ukryje pod klawiszami funkcyjnymi, na zasadzie badania czasu ich naciśnięcia.
Wiele także zależy jakim interfejsem fizycznym dysponujemy, Joystik, klawisze, enkoder, ekran dotykowy, sposób wizualizacji menu/funkcji.
To wszystko powoduje że nie ma jednego uniwersalnego rozwiązania problemu menu i jego interfejsu.
Wiele także zależy jakim interfejsem fizycznym dysponujemy, Joystik, klawisze, enkoder, ekran dotykowy, sposób wizualizacji menu/funkcji.
To wszystko powoduje że nie ma jednego uniwersalnego rozwiązania problemu menu i jego interfejsu.
-
rezasurmar
- Użytkownik
- Posty: 626
- Rejestracja: 19 kwie 2009, 15:59
- Lokalizacja: Tychy
- Kontakt:
Wiem, wiem
, ale przynajmniej mnie, bo nie wiem jak koledze slawek55 zależy na dobrze napisanym menu, które można wykorzystać w innych projektach. Do zegarka menu to przerost formy nad treścią, jak mówisz wystarczą klawisze funkcyjne.
Dla mnie pisanie jednego programu konkretnie pod dane urządzenie bez podziału na podprocedury itp, to strata czasu i skrajny brak profesjonalizmu
. Niestety sporo początkujących uczy się w ten sposób pisać, niechlujnie, bez ładu i składu.
Dla mnie pisanie jednego programu konkretnie pod dane urządzenie bez podziału na podprocedury itp, to strata czasu i skrajny brak profesjonalizmu
Zgadzam się z twierdzeniem że program powinien być dzielony na bloki funkcjonalne (funkcje, procedury, obsługi przerwań). Jednak często pisanie na siłę zbyt uniwersalnych procedur czy funkcji powadzi do zwiększenia objętości programu który mógłby być "odchudzony" o niewykorzystywane w danym urządzeniu możliwości takiej uniwersalnej funkcji. Mikroprocesor ośmio/szesnasto bitowy to jednak nie komputer PC z dyskami i pamięcią RAM podawaną w gigabajtach i często brakuje pamięci. Co do zegara który odmierza tylko czas to rzeczywiście wielopoziomowe menu to "przerost treści nad formą" chyba że jest to jakiś zegar/timer sterujący jakimś procesem a to już inna "bajka".
Z tym zegarem to był przykład, bo każdy wie co mniej więcej powinno być w takim menu.
A inny przykład. Powiedzmy, że mamy coś takiego jak układ mierzący napięcie, prąd, temperaturę. Mamy przycisk (przyciski), który umozliwia przełączenie sie pomiędzy wskazaniami. Czy budowa menu z fukcjami i wskaźnikami na funkcję, nie byłaby zbyt ambitna? Może wtedy pętla nieskońzona z instrukcjami if mogłaby być całkiem przyzwoita?
A inny przykład. Powiedzmy, że mamy coś takiego jak układ mierzący napięcie, prąd, temperaturę. Mamy przycisk (przyciski), który umozliwia przełączenie sie pomiędzy wskazaniami. Czy budowa menu z fukcjami i wskaźnikami na funkcję, nie byłaby zbyt ambitna? Może wtedy pętla nieskońzona z instrukcjami if mogłaby być całkiem przyzwoita?
-
rezasurmar
- Użytkownik
- Posty: 626
- Rejestracja: 19 kwie 2009, 15:59
- Lokalizacja: Tychy
- Kontakt:
Najlepiej zrobić prototyp, samemu sprawdzić co będzie bardziej odpowiednie. Mnie np. denerwują jednoprzyciskowe telefony itp. Cholery można dostać obsługując dotykowy ekran w rękawiczkach, albo chcąc szybko zadzwonić, wysłać sms. Podobnie w wszelkich urządzeniach minimalna ilość klawiszy, a potem jeden przycisk wciśnij, ten sam naciśnij dwa razy, koszmar. Dla mnie jeżeli ma być menu, to powinny być obowiązkowo przynajmniej 4 klawisze - góra, dół, OK, wstecz. Do 4 klawiszy jeżeli jest co najmniej 3poziomowe menu, to już warto się pokusić o lepsze menu. Jeżeli ma to być tylko kilka komend, to szkoda strzelać z armaty do muchy. Zresztą najlepiej napisać 2 różne, jedno bardziej rozbudowane i zaawansowane (chociaż uważam, że warto zaczerpnąć inspiracje z avrfreaks). Drugie proste, za pomocą case (czy tam if-then) najlepiej.
Najlepiej potem sprawdzić ile dane menu zajmuje zasobów, procesora, ludzkich
. Dobre menu napiszemy "raz", a potem będzie trzeba tylko kosmetykę zmieniać. Przecież ja nie twierdze, że ma to być od razu biblioteka na miarę .NET
(brrrr). Tylko coś do czego można przekazać parametr jako element menu. Oczywiście w przypadku atiny, się to nie sprawdzi, ale kto używa zaawansowanego menu w małych prockach. Same przecież napisy z menu zajmują sporo miejsca i też powinny być wrzucone w jakiś obszar pamięci jako tablica, by można ją było ewentualnie łatwo zmodyfikować np. przez bootloader.
Wiem, wiem, za ambitnie podchodzę do pewnych rzeczy, ale jak coś robić to porządnie, albo wcale.
Najlepiej potem sprawdzić ile dane menu zajmuje zasobów, procesora, ludzkich
Wiem, wiem, za ambitnie podchodzę do pewnych rzeczy, ale jak coś robić to porządnie, albo wcale.
Jest to absolutne minimum zapewniające łatwą obsługę i spore możliwości. Cztery przyciski obsłużą dość skomplikowane menu a nawet w przypadku podłączenia hosta MSD umożliwią wędrówkę po drzewie katalogów i wybór plikówDla mnie jeżeli ma być menu, to powinny być obowiązkowo przynajmniej 4 klawisze - góra, dół, OK, wstecz.
Gdzieś znalazłem ciekawy pomysł menu na jednym przycisku.
W każdym poziomie menu mamy pozycje ustawione według częstości używania. Naciskając przycisk przechodzimy do następnej pozycji, czekając ponad sekundę wybierana jest aktywna pozycja. Na samym początku listy jest pozycja wróć żeby w razie pomyłki nie trzeba było jej szukać. Menu ma oczywiście kilka poziomów.
Można by dodać drugi przycisk lub dłuższe przyciśnięcie przycisku, przydaje się to przy zmianie parametrów np. czasu, gdyż często nie ma sensu przelecieć przez 20 wartości żeby zmniejszyć daną wartość o jedną pozycję.
Jeśli dobrze pamiętam, to projekt znalazłem na forum AlexRC, menu zostało użyte w komputerze pokładowym modelu samolotu, wejście to jeden kanał serwa (przycisk chwilowy w nadajniku), wyjście to OSD dodawane do obrazu z kamery pokładowej.
W każdym poziomie menu mamy pozycje ustawione według częstości używania. Naciskając przycisk przechodzimy do następnej pozycji, czekając ponad sekundę wybierana jest aktywna pozycja. Na samym początku listy jest pozycja wróć żeby w razie pomyłki nie trzeba było jej szukać. Menu ma oczywiście kilka poziomów.
Można by dodać drugi przycisk lub dłuższe przyciśnięcie przycisku, przydaje się to przy zmianie parametrów np. czasu, gdyż często nie ma sensu przelecieć przez 20 wartości żeby zmniejszyć daną wartość o jedną pozycję.
Jeśli dobrze pamiętam, to projekt znalazłem na forum AlexRC, menu zostało użyte w komputerze pokładowym modelu samolotu, wejście to jeden kanał serwa (przycisk chwilowy w nadajniku), wyjście to OSD dodawane do obrazu z kamery pokładowej.
Takie menu jedno przyciskowe sprawdzi się tylko w systemach w których "auto" wybieranie pozycji menu nie spowoduje zagrożenia uszkodzenia sprzętu (utraty krytycznych parametrów, zdrowia, życia) w przypadku nie autoryzowanego wyboru pozycji menu. Wyobrażam sobie takie menu w "krzemofonie" odtwarzaczu plików muzycznych. Można pójść na kompromis między wygodą użytkowania a "pewnością działania" stosując dwa przyciski: jeden do "dookolnego" przewijania listy w jedną stronę, drugi do zatwierdzania wyboru. Na liście oczywiście musi znajdować się pozycja do wyjścia z podmenu w górę lub i powrót do menu głównego. Do tak zdefiniowanego menu można dodać przyciski szybkiego dostępu do wybranych funkcji (funkcyjne) pod które można przypisać pozycje menu najczęściej używane.
-
rezasurmar
- Użytkownik
- Posty: 626
- Rejestracja: 19 kwie 2009, 15:59
- Lokalizacja: Tychy
- Kontakt: