Uniwersalna biblioteka obsługi menu wielopoziomowego - jak to ugryźć?

[pmochocki]

Już chciałem pisać rozprawkę o używaniu narzędzi odpowiednich do złożoności rozwiązywanego problemu, ale raczej sobie odpuszczę.

Mam pytanie o:

	IOmenu->callback[5] = esc;
	IOmenu->callback[6] = mexit;

co dokładnie ma robić esc i mexit? Pewnie okaże się oczywiste po wyjaśnieniu  

[ethanak]

Po co tyle tych funkcji? A co będzie kiedy trzeba będzie dodać jeszcze jedną akcję której nie przewidziałeś?

Inaczej: czy wykonanie polecenia "do góry" może skutkować czymś innym niż przesunięcie do poprzedniej pozycji jeśli to możliwe lub zignorowaniem polecenia jeśli jesteś na początku? Jeśli tak, podaj przykład.

[_LM_]

@pmochockiesc zakładam szybkie czyszczenie edytowanego pola, exit szybkie wyjście z menu. 

1 minutę temu, ethanak napisał:

Po co tyle tych funkcji? A co będzie kiedy trzeba będzie dodać jeszcze jedną akcję której nie przewidziałeś?

Dlatego wskaźniki są w tablicy, tak aby można bez problemu dodać akcje, faktycznie z tą inicjalizacją trzeba jeszcze przemyśleć sprawę, wiedziałem że się o to "przyczepisz"  

[_LM_]

Czekaj czekaj czy ty mi sugerujesz że nie powinienem na przód zakładać kierunku przechodzenia po elementach menu? Przecież nie mamy zbyt wiele możliwości  jest góra, dół, prawo,lewo wejście, wyjście

Poza tym nie zakładam zmiany układu menu w trakcie działania programu, chyba że hm no ale to sporo miejsca zajmuje a przecież nie piszemy systemu operacyjnego

Edytowano Grudzień 21, 2021 przez _LM_

[_LM_]

No tak, dochodzi jeszcze zmiana kontekstu w trakcie działania menu, przycisk czy coś musi mieć możliwość zmiany oddziaływania zależnie od wybranej opcji

[ethanak]

A co tam się może zmienić?

Pozornie niby tak - np. w menu mojej Anetki jest pozycja "temperatura" i jak tam wciśniesz "enter" to klawisze góra/dół realizują zmuanę nastawu temperatury... ale przecież tego nie realizuje program menu tylko funkcja, którą wywołało wciśnięcie entera. A to zupełnie inna bajka.

[FlyingDutch]

4 godziny temu, ethanak napisał:

Teraz weź  swój kod i zmień tak, że na wejściu jest enkoder, a na wyjściu syntezator mowy z uwzględnieniem "where am i". A jak już to zrobisz, to dodaj na szybko dwie pozycje gdzieś na trzecim poziomie a na drugim połącz pozycję 3 i 5 w jedną.

Dodawanie nowych pozycji jest bardzo proste: dodanie nowego stanu i proste zmodyfikowanie przejść miedzy stanami "transitions". W "stanach" mamy wskaźniki na funkcje, które są wykonywane przy wejściu do danego stanu. Dodanie obsługi enkodera jest bardzo proste dodanie funkcji, która w swoim ciele generuje dodatkowy event dla FSM.

pozdrawiam

[ethanak]

@FlyingDutch Mam prośbę. Ponieważ na razie udowadniasz wyższość istniejącego rozwiązania nad takim, którego nawet wstępne założenia nie są określome - poczekaj przynajmniej do jutra, do tego czasu pewnie coś się wyklaruje. Wtedy z czystym sumienem będziesz mógł powiedzieć "a nie mówiłem?"

Piszę na poważnie, bez żadnych złośliwości i podtekstów.

[FlyingDutch]

36 minut temu, _LM_ napisał:

Czekaj czekaj czy ty mi sugerujesz że nie powinienem na przód zakładać kierunku przechodzenia po elementach menu? Przecież nie mamy zbyt wiele możliwości  jest góra, dół, prawo,lewo wejście, wyjście

i tak jest dokładnie w kodzie, który przedstawiłem - naciśniecie klawiszy: góra, dół, prawo,lewo wejście generuje eventy(po polsku zdarzenia) dla maszyny FSM, po których wystąpieniu dokonuje ona zmiany stanu (w definicji "transitions" przejść stanów od FSM  są te zdarzenia). Coś mi się zdaje, że próbujecie odkryć koło na nowo .

Pozdrawiam

[FlyingDutch]

Przed chwilą, ethanak napisał:

@FlyingDutch Mam prośbę. Ponieważ na razie udowadniasz wyższość istniejącego rozwiązania nad takim, którego nawet wstępne założenia nie są określome - poczekaj przynajmniej do jutra, do tego czasu pewnie coś się wyklaruje. Wtedy z czystym sumienem będziesz mógł powiedzieć "a nie mówiłem?"

Piszę na poważnie, bez żadnych złośliwości i podtekstów.

@ethanak,

ja też na poważnie - nie zadaliście sobie trudu, aby chociaż pobieżnie przeanalizować kod, który przedstawiałem. Skąd tak wnoszę, bo piszecie dalej o sprawach, które w tym kodzie zostały bardzo prosto zrealizowane. Bardzo Cię cenię @ethanak, ale uważam, że w tym wątku trochę się za bardzo pośpieszyłeś z komentarzami..Ale dobra powstrzymam się do jutra od dalszych komentarzy.

Druga sprawa, gdyby ktoś napisał, że napisze swojego bardzo prostego RTOS'a na AVR'y to bym przyklasnął temu pomysłowi, ale pisanie generatora menu dla Arduino , to według mnie lekka przesada . Tak ,ze nie jestem przeciw postępowi, ale opartemu na zdroworozsądkowych zasadach.

Pozdrawiam

 

[_LM_]

25 minut temu, ethanak napisał:

poczekaj przynajmniej do jutra

Najgorzej że muszę za chwilę lecieć na dyżur więc możliwości pracy z libsem będę miał ograniczone.

@FlyingDutch może tak się stać że projekt zostanie porzucony nie mówię że nie(choć pewnie i tak będę próbował dalej). Chciałbym żebyś przeczytał jeszcze raz pierwszy wpis, zrozum że nie chodzi mi tylko o małe AVR  

 

[Elvis]

16 minut temu, FlyingDutch napisał:

Druga sprawa, gdyby ktoś napisał, że napisze swojego bardzo prostego RTOS'a na AVR'y to bym przyklasnął temu pomysłowi, ale pisanie generatora menu dla Arduino , to według mnie lekka przesada .

Pisania RTOS-a na AVR się nie podejmę, ale można założyć nowy wątek i zacząć pisanie czegoś na ARMv7-m

[ethanak]

Dobra, wróćmy do meritum.

Zacznijmy od pewnych założeń:

• Menu i jego obsługa to nie główne zadanie aplikacji, ma jedynie umożliwić wprowadzenie jakichś danych
• Całe menu siedzi sobie w obszarze pamięci read only
• Menu najprawdopodobniej będzie generowane jakim generatorem, co nie wyklucza ręcznego utworzenia odpowiednich struktur
• Funkcje realizujące translację wejść na polecenia MENU_CMD_* są odrębną częścią biblioteki, może być ich kilka
• Funkcje wyświetlające menu są odrębną częścią biblioteki, może ich być kilka

Załóżmy dla uproszczenia, że nasz mikrokontroler ma jednolity sposób adresowania (tzn. nie ma dziwactw typu PROGMEM), ale pamiętamy od początku o takiej możliwości.

Również dla uproszczenia załóżmy, że wyświetlane są wyłącznie napisy.

Dlatego też zacznijmy od dwóch deklaracji typów:

typedef const struct menu_menuItem *menu_MENUADDR;
typedef const char * menu_displayItem;

Te deklaracje mogą być różne dla rożnych implementacji, ale do wersji uproszczonej wystarczą.

Spróbujmy teraz stworzyć jakąś strukturę opisującą pojedynczy element menu:

struct menu_menuItem {
    menu_MENUADDR prev, next, parent, child;
    menu_displayItem display;
    uint8_t (*executor)(struct menu_Menu *);
    void *userData;
    uint8_t type;
};

i enumerator typu menu:

enum {
    MENU_TYPE_STANDARD = 0,
    MENU_TYPE_CHECKBOX,
    MENU_TYPE_RADIO,
    MENU_TYPE_MAX
};

Tu chyba wszystko jest jasne, dodajmy więc jakąś strukturę opisującą całe menu włącznie ze stanem bieżącym. Jext ona zaskakujaco krótka:

struct menu_Menu {
    struct menu_menuItem *top;
    struct menu_menuItem *current;
};

Taka struktura musi być umieszczona w RAM-ie, z uwagi na wskaźnik current.

No i teraz możemy sobie utworzyć podstawowe makra określające dostęp do poszczególnych pól struktury menu_menuItem:

#define menu_GETITEM(menuitem, which) (menuitem)->which
#define menu_GETUDATA(menuitem) (menuitem)->userData
#define menu_GETDISPL(menuitem) (menuitem)->displaya
#define menu_TYPE(menuitem) (menuitem)->type

Po co tak?

A po to, że w przypadku AVR-ów sprawa się skomplikuje, i np. makro menu_GETUDATA mogłoby wyglądać jakoś tak:

#define menu_GETUDATA(menuitem) pgm_read_word((uint8_t *)menuitem + offsetof(menu_menuItem, userData))

Ale nie komplikujmy sprawy, AVR-ami można się zająć potem.

Jak pisałem na początku, funkcja realizująca pobieranie polecenia z wejścia jest całkiem odrębna. Możemy założyć jedynie, że istnieją dwie funkcje:

extern void input_Update();
extern uint8_t input_getMenuCommand();

przy czym funkcja input_getMenuCommand() powinna zwrócić którąś z wartości z enumeratora:

enum {
    MENU_CMD_NONE=0,
    MENU_CMD_BACK,
    MENU_CMD_FWD,
    MENU_CMD_UP,
    MENU_CMD_DOWN,
    MENU_CMD_ENTER,
    MENU_CMD_CANCEL,
    MENU_CMD_MAX
};

Ale... padło wcześniej pytanie, czy od początku musimy znać wszystkie możiwe polecenia? Absolutnie nie. Wyobraźmy sobie coś takiego:

enum {
    MYMENU_CMD_PGUP = MENU_CMD_MAX,
    MYMENU_CMD_PGDN,
    MYMENU_CMD_HOME,
    MYMENU_CMD_END,
    MYMENU_CMD_MAX
};

Konkretna funkcja (np interpretująca dane z odbiornika IR) mogłaby zwracać takie wartości, tyle że program musi wiedzieć co z tym zrobić.

Ale wróćmy do core.

Oczywiście kody poniżej nie są absolutnie próbą stworenia gotowej biblioteki - wręcz przeciwnie, mają za zadanie jedynie pokazać jak to  można zrealizować.

uint8_t menu_doMenu(struct menu_Menu *menu,int command)
{
    struct menuItem *item=menu->current, *newitem;
    switch (command) {
        case MENU_CMD_NONE:
        // tu można sie pobawic w timeout jeśli menu ma się wyłączyć
        return 0;
        
        case MENU_CMD_BACK:
        return menu_setItem(menu, menu_GETITEM(item, parent);
        
        case MENU_CMD_UP:
        return menu_setItem(menu, menu_GETITEM(item, up);
        
        case MENU_CMD_DOWN:
        return menu_setItem(menu,menu_GETITEM(item, down);
        
        case MENU_CMD_FWD:
        newitem = menu_GETITEM(item, child);
        if (newitem) return menu_setItem(menu, newitem);
        if (item->executor) return item->executor(menu);
        break;
        
        case MENU_CMD_ENTER:
        if (item->executor) return item->executor(menu);
        newitem = menu_GETITEM(item, child);
        if (newitem) return menu_setItem(menu, newitem);
        break;
        
        case MENU_CMD_CANCEL:
        menu->current = MENUNULL;
        return MENU_CANCELED;
        
        default:
        // tak sie nie powino zdarzyć
        return 0;
    }
    
    // tu wiemy że był albo ENTER albo FWD, oba działają tak samo
    // w przypadku checkbox i radio userData wskazuje na zmienną typu uint8_t
    
    if (menu_TYPE(item) == MENU_TYPE_CHECKBOX) {
        *(uint8_t)menu_GETUDATA(item) ^= 1;
        menu_Display(menu, MENU_DISPLAY_CURRENT);
        return 0;
    }
    if (menu_TYPE(item) == MENU_TYPE_RADIO) {
        *(uint8_t *)menu_GETITEM(item, userData = 1;
        for (newitem = menu_GETITEM(item, prev); newitem; newitem = menu_GETITEM(item, prev)) {
            if (menu_TYPE(newitem) == MENU_TYPE_RADIO) *(uint8_t *)menu_GETUDATA(newitem) = 0;        
        }
        for (newitem = menu_GETITEM(item, next); newitem; newitem = menu_GETITEM(item, next)) {
            if (menu_TYPE(newitem) == MENU_TYPE_RADIO) *(uint8_t *)menu_GETUDATA(newitem) = 0;        
        }
        return 0;
    }
    // tak sie nie powinno zdarzyć
    return 0;
}

no i pomocnicza funkcyjka:
 
 

static uint8_t menu_setItem(struct menu_Menu *menu, struct menu_menuItem *item)
{
    if (item) {
        menu->current = item;
        menu_Display(menu, MENU_DISPLAY_SMART);
    }
    return 0;
}

Kod jest na tyle krótki i prosty że nie powinien sprawić problemu w zrozumieniu... afragment kodu aplikacju mógłby wyglądać np. tak:
 

// pętla główna
	for (;;) {
		input_Update();   
		if (MojeMenu.current) {
			int cmd = input_getMenuCmmand();
			menu_DoMenu(&mojeMenu, cmd);
			continue;
		}
		// tu reszta kodu

 

Ej, zaraz. A co z tymi rozszerzonymi poleceniami?

Jak widać, główna funkcja w ogóle na nie nie zareaguje. Ale można jakoś temu zaradzić.

Załózmy istnienie jakiejś dodatkowej funkcji realizującej owe dodatkowe polecenia. Dodajmy więc do struktury menu_Menu pozycję:

uint8_t (*extra_inp)(struct menu_Menu *menu,int command);

a w funkcji menu_doMenu dodajmy w miejsce komentarza "tak się nie powinno zdarzyć" linijkę:
    
 

if (menu->extra_inp) return menu->extra_inp(menu, command);

To by było na dzisiaj na tyle. W razie niejasności postaram się dokładniej wyjaśnić.

[_LM_]

No i to jest siła callbacków i struktur w języku C. Dzięki @ethanak mam punkt wyjścia, i tak już o wiele więcej wiem niż wynika z pierwszego wpisu, co do generowania menu to niemal od początku zakładałem że takie narzędzie będzie trzeba stworzyć - mi łatwiej będzie napisać aplikację w b4j, zobaczymy jak to wszystko wyjdzie w praktyce. Jak dla mnie jest już późno aby wgryźć się w kod który pokazałeś także zostawiam sobie to na późniejszy czas

[_LM_]

Idzie mi to jak krew z nosa, no ale coś tam w miarę czasu wolnego działam. Mam pewną koncepcję związaną ze strukturami w menu: ponieważ budowa struktury od razu wymusza sposób prezentacji danych - przeważnie jest to wskaźnik na tekst, zastanawiam się czy nie lepiej byłoby zamiast tego indeksować pozycję menu przez zwykłego uin16_t. A dopiero na podstawie tego indeksu użyktownik mógłby podjąć decyzję w jaki sposób prezentować dane. Takie podejście komplikuje utworzenie szkieletu menu, ale jak już wcześniej pisałem, jeśli projekt się powiedzie to obliguję się do napisania oprogramowania do tego. Teraz struktura wyglądałaby tak: 

1) stara wersja zaproponowana przez @ethanak

struct menu_menuItem {
    menu_MENUADDR prev, next, parent, child;
    menu_displayItem display;
    uint8_t (*executor)(struct menu_Menu *);
    void *userData;
    uint8_t type;
};

2) z indeksem:

struct menu_menuItem {
    menu_MENUADDR prev, next, parent, child;
    uint16_t idx; // zmiana
    uint8_t (*executor)(struct menu_Menu *);
    void *userData;
    uint8_t type;
};