Организация меню. Опции

[Jenya7]

У меня на экране сначала загружается главный экран с разделами меню. Потом я кнопками выбираю раздел и если я нажимаю ENTER появляется другой экран со своими разделами меню. Я могу вернутся на предыдущий экран и предыдущий выбранный раздел должен быть подсвечен.
Вопрос где хранить индекс текущего выбранного экрана и индекс выбранного раздела в нем? Сделать массив индексов экрана и в каждом экране массив разделов?

[iosifk]

У меня на экране сначала загружается главный экран с разделами меню. Потом я кнопками выбираю раздел и если я нажимаю ENTER появляется другой экран со своими разделами меню. Я могу вернутся на предыдущий экран и предыдущий выбранный раздел должен быть подсвечен.
Вопрос где хранить индекс текущего выбранного экрана и индекс выбранного раздела в нем? Сделать массив индексов экрана и в каждом экране массив разделов?

Я делаю так.
Вся управляющая программа должна быть описана как самый верхний автомат состояний. И каким-то состояниям этого автомата должны быть приписаны разные экраны.
В некоторых экранах есть "меню", которые тоже представляют собой автоматы состояний. И, соотв. каждому состоянию должно быть приписано условие отображения на этом экране. Нижние автоматы передают верхнему свое состояние или флаги.
Как только сделаете чтобы отображение соответствовало состоянию автомата, так все далее будет легко и просто...
Состояние главного автомата покажет, какой экран активный и в какой экран можно переходить, а в какой - нельзя. Соотв. нижний автомат покажет, какой пункт меню был нажат, какой выполнен, в какой можно переходить, а в какой - нельзя...

[Jenya7]

Я делаю так.
Вся управляющая программа должна быть описана как самый верхний автомат состояний. И каким-то состояниям этого автомата должны быть приписаны разные экраны.
В некоторых экранах есть "меню", которые тоже представляют собой автоматы состояний. И, соотв. каждому состоянию должно быть приписано условие отображения на этом экране. Нижние автоматы передают верхнему свое состояние или флаги.
Как только сделаете чтобы отображение соответствовало состоянию автомата, так все далее будет легко и просто...
Состояние главного автомата покажет, какой экран активный и в какой экран можно переходить, а в какой - нельзя. Соотв. нижний автомат покажет, какой пункт меню был нажат, какой выполнен, в какой можно переходить, а в какой - нельзя...

Но должна же быть какая то глобальная структура хранящая состояния автомата. В принципе зная выбранный экран и выбранный раздел в нем я в свиче могу перебрать все кейсы и решить какое действие предпринять.

Мне нужно найти какую нибудь компактную форму хранения выбранных разделов. Не хочу создавать двойной массив.

Сообщение отредактировал Jenya7 - Oct 25 2016, 11:16

[iosifk]

Но должна же быть какая то глобальная структура хранящая состояния автомата. В принципе зная выбранный экран и выбранный раздел в нем я в свиче могу перебрать все кейсы и решить какое действие предпринять.

Мне нужно найти какую нибудь компактную форму хранения выбранных разделов. Не хочу создавать двойной массив.

Массив структур... Или классы состояний автомата.
В главном автомате - указатель на текущий.

[Jenya7]

а что если так

CODE

typedef struct SCREEN1_S
{
uint8_t item_idx;
}SCREEN1;

typedef struct SCREEN2_S
{
uint8_t item_idx;
}SCREEN2;

typedef struct SCREEN3_S
{
uint8_t item_idx;
}SCREEN3;

typedef struct SCREENS_S
{
SCREEN1 scr1;
SCREEN2 scr2;
SCREEN3 scr3;
}SCREENS;

нет. структура хранит выбранный раздел меню но из нее не видно какой экран выбран.

о. есть идея. можно немного модифицировать.

CODE

typedef struct SCREEN1_S
{
uint8_t item_idx;
uint8_t selected;
}SCREEN1;

typedef struct SCREEN2_S
{
uint8_t item_idx;
uint8_t selected;
}SCREEN2;

typedef struct SCREEN3_S
{
uint8_t item_idx;
uint8_t selected;
}SCREEN3;

typedef struct SCREENS_S
{
SCREEN1 scr1;
SCREEN2 scr2;
SCREEN3 scr3;
}SCREENS;

теперь есть индикация выбранного экрана.

Сообщение отредактировал Jenya7 - Oct 25 2016, 11:34

[iosifk]

а что если так

Код

typedef struct SCREEN1_S
{
  uint8_t item_idx;
}SCREEN1;

typedef struct SCREEN2_S
{
  uint8_t item_idx;
}SCREEN2;

typedef struct SCREEN3_S
{
  uint8_t item_idx;
}SCREEN3;

typedef struct SCREENS_S
{
  SCREEN1 scr1;
  SCREEN2 scr2;
  SCREEN3 scr3;
}SCREENS;

Ну просто беда с Вами...
Забудьте, что у Вас "экраны"... Вы же не картины в Эрмитаже рисуете. Любой Ваш "экран" - это набор примитивов графики, их координаты на экране, тексты и их координаты на экране и фон...
Соответственно, определите один "экран", т.е создайте его описание как массив или структуру или класс с этими графическими примитивами...
Потом соответственно, главный экран, соответствующий верхнему автомату будет содержать массив экранов и указатель на активный по состоянию главного автомата...

[Jenya7]

Ну просто беда с Вами...
Забудьте, что у Вас "экраны"... Вы же не картины в Эрмитаже рисуете. Любой Ваш "экран" - это набор примитивов графики, их координаты на экране, тексты и их координаты на экране и фон...
Соответственно, определите один "экран", т.е создайте его описание как массив или структуру или класс с этими графическими примитивами...
Потом соответственно, главный экран, соответствующий верхнему автомату будет содержать массив экранов и указатель на активный по состоянию главного автомата...

У меня библиотека которая создает экраны. Каждый экран это набор графических элементов - кнопки, лейблы, чекбоксы, и.т.д Я могу вызвать экран и работать с графическими элементами - в моем случае это элементы типа LABEL - каждый LABEL это пункт меню. мне лишь нужно знать выбранный экран и пункт меню в нем.

[iosifk]

У меня библиотека которая создает экраны. Каждый экран это набор графических элементов - кнопки, лейблы, чекбоксы, и.т.д Я могу вызвать экран и работать с графическими элементами - в моем случае это элементы типа LABEL - каждый LABEL это пункт меню. мне лишь нужно знать выбранный экран и пункт меню в нем.

Ну вот, значит прорисовывать экран не нужно. И все же - экран - это массив " элементы типа LABEL", и любое действие с этими элементами должно возвращать указатель на то, какой элемент был активен...

[k155la3]

У меня на экране сначала загружается главный экран с разделами меню. Потом я кнопками выбираю раздел и если я нажимаю ENTER появляется другой экран со своими разделами меню. Я могу вернутся на предыдущий экран и предыдущий выбранный раздел должен быть подсвечен.
Вопрос где хранить индекс текущего выбранного экрана и индекс выбранного раздела в нем? Сделать массив индексов экрана и в каждом экране массив разделов?

Можно - как вариант, для простых реализаций.
Основной элемент меню - консольный цикл. Нечто автомато-подобное
Под ним подразумевается ввод оператором команд (Up-Down-Left-Right, Enter, Esc),
вывод информации на экран, режим редактирования.
В этот цикл встраивается прикладная часть, зависящая от конкретный задач в данном пункте меню.

Меню строится как обычные вызовы функций, тем самым легко обеспечивается "возвращаемость"
параметров и установок пунктов-разделов меню при выходе "вверх".

Недостаток - разрастается стек при большой вложенности.

Если требуется легко масштабируемое-изменяемое меню, то все "типовые" данные
(наименования пунктов, номерация, вызываемые ф-ии итп) заносятся в массив структур.
При этом сама функция, реализующая меню, будет проядка сотни строк, и ОДНА
Вся прикладная функциональность прописывается в таблицу в виде констант, литералов,
указателей на прикладные функции-"обработчики".

[Jenya7]

Если требуется легко масштабируемое-изменяемое меню, то все "типовые" данные
(наименования пунктов, номерация, вызываемые ф-ии итп) заносятся в массив структур.
При этом сама функция, реализующая меню, будет проядка сотни строк, и ОДНА
Вся прикладная функциональность прописывается в таблицу в виде констант, литералов,
указателей на прикладные функции-"обработчики".

мне даже не надо сохранять наименования пунктов и вызываемые функции. достаточно выбранный пункт.

[_pv]

мне даже не надо сохранять наименования пунктов и вызываемые функции. достаточно выбранный пункт.

меню сделайте как четырёхнаправленный список, тогда при возвращении наверх всегда будете знать откуда возвращаетесь.

[k155la3]

меню сделайте как четырёхнаправленный список, тогда при возвращении наверх всегда будете знать откуда возвращаетесь.

В смысле двусвязный список, в котором есть элементы "входов" и "выходов" в списки, соотв-ие уровням меню ?

[Jenya7]

меню сделайте как четырёхнаправленный список, тогда при возвращении наверх всегда будете знать откуда возвращаетесь.

это как?

В смысле двусвязный список, в котором есть элементы "входов" и "выходов" в списки, соотв-ие уровням меню ?

это как?

[XVR]

Вам нужен стек, каждый элемент которого хранит номер экрана (или указатедь на экран) и номер (или указатель) текущего элемента в нем.
Тогда при вызове вложенного меню вы заталкиваете в стек текущее меню и текущий элемент в нем, а при закрытии меню извлекаете из стека верхний элемент и отрисовываете

[_pv]

В смысле двусвязный список, в котором есть элементы "входов" и "выходов" в списки, соотв-ие уровням меню ?

У каждого элемента есть указатели на соседей для навигации в пределах списка, наверх в предыдущий уровень, и вниз в следующий.

Код

    typedef const struct Menu_Item {
        const struct Menu_Item *Next; /**< Pointer to the next menu item of this menu item */
        const struct Menu_Item *Previous; /**< Pointer to the previous menu item of this menu item */
        const struct Menu_Item *Parent; /**< Pointer to the parent menu item of this menu item */
        const struct Menu_Item *Child; /**< Pointer to the child menu item of this menu item */
        void (*SelectCallback)(void); /**< Pointer to the optional menu-specific select callback of this menu item */
        void (*EnterCallback)(void); /**< Pointer to the optional menu-specific enter callback of this menu item */
        const char Text[]; /**< Menu item text to pass to the menu display callback function */
    } Menu_Item_t;

https://github.com/abcminiuser/micromenu-v2

[Jenya7]

У каждого элемента есть указатели на соседей для навигации в пределах списка, наверх в предыдущий уровень, и вниз в следующий.

Код

    typedef const struct Menu_Item {
        const struct Menu_Item *Next; /**< Pointer to the next menu item of this menu item */
        const struct Menu_Item *Previous; /**< Pointer to the previous menu item of this menu item */
        const struct Menu_Item *Parent; /**< Pointer to the parent menu item of this menu item */
        const struct Menu_Item *Child; /**< Pointer to the child menu item of this menu item */
        void (*SelectCallback)(void); /**< Pointer to the optional menu-specific select callback of this menu item */
        void (*EnterCallback)(void); /**< Pointer to the optional menu-specific enter callback of this menu item */
        const char Text[]; /**< Menu item text to pass to the menu display callback function */
    } Menu_Item_t;

https://github.com/abcminiuser/micromenu-v2

спасибо.попробую. я правда не понимаю - у меня относительно простое меню, три экрана по три пункта в экране - 9 пунктов. можно ведь пробежаться по ним в одном кейсе. зная выбранный пункт передать его в свич и все дела. или я что то не понимаю.

[k155la3]

У каждого элемента есть указатели на соседей для навигации в пределах списка, наверх в предыдущий уровень, и вниз в следующий.
. . . .
https://github.com/abcminiuser/micromenu-v2

Спасибо.
Ссылка правильная

спасибо.попробую. я правда не понимаю - у меня относительно простое меню, три экрана по три пункта в экране - 9 пунктов. можно ведь пробежаться по ним в одном кейсе. зная выбранный пункт передать его в свич и все дела. или я что то не понимаю.

Все просто.
-------
(1) Если это разовая (учебная) задача - делайте как удобно, как Вам будет понятно и логично.
(в надежде, что исходя из этого будет правильно и надежно. Но не факт)
При этом при каждом изменении- дополнении - удалнении Вам придется вспоминать что Вы напрограммировали,
читать комментарии, вникать, что было, например года полтора назад
В процессе набивания шишек по (1) Вы перейдете к (2)
------
(2) Если это постоянная, серьезная разработка - надо все формализовать, чтобы добавление пункта меню
было добавлением строки параметров в таблице и указанием в ней функции-обработчика(ов),
а не "исследования" по (1) с правкой кода и прочей канителью.
Кроме того формализация автом. обеспечивает минимизацию логических ошибок.
-----
по "непониманию"
----------
Для начала реализуйте на case-swith - у Вас все получится.
Потом представьте, что Ваше меню состоит из десятка уровней и до сотни пунктов в некоторых входах.

[Jenya7]

понял. спасибо.

[uriy]

Я тоже в нескольких проектах применял micromenu. Рекомендую!

[Jenya7]

Я тоже в нескольких проектах применял micromenu. Рекомендую!

спасибо. остановлюсь на нем.

[Jenya7]

портирую micromenu в проект и там есть такой дифайн

Код

#define MENU_ITEM_STORAGE  PROGMEM

#define MENU_ITEM(Name, Next, Previous, Parent, Child, SelectFunc, EnterFunc, Text) \
              extern Menu_Item_t MENU_ITEM_STORAGE Next;     \
    extern Menu_Item_t MENU_ITEM_STORAGE Previous; \
    extern Menu_Item_t MENU_ITEM_STORAGE Parent;   \
    extern Menu_Item_t MENU_ITEM_STORAGE Child;  \
    Menu_Item_t MENU_ITEM_STORAGE Name = {&Next, &Previous, &Parent, &Child, SelectFunc, EnterFunc, Text}

но PROGMEM (размещение во флэш ) это для AVR а для кортекса что будет? что то я туплю.

сделал так.

Код

#define MENU_ITEM_STORAGE  const

вобще то размер RAM позволяет хранить меню в RAM. обязательно пихать его во флэш?

Сообщение отредактировал Jenya7 - Nov 3 2016, 07:50

[k155la3]

. . . . .
вобще то размер RAM позволяет хранить меню в RAM. обязательно пихать его во флэш?

Распологать во флеш следует все данные, которые не будут изменяться во время выполнения Вашего кода,
а также те, которые определены на этапе компиляции.
Если вы делаете обычное меню, а не динамически настраиваемое (не знаю зачем это комуто может понадобиться)
то используйте флеш.

[Jenya7]

Распологать во флеш следует все данные, которые не будут изменяться во время выполнения Вашего кода,
а также те, которые определены на этапе компиляции.
Если вы делаете обычное меню, а не динамически настраиваемое (не знаю зачем это комуто может понадобиться)
то используйте флеш.

понял. спасибо.

[Jenya7]

кто нибудь портировал под ARM это меню? начинает бесить.

[k155la3]

кто нибудь портировал под ARM это меню? начинает бесить.

Вы не старайтесь "в лоб" перегнать код под свой target.
Это может быть контрпродуктивно
Разберитесь детально в логике работы и реализуйте на своем процессоре.

[Jenya7]

Вы не старайтесь "в лоб" перегнать код под свой target.
Это может быть контрпродуктивно
Разберитесь детально в логике работы и реализуйте на своем процессоре.

так то и бесит что структуры не привязанные к платформе не работают. в принципе тут все должно быть генерик.

[_pv]

так то и бесит что структуры не привязанные к платформе не работают. в принципе тут все должно быть генерик.

чему там не работать-то?
там из платформозависимого только два макроса
#define MENU_ITEM_STORAGE PROGMEM
#define MENU_ITEM_READ_POINTER(Addr) (void*)pgm_read_word(Addr)

первый можно заменить на const, или на ничего если памяти не жалко,
второй на ((void*)(Addr)), так как это у авр указатели на флэш и обычные указатели отличаются.

ну либо, как уже сказали, просто посмотреть как сделано и сделать самому без заворачивания в макросы и кастования void*.

[Jenya7]

чему там не работать-то?
там из платформозависимого только два макроса
#define MENU_ITEM_STORAGE PROGMEM
#define MENU_ITEM_READ_POINTER(Addr) (void*)pgm_read_word(Addr)

первый можно заменить на const, или на ничего если памяти не жалко,
второй на ((void*)(Addr)), так как это у авр указатели на флэш и обычные указатели отличаются.

ну либо, как уже сказали, просто посмотреть как сделано и сделать самому без заворачивания в макросы и кастования void*.

а почему (void*)? (Menu_item_t*) вроде как.

[_pv]

а почему (void*)? (Menu_item_t*) вроде как.

наследие АВР, при хранении меню во флэше pgm_read_ возвращает void*.
соответственно указатели на колбэки и на другие пункты меню читаются из флэша как void* и где надо приводятся к (Menu_item_t*), а где надо к void (*Callback)(void).
то есть там вообще что угодно может быть и всё равно где надо приведётся к нужному типу.
#define MENU_ITEM_READ_POINTER(Addr) (Addr)
работать будет ничуть не хуже.

[Jenya7]

наследие АВР, при хранении меню во флэше pgm_read_ возвращает void*.
соответственно указатели на колбэки и на другие пункты меню читаются из флэша как void* и где надо приводятся к (Menu_item_t*), а где надо к void (*Callback)(void).
то есть там вообще что угодно может быть и всё равно где надо приведётся к нужному типу.
#define MENU_ITEM_READ_POINTER(Addr) (Addr)
работать будет ничуть не хуже.

я понял. спасибо.
чтоб не открывать отдельную тему хочу спросить. по сути дела это Linked List. Каждый член структуры имеет тип этой структуры, ну кроме указателей на функции. но такого типа в принципе нет, есть uint8_t, uint32_t , но Menu_item_t это наше определение. так сколько байт займет структура после компиляции?

Сообщение отредактировал Jenya7 - Nov 4 2016, 11:51

[_pv]

я понял. спасибо.
чтоб не открывать отдельную тему хочу спросить. по сути дела это Linked List. Каждый член структуры имеет тип этой структуры, ну кроме указателей на функции. но такого типа в принципе нет, есть uint8_t, uint32_t , но Menu_item_t это наше определение. так сколько байт займет структура после компиляции?

6 указателей по 4 (для кортекса) байта.

[Jenya7]

6 указателей по 4 (для кортекса) байта.

спасибо.

[Jenya7]

Вобщем прикрутил таки
https://github.com/abcminiuser/micromenu-v2
Оч доволен. Навигация по пунктам меню, с колбэками, все работает четко. Но пункты дбавляю в дизайн тайм

Код

//MAIN MENU
//            NAME      NEXT,       PREVIOUS    PARENT,      CHILD       //SELECT    //ENTER
MENU_ITEM(m_manual, m_fails,    m_auto,       NULL_MENU,   NULL_MENU,  NULL_FUNC,   NULL_FUNC,  "MANUAL");
MENU_ITEM(m_fails,  m_muxbus,   m_manual,   NULL_MENU,   m_mf,       NULL_FUNC,   GoToChild,  "FAILS ");
MENU_ITEM(m_maint,  m_auto,     m_muxbus,   NULL_MENU,   m_lmfls,    NULL_FUNC,   GoToChild,  "MAINT ");
MENU_ITEM(m_auto,   m_manual,   m_maint,    NULL_MENU,   NULL_MENU,  NULL_FUNC,   NULL_FUNC,  "AUTO  ");

Но я как всегда со своими идеями - а что если добавлять пункты в ран тайм

Код

void MenuItemCreate (Menu_Item_t Name, Menu_Item_t Next)
{
    MENU_ITEM(Name, Next, NULL_MENU, NULL_MENU, NULL_MENU, NULL_FUNC, NULL_FUNC, "TEST");
}

Компайлер конечно орет - он хочет extern. а я не могу передать extern в функцию.
Можно как то схитрожопить?

Сообщение отредактировал Jenya7 - Jul 29 2018, 07:27

[inventor]

я взял за образец меню от миландра
перетащил на свой контроллер и другой дисплей
все работает.

Прикрепленные файлы

 mdr1986ve3_menu_test.rar ( 1.1 мегабайт ) Кол-во скачиваний: 34

 

[Jenya7]

я взял за образец меню от миландра
перетащил на свой контроллер и другой дисплей
все работает.

спасибо. очень даже интересная идея.

[x893]

Если не секрет - Какая идея очень даже интересная ?

[Jenya7]

Если не секрет - Какая идея очень даже интересная ?

Код

void ReadKey(void)
{
    uint32_t key;

    while (1) {
    key = GetKey();
    switch (key) {
    case SEL:
        SelFunc();
        break;
    case UP:
        UpFunc();
        break;
    case DOWN:
        DownFunc();
        break;
    case BACK:
        ReturnFunc();
        break;
    }
    WAIT_UNTIL_KEY_RELEASED(key);
    }
}