FlexMenu - решение вопросов меню. Зацените.

[ARV]

Вы можете сказать, сколько у вас тратится? В разных вариациях.

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

а что если экран примерно такого вида?

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

Значение нужного параметра мигает

да хоть переливается всеми цветами радуги - еще раз повторяю: вывод - это ваша задача! вы читали документацию, которую я сделал? видели - там написано черным по белому, что функцию paint_menu должен реализовать пользователь самостоятельно!

Универсальности нет и не будет.

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

а так не вижу смысла в наших разговорах: на любые мои слова у вас заготовлен ответ "я так делаю". ну и делайте, я ж не запрещаю! я тут при чем? я сделал ВОТ ТАК, и жду результатов впечатлений. а у вас пока что только рассказы о боевой молодости.

Добавлено after 8 minutes 22 seconds:
вы используете в своих проектах библиотечную функцию printf? не sprintf, а именно printf?
думаю, что не используете... не важно по каким причинам.
а вы знаете, в чем её огромный плюс? да в том, что достаточно САМОМУ написать единственную функцию вывода 1 символа (назовем её putch), и стандартная библиотечная функция printf будет выводить информацию в USART, или на ЖКИ, или на 7-сегментник, или записывать в файл на флешке, или отправлять по радиоканалу, или по CAN-у... фишка этой функции в том, что ей абсолютно все равно, КУДА ВЫВОДИТЬ - это делает не она, а putch.
и получается УНИВЕРСАЛЬНАЯ функция.

кстати, именно такая универсальность применена мной в модуле com_io.c, который так же в архиве вместе с демо-проектами.

и для меню принцип тот же - вывод не связан с меню.

[WiseLord]

Стало интересно, получится ли собрать библиотеку - у себя под linux.

Для AVR собралось (в варианте с UART) без особых проблем.

Но для другой платформы - STM32 - я пока даже не пытаюсь. Слишком много нужно работы провести, чтобы AVR-специфичные вещи вычистить. Практически каждый модуль прямо включает AVR-овские <avr/...> или <util/> модули. И кое-где без них не обойтись (используются функции из pgmspace и т.д).

В общем, вычистить всё это и вынести в платформозависимые .h-ки можно было бы, но много времени понадобится.

[ARV]

используются функции из pgmspace

надо заремарить PLACE_CONST_IN_FLASH, и тогда никакие PGMSPACE не потребуются. разве что инклюды я не прятал в #if defined - #endif

если я модифицирую код соответствующим образом - протестируете?

[WiseLord]

Если только на выходных.

Там, в основном, разные функции с постфиксом _P прямо в коде встречаются (копирование строки, памяти и т.д) - как я понимаю, это чисто AVR-специфичные вещи для работы с flash.

[ARV]

Там, в основном, разные функции с постфиксом _P прямо в коде встречаются

еще раз: они все упрятаны в условную компиляцию по макросу PLACE_CONST_IN_FLASH - если его заремарить, все будет только через ОЗУ, и эти функции_P не будут компилироваться.

[WiseLord]

ОК.

Хотя чисто технически - в случае STM32 (ARM) оне не в ОЗУ будут, а во флеше. Там для этого достаточно const.

В любом случае, нужно почистить исходники от avr-овских include, стянув их все в один platform-specific файл.

[ARV]

WiseLord, вот архив, в котором должно автоматически убираться все, что только для AVR предназначено (используется defined(__arm__) - вроде так в arm-gcc определено).
только я пока не знаю, как быть с портами для ЖКИ и USART-ом, а так же с EEPROM... поэтому функции работы с EEPROM просто заблокировал, а переменные в EPROM сделал в RAM. а вот вывод - это я не знаю, как делать... для USART по идее самое простое должно быть - сами сделаете?

[WiseLord]

Я всё-таки не утерпел, и попробовал это сделать, на базе предыдущих исходников.

Под STM32 ставил задачу только скомпилировать, сами отрисовки не делал.

Да, единственное на что осталась "ругань" - это eeprom_ функции, но поскольку они пока не вызываются, то код компилируется.

Забросил на github: https://github.com/WiseLord/fmenu

Добавлено after 1 hour 25 minutes 22 seconds:
Проверил работу меню в режиме UART (ATmega328p, терминал picocom):

[ARV]

Проверил работу меню в режиме UART

спасибо за тестирование! но было бы просто замечательно, если бы вы все-таки под stm32 тоже терминальный вариант собрали бы... если в GCC под ARM концепция стандартного ввода-вывода такая же, как и в avr-libc, то должно быть это просто: проинициализировать UART и определить функцию вывода байта... в самом простом случае...

[WiseLord]

Это я попробую...
Сейчас пинцетом на PC0..PC5 позамыкал - работает. Правда, пришлось маску порта C на 0x3F поменять - не знаю, зачем там 6-й бит был задействован, но мне мешало, на кнопки не реагировало. Тем более, что у ATmega328p PC6/PC7 недоступны - там только АЦП на их месте.

[ARV]

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

Добавлено after 1 minute 13 seconds:
допустим, eeprom считывание и сохранение я точно вынесу в платформозависимый модуль... или как-то так сделаю...

[WiseLord]

Пока не знаю. Когда займусь - возможно, идеи появятся.

А по поводу eeprom я подумал, написать аналог какой-то аналог eeprom_update_page, который бы пробрасывал параметры в мою имплементацию эмуляции eeprom-а для STM32

Вот её API: https://github.com/WiseLord/ampcontrol- ... rc/eemul.h

По сути, всё что нужно - это вызовы:
void eeUpdateRaw(uint16_t cell, uint16_t data); - сохраняет данные data в ячейку cell
uint16_t eeReadRaw(uint16_t cell); - читает данные из ячейки cell

Всё остальное делается внутри eemul.c и от этого можно абстрагироваться.

Использование эмулятора максимально простое, типа:

Код: Выделить всё

enum {
  PARAM_1,
  PARAM_2,
  ..
  PARAM_SPEED,
  PARAM_SOMETING_ELSE,
  ..
  PARAM_END,
}

uint16_t write_value = 34;

eeUpdateRaw(PARAM_1, write_value);

uint16_t read_value = eeReadRaw(PARAM_1); // считается 34;

А если данные больше 16 бит, то придётся для такой переменной заводить два индекса сразу. Типа PARAM_DATA_H, PARAM_DATA_L, и писать/читать подвухбайтно. Просто это ограничения самой STM32 в плане записи flash - записать одновременно можно 2 байта

Добавлено after 4 minutes 18 seconds:
А по поводу доработки кода... Я бы посоветовал завести репозиторий на Github (можно просто "форкнуть" то, что у меня получилось) и работать уже с этим кодом, периодически закидывая наработки. Тогда можно было бы параллельно что-то делать с одним и тем же кодом. Это лучше, чем постоянно перебрасываться архивами.

[ARV]

ок, если остальные мои штуки заработают на ARM, сделаю интерфейс EEPROM "выносным", чтобы обертка была прописана, а реализация - внешняя. интерфейс ваш возьму за основу лишь бы все мои выкрутасы со структурами были совестимыми... все эти выравнивания и т.п. - я от этого далёк...

Добавлено after 1 minute 26 seconds:
для ARM, скорее всего, нет смысла пункты меню делить на uint8_t и uint16_t - вряд ли экономия 1 байта важна...

[WiseLord]

В общем, на STM32 меню завелось - выводится по UART всё нормально.

Код там же на гитхабе.

Правда, printf использовать не получилось, так что сделал не через переопределение stdout, а попроще.

[ARV]

премного благодарен!

[WiseLord]

Ещё одно предложение по меню. При его формировании вместо самой строки с текстом вносить некий индекс.

При выводе меню, соответственно, брать не текст, а вызывать функцию, возвращающую текст по этому индексу.

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

А ещё один плюс - эти же строки в массиве, доступные по индексу, можно будет выводить не только из меню, но и на других "экранах" проекта.

Можете опять же у меня глянуть, как я это вижу: https://github.com/WiseLord/ampcontrol- ... ter/src/tr . Функция labelsGet() - то, что я имею в виду.

Единственное, что у меня в labels.h подключены другие файлы проекта - но это просто для синхронизации enum-ов самих Labels и других подсистем. Сейчас я от этого пытаюсь уйти.

Ещё один плюс - в разных подменю могут быть пункты с одинаковым именем. Здесь можно будет использовать один и тот же индекс вместо фактически разных строк. Хотя компиляторы сейчас умные, и такое сами могут оптимизировать (схлопнуть до одной константной строки в flash).

[Demiurg]

AVR. Я понимаю, что ты потратил время и усилия на создание своего меню. А тут видите ли я лезу тут с грязными сапогами к вашему детищу. Выдохни. Всестороннее обсуждение.
Итак. В MicroMenu нет сущности submenu. Лично я посчитал это скорее достоинством. Как я уже писал, по сути меню конечный автомат в явном виде. Количество состояний конечно. Древовидное меню или какое угодно, это не важно. Сама суть меню конечна. Будет ли это индекс, или адрес во flash не суть. Почему submenu появилoсь в вашем проекте?
В свое время я изучал как меню устроено в DOS, системах мультизагрузки. Что то ещё смотрел, лень вспоминать и перечислять. И пришёл к такому выводу. По сути нужен парсер. В этом случае было бы вообще чудесно...

[ARV]

Выдохни.

похоже, выдохнуть нужно вам.

Почему submenu появилoсь в вашем проекте?

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

В этом случае было бы вообще чудесно

еще более чудесно было бы, если бы вы все-таки вникли в суть того, что я сделал, а не судили бы об этом исключительно по придуманным вами вещам. вы постоянно противопоставляете мой вариант и MicroMenu - почему? между ними НЕТ разницы! оба варианта построены на СВЯЗНЫХ СПИСКАХ пунктов. навигация по этим спискам тоже одинакова. в чем вы видите разницу?

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

Ещё одно предложение по меню. При его формировании вместо самой строки с текстом вносить некий индекс.
При выводе меню, соответственно, брать не текст, а вызывать функцию, возвращающую текст по этому индексу.
Самая простая реализация такой функции - это просто вывод строки из массива таких строк. Более сложная, по желанию, может, учитывая настройки, выводить текст на другом языке и т.д.

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

Добавлено after 24 minutes 43 seconds:

в разных подменю могут быть пункты с одинаковым именем

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

[WiseLord]

интересно, зачем? как-то это не логично...

Ну, например в структуре меню типа такой:

Код: Выделить всё

- Температурные датчики
  - Датчик 1
    - Нижний порог срабатывания
    - Верхний порог срабатывания
    - Коррекция
  - Датчик 2
    - Нижний порог срабатывания
    - Верхний порог срабатывания
    - Коррекция
  - Датчик 3
    - Нижний порог срабатывания
    - Верхний порог срабатывания
    - Коррекция

с какой целью вы решили сделать многоязычный интерфейс?

Чтобы уменьшить количество генерируемых прошивок при очередном релизе.

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

Плюс этот способ в принципе легко переделывается назад в вариант с одним языком, если вдруг упрусь в размер flash и понадобится способ как-то подрезать размер прошивки.

Ну и опять же - раздельные текстовые метки можно использовать не только в меню, но и проще "расшаривать" на другие экраны. Ведь проект не только из меню состоит.

[Demiurg]

Мне пока трудно судить о вашем проекте в полном объёме. Для примера, проект с easyelectronics.ru я перематерился, но перенёс на IAR. В WINAVR Я никогда не работал, даже не знаю как его ставить, настраивать и тем более, как составлять makefile. Попробовал запустить в AVR Toolchain, оказывается у вас зависимость от версии.
Что нужно мне, на примере chipenable.ru архивы проектов собранные для разных компиляторов. Считаю, что подход этого автора более дружелюбен. Скачал проект под IAR, тут же обкатал его.
Итак, чтобы оценить ваш проект. IAR, МК, к примеру, ATMEGA32A. Скомпилированный рхив для LCD (при этом без опроса флага готовности) , архив для терминала.
Это не моя личная хотелка. Именно такой подход охватит бОльшую аудиторию.