Witam,
Czy mógłby mi ktoś spróbować powiedzieć czy na podstawie takiego hmm ala diagramu można coś wywnioskować - BEZ ŻADNYCH dodatkowych opisów ? OCZYWIŚCIE chodzi tutaj generalnie o diagram, który ma obrazować w jaki sposób działać ma MkMENU_LIB czyli przygotowywana przeze mnie biblioteka do obsługi dowolnego MENU na dowolnym mikrokontrolerze i co ciekawe na dowolnym wyświetlaczu a co jeszcze lepsze na dowolnym urządzeniu wejściowym, gdzie na przykładach pokazuję, w poprzednich poradnikach wideo, że zastosować można do sterowania takie rzeczy jak enkoder, poprzez najzwyklejsze mikroprzyciski aż po piloty podczerwieni i mnóstwo innych.
Nie chodzi mi o to aby późniejsze opisy czy instrukcję zastąpić jednym diagramem. To ma na celu jedynie sprawdzenie czy jest to w jakiś sposób czytelne i na ile czytelne. Miło byłoby również gdyby ktoś napisał co jest nieczytelne i dlaczego, ew jakieś sugestie ;) Bardzo mnie interesuje co uda się wam wywnioskować z prezentowanego diagramu bez żadnych moich dalszych sugestii - więc jak ? pomożecie ? ;) Oczywiście z góry dziękuję, pozdrawiam i zapewniam, że już niedługo ukaże się wersja ostateczna, która w porównaniu do pierwotnie pokazywanej będzie miała być może jeszcze jakieś dodatkowe "bajery" ;) Poniżej w poście znajduje się oczywiście rysunek w wysokiej rozdzielczości.
kliknij w obrazek aby go powiększyć na ekranie
;)
Ja czytam to tak:
OdpowiedzUsuń1 faza init gdzie user rejestruje swoje callbacki
2 w pętli głównej uruchamiam user uruchamia funkcję mk_menu
3 funkcja mk_menu informuje pętlę główną jeśli menu włączone
4 kolejne są funkcje wybranego przez użytkownika interfejsu (encoder, switch, IR)
5 dalej są ciała funkcji czyli callbacki zarejestrowane w bibliotece menu, które są uruchamiane przez samo menu jeśli jest aktywne...
6 na końcu konfiguracja wyświetlacza jakiegokolwiek :)
Dziękuję ślicznie ;) ... czyli nie jest tak źle z tym diagramem
UsuńCzysto i przejrzyscie.
OdpowiedzUsuńTo może ja zacznę :) Rozpocznę o rzeczy prozaicznych, kiedyś to Mirku broniłeś polskich opisów/komentarzy, a ostatnio to coraz więcej tego angielskiego u Ciebie. Ja chcę tą wersję PL ;)
OdpowiedzUsuńA przechodząc do konkretów. Na podstawie diagramu, ostatniego poradnika o MKmenu i pisząc z głowy wnioskuję. Na starcie musimy zainicjalizować oczywiście obsługę menu, a także możemy zarejestrować własne funkcje do obsługi poszczególnych zdarzeń, czyli: zmiana obecnego węzła (pozycji obecnej gałęzie), zmiana gałęzi (menu, podmenu, itd.), wybór węzła (wybór gałęzi ostatecznej). Może jakiś rysunek, z opisem co to jest gałąź, węzeł, bo nie wiem czy sam się w tym nie pogubiłem? Do takiej funkcji wnioskuję wysyłali byśmy jako argument numer węzła związanego z danym zdarzeniem (na filmiku takie numery posiadają chyba tylko węzły ostateczne). W takich własnych funkcjach musieli byśmy przygotować jakiegoś np. switch-a który np. zapali nam diodę jeśli wybierzemy węzeł „zapal diodę” (lub uruchomi inną funkcję). Funkcja ta otrzyma numer tego węzła, dla wygody będziemy mogli korzystać z typu wyliczeniowego. Na chwilę obecną nie mam pomysłu na zastosowanie przez użytkownika pozostałych callbacków, ale ważne że są i można ich w każdej chwili użyć.
Główna pętla będzie zawierała dwie funkcje. Is_menu_on() będzie czuwała nad wyświetleniem menu jeśli będzie ono aktywne tzn. nie zakończył się jeszcze czas do auto wyłączenia albo użytkownik nie wyszedł z menu. Zadaniem mk_menu(x) będzie obsługa całej logiki poruszania się po drzewie menu. Nie wiem czy dobrze to interpretuje te strzałeczki nie są dla mnie do końca zrozumiałe. Może chodzi o to że mk_menu(x), otrzymuje dane z zewnątrz (np. od funkcji obsługującej przycisk) i „wkłada” (interpretuje) je w całej bibliotece od MkMENU, a is_menu_on() na podstawie danych globalnych wyświetla menu na ekran.
Do funkcji kontroli nad menu będziemy liczbami (typ wyliczeniowy) wysyłać poszczególne polecenia (np. następny węzeł itd.). A może to będzie jakiś zestaw funkcji (bo jest liczba mnoga). Każda przygotowana pod inny typ kontrolera (ir, mocroswitch, encoder)? Tylko dla czego tego nie połączyć w jedną i z innych bibliotek (np. do obsługi ir) i zawartych tam funkcji nie otrzymywać już gotowych liczb. Może się nie da tak łatwo, może coś mnie ominęło. Funkcje kontroli nad menu będzie odpowiedzialna za poruszanie się po menu, zapisywanie obecnej pozycji.
Ta duża strzałka w dół od „user registered fuctions”, ma zapewne oznaczać, że wraz z zdarzeniami (tymi „change NODE EVENT, itd.), oprócz funkcji wbudowanych wywołają się też funkcje zarejestrowane przez programistę na początku programu. Tylko czy „execute selected node function”, nie zawiera się już w pojęciu funkcji zarejestrowanej przez programistę? Przecież „display” są poleceniami wewnętrznymi, a „execute” musi być raczej dopisane. (nie wiem czy pojąłeś co mam na myśli)
Reset zapewne posłuży do definitywnego zamknięcia menu, tzn. ustawieniu pozycji w menu na takim (0, 0) i wygaszenia menu. Tak troszkę jest narysowany w oderwaniu od zwykłych funkcjonalności menu, czy na pewno tak powinno być? Chyba, że jednak nie pojąłem jego idei.
A na samym końcu tego wszystkiego uniwersalna funkcja przygotowana pod różne typy wyświetlaczy w zależności od ilości wierszy, ilości znaków itp., która komunikuje się już z inną biblioteką do wysyłania danych na wyświetlacz. Zapewne będziemy musieli sterować dyrektywą preprocesora żeby wybierać różne typy wyświetlaczy, ale coś mi świta, że w jednym poradniku było to automatyczne (ale jak?).
Właśnie tak to widzę. Nie wiem czy dobrze, że się naprodukowałem, ale niech stracę. Nawet wyszedł z tego niezły esej, a miałem się do sesji uczyć. Co w moim opisie zabrakło? Pewnie myślenia o przerwaniach, ale nie umiałem tego inaczej ująć. No i zapewne jest sporo chaosu, ale sam tego chciałeś ;)
Bardzo dziękuję i za tę próbę opisu. Nie ma co patrzeć czy jest chaos czy nie bo nie w tym rzecz, właśnie celem było sprawdzenie jak to widzą różne osoby zarówno te mniej jak i bardziej doświadczone w programowaniu w C. Bo nawet jeśli miałbym powiedzieć, że gdzieś pobłądziłeś to nie ... ja już to ja pobłądziłem w opisie, diagramie itp. Tak czy inaczej twój opis to dla mnie równie cenna wskazówka i jeszcze raz dziękuję ;)
UsuńDla mnie pismo obrazkowe, zawsze dużo lepiej przemawiało aniżeli proza :) A tak na poważnie to w pełni podzielam wypowiedź Sławka.
OdpowiedzUsuńMnie zastanawia tylko kiedy zadziała controller reset? :)
OdpowiedzUsuńPo pierwsze oczywiście wtedy jeśli w ogóle zarejestrujemy ten callback, a jego zadaniem jest ew reset enkodera jeśli np był pokręcany w trakcie wykonywania się jakiejś funkcji menu, aby po wyjściu z tej funkcji nie nastąpiło automatyczne przejście do poprzedniej albo następnej pozycji menu. Jeszcze będę to wyjaśniał dokładnie, ale to jak mówię najmniej istotny callback i tylko przy tej implementacji enkodera na przerwaniach i zdarzeniach opartej.
UsuńTo ja może z innej beczki. Tak jak Karol N napisał obrazki bardziej przemawiają do wyobraźni, ale pod warunkiem, że obrazki nie przytłoczą swą 'urodą' treści którą mają przekazać. Stąd też ten schemat jest dla mnie ciut za bardzo chaotyczny w swej formie. Zdecydowanie wolałbym ujednolicenie szaty graficznej w kierunku prostoty - jak w bloczkach 'Register collbacks' i 'Encoder or..' niż przesadnie wypudrowanych jak bloczki 'Change NODE...'.
OdpowiedzUsuńDziękuję również za tę cenną uwagę.
Usuń