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

[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