Ср май 06, 2020 17:58:44
могу, но не вижу смысла и не испытываю желания.Demiurg писал(а):Вы можете сказать, сколько у вас тратится? В разных вариациях.
способ вывода пунктов меню не является частью моего проекта - вы можете выводить как хотите и куда хотите! если 2 варианта вывода, что я в виде бонуса приложил в демо-проектах, вас не устраивают, вы имеете шикарную возможность написать свой вариант. это никак не изменит остальное.Demiurg писал(а):а что если экран примерно такого вида?
да хоть переливается всеми цветами радуги - еще раз повторяю: вывод - это ваша задача! вы читали документацию, которую я сделал? видели - там написано черным по белому, что функцию paint_menu должен реализовать пользователь самостоятельно!Demiurg писал(а):Значение нужного параметра мигает
вместо бесплодных рассуждений и необоснованных завлений вы лучше бы собрали демку, поигрались бы с разными параметрами, попробовали бы что-то изменить, переделать... возможно, или вопросы у вас стали бы более осмысленные, либо они исчезли бы.Demiurg писал(а):Универсальности нет и не будет.
Чт май 07, 2020 10:22:42
Чт май 07, 2020 11:50:12
надо заремарить PLACE_CONST_IN_FLASH, и тогда никакие PGMSPACE не потребуются. разве что инклюды я не прятал в #if defined - #endifWiseLord писал(а):используются функции из pgmspace
Чт май 07, 2020 13:08:47
Чт май 07, 2020 14:18:24
еще раз: они все упрятаны в условную компиляцию по макросу PLACE_CONST_IN_FLASH - если его заремарить, все будет только через ОЗУ, и эти функции_P не будут компилироваться.WiseLord писал(а):Там, в основном, разные функции с постфиксом _P прямо в коде встречаются
Чт май 07, 2020 14:33:56
Чт май 07, 2020 16:49:07
Чт май 07, 2020 19:14:10
Чт май 07, 2020 19:20:55
спасибо за тестирование! но было бы просто замечательно, если бы вы все-таки под stm32 тоже терминальный вариант собрали бы... если в GCC под ARM концепция стандартного ввода-вывода такая же, как и в avr-libc, то должно быть это просто: проинициализировать UART и определить функцию вывода байта... в самом простом случае...WiseLord писал(а):Проверил работу меню в режиме UART
Чт май 07, 2020 19:27:49
Чт май 07, 2020 19:32:08
Чт май 07, 2020 19:46:35
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;
Чт май 07, 2020 19:49:57
Чт май 07, 2020 20:34:35
Чт май 07, 2020 21:10:15
Чт май 07, 2020 21:38:35
Чт май 07, 2020 22:13:04
Пт май 08, 2020 07:40:34
похоже, выдохнуть нужно вам.Demiurg писал(а):Выдохни.
потому что логически это более понятно. меню - это интерфейс с пользователем. пользователь - в общем случае не программист, поэтому ему надо оперировать понятными терминами. в винде меню состоит именно из главного меню и субменю (подменю). иногда говорят о дочерних меню, но мне больше нравится именно термин подменю. вот я его и использую.Demiurg писал(а):Почему submenu появилoсь в вашем проекте?
еще более чудесно было бы, если бы вы все-таки вникли в суть того, что я сделал, а не судили бы об этом исключительно по придуманным вами вещам. вы постоянно противопоставляете мой вариант и MicroMenu - почему? между ними НЕТ разницы! оба варианта построены на СВЯЗНЫХ СПИСКАХ пунктов. навигация по этим спискам тоже одинакова. в чем вы видите разницу?Demiurg писал(а):В этом случае было бы вообще чудесно
тут ведь вот какая загогулина получается... изначально идея была именно в том, чтобы сделать описание меню простым: все собрать в один макрос и, при необходимости что-то поправить, делать это в одном месте, не лазя по файлам и не скролля текст. предлагаемый вами вариант фактически возвращает нас к исходной точке: все расползается... при вынесении строк в отдельные массивы уже теряется та прозрачность, которая достигается в текщем подходе, ведь использование строки не в виде ясной константы, а в виде какого-то идентификатора или того хуже - индексного обращения к массиву, - сделает код менее удобным... так что я даже не знаю, насколько это целесообразно. технически - возможно, но логически - не уверен, что будет хорошо...WiseLord писал(а):Ещё одно предложение по меню. При его формировании вместо самой строки с текстом вносить некий индекс.
При выводе меню, соответственно, брать не текст, а вызывать функцию, возвращающую текст по этому индексу.
Самая простая реализация такой функции - это просто вывод строки из массива таких строк. Более сложная, по желанию, может, учитывая настройки, выводить текст на другом языке и т.д.
интересно, зачем? как-то это не логично...WiseLord писал(а):в разных подменю могут быть пункты с одинаковым именем
Пт май 08, 2020 09:29:25
Ну, например в структуре меню типа такой:ARV писал(а):интересно, зачем? как-то это не логично...
- Температурные датчики
- Датчик 1
- Нижний порог срабатывания
- Верхний порог срабатывания
- Коррекция
- Датчик 2
- Нижний порог срабатывания
- Верхний порог срабатывания
- Коррекция
- Датчик 3
- Нижний порог срабатывания
- Верхний порог срабатывания
- Коррекция
Чтобы уменьшить количество генерируемых прошивок при очередном релизе.ARV писал(а):с какой целью вы решили сделать многоязычный интерфейс?
Пт май 08, 2020 09:29:43