Вы можете сказать, сколько у вас тратится? В разных вариациях.
могу, но не вижу смысла и не испытываю желания. сколько бы ни тратилось - я предлагаю комплексное готовое решение. кроме того, я выложил код, включая демо-проекты - можете собрать и посмотреть самостоятельно. да и по описанным макросам "вычислить" размер структур не сложно.
Demiurg писал(а):
а что если экран примерно такого вида?
способ вывода пунктов меню не является частью моего проекта - вы можете выводить как хотите и куда хотите! если 2 варианта вывода, что я в виде бонуса приложил в демо-проектах, вас не устраивают, вы имеете шикарную возможность написать свой вариант. это никак не изменит остальное.
Demiurg писал(а):
Значение нужного параметра мигает
да хоть переливается всеми цветами радуги - еще раз повторяю: вывод - это ваша задача! вы читали документацию, которую я сделал? видели - там написано черным по белому, что функцию paint_menu должен реализовать пользователь самостоятельно!
Demiurg писал(а):
Универсальности нет и не будет.
вместо бесплодных рассуждений и необоснованных завлений вы лучше бы собрали демку, поигрались бы с разными параметрами, попробовали бы что-то изменить, переделать... возможно, или вопросы у вас стали бы более осмысленные, либо они исчезли бы.
а так не вижу смысла в наших разговорах: на любые мои слова у вас заготовлен ответ "я так делаю". ну и делайте, я ж не запрещаю! я тут при чем? я сделал ВОТ ТАК, и жду результатов впечатлений. а у вас пока что только рассказы о боевой молодости.
Добавлено after 8 minutes 22 seconds: вы используете в своих проектах библиотечную функцию printf? не sprintf, а именно printf? думаю, что не используете... не важно по каким причинам. а вы знаете, в чем её огромный плюс? да в том, что достаточно САМОМУ написать единственную функцию вывода 1 символа (назовем её putch), и стандартная библиотечная функция printf будет выводить информацию в USART, или на ЖКИ, или на 7-сегментник, или записывать в файл на флешке, или отправлять по радиоканалу, или по CAN-у... фишка этой функции в том, что ей абсолютно все равно, КУДА ВЫВОДИТЬ - это делает не она, а putch. и получается УНИВЕРСАЛЬНАЯ функция.
кстати, именно такая универсальность применена мной в модуле com_io.c, который так же в архиве вместе с демо-проектами.
и для меню принцип тот же - вывод не связан с меню.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Стало интересно, получится ли собрать библиотеку - у себя под linux.
Для AVR собралось (в варианте с UART) без особых проблем.
Но для другой платформы - STM32 - я пока даже не пытаюсь. Слишком много нужно работы провести, чтобы AVR-специфичные вещи вычистить. Практически каждый модуль прямо включает AVR-овские <avr/...> или <util/> модули. И кое-где без них не обойтись (используются функции из pgmspace и т.д).
В общем, вычистить всё это и вынести в платформозависимые .h-ки можно было бы, но много времени понадобится.
Там, в основном, разные функции с постфиксом _P прямо в коде встречаются (копирование строки, памяти и т.д) - как я понимаю, это чисто AVR-специфичные вещи для работы с flash.
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
Там, в основном, разные функции с постфиксом _P прямо в коде встречаются
еще раз: они все упрятаны в условную компиляцию по макросу PLACE_CONST_IN_FLASH - если его заремарить, все будет только через ОЗУ, и эти функции_P не будут компилироваться.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
WiseLord, вот архив, в котором должно автоматически убираться все, что только для AVR предназначено (используется defined(__arm__) - вроде так в arm-gcc определено). только я пока не знаю, как быть с портами для ЖКИ и USART-ом, а так же с EEPROM... поэтому функции работы с EEPROM просто заблокировал, а переменные в EPROM сделал в RAM. а вот вывод - это я не знаю, как делать... для USART по идее самое простое должно быть - сами сделаете?
спасибо за тестирование! но было бы просто замечательно, если бы вы все-таки под stm32 тоже терминальный вариант собрали бы... если в GCC под ARM концепция стандартного ввода-вывода такая же, как и в avr-libc, то должно быть это просто: проинициализировать UART и определить функцию вывода байта... в самом простом случае...
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Это я попробую... Сейчас пинцетом на PC0..PC5 позамыкал - работает. Правда, пришлось маску порта C на 0x3F поменять - не знаю, зачем там 6-й бит был задействован, но мне мешало, на кнопки не реагировало. Тем более, что у ATmega328p PC6/PC7 недоступны - там только АЦП на их месте.
заодно пооветуйте, что концептуально надо изменить или переделать в плане того, чтобы адаптация к разным платформам проходила наиболее просто? у вас же опыта в этом больше, я ж кроме AVR ничего не применяю...
Добавлено after 1 minute 13 seconds: допустим, eeprom считывание и сохранение я точно вынесу в платформозависимый модуль... или как-то так сделаю...
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Пока не знаю. Когда займусь - возможно, идеи появятся.
А по поводу eeprom я подумал, написать аналог какой-то аналог eeprom_update_page, который бы пробрасывал параметры в мою имплементацию эмуляции eeprom-а для STM32
По сути, всё что нужно - это вызовы: void eeUpdateRaw(uint16_t cell, uint16_t data); - сохраняет данные data в ячейку cell uint16_t eeReadRaw(uint16_t cell); - читает данные из ячейки cell
Всё остальное делается внутри eemul.c и от этого можно абстрагироваться.
Использование эмулятора максимально простое, типа:
uint16_t read_value = eeReadRaw(PARAM_1); // считается 34;
А если данные больше 16 бит, то придётся для такой переменной заводить два индекса сразу. Типа PARAM_DATA_H, PARAM_DATA_L, и писать/читать подвухбайтно. Просто это ограничения самой STM32 в плане записи flash - записать одновременно можно 2 байта
Добавлено after 4 minutes 18 seconds: А по поводу доработки кода... Я бы посоветовал завести репозиторий на Github (можно просто "форкнуть" то, что у меня получилось) и работать уже с этим кодом, периодически закидывая наработки. Тогда можно было бы параллельно что-то делать с одним и тем же кодом. Это лучше, чем постоянно перебрасываться архивами.
ок, если остальные мои штуки заработают на ARM, сделаю интерфейс EEPROM "выносным", чтобы обертка была прописана, а реализация - внешняя. интерфейс ваш возьму за основу лишь бы все мои выкрутасы со структурами были совестимыми... все эти выравнивания и т.п. - я от этого далёк...
Добавлено after 1 minute 26 seconds: для ARM, скорее всего, нет смысла пункты меню делить на uint8_t и uint16_t - вряд ли экономия 1 байта важна...
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Ещё одно предложение по меню. При его формировании вместо самой строки с текстом вносить некий индекс.
При выводе меню, соответственно, брать не текст, а вызывать функцию, возвращающую текст по этому индексу.
Самая простая реализация такой функции - это просто вывод строки из массива таких строк. Более сложная, по желанию, может, учитывая настройки, выводить текст на другом языке и т.д.
А ещё один плюс - эти же строки в массиве, доступные по индексу, можно будет выводить не только из меню, но и на других "экранах" проекта.
Единственное, что у меня в labels.h подключены другие файлы проекта - но это просто для синхронизации enum-ов самих Labels и других подсистем. Сейчас я от этого пытаюсь уйти.
Ещё один плюс - в разных подменю могут быть пункты с одинаковым именем. Здесь можно будет использовать один и тот же индекс вместо фактически разных строк. Хотя компиляторы сейчас умные, и такое сами могут оптимизировать (схлопнуть до одной константной строки в flash).
AVR. Я понимаю, что ты потратил время и усилия на создание своего меню. А тут видите ли я лезу тут с грязными сапогами к вашему детищу. Выдохни. Всестороннее обсуждение. Итак. В MicroMenu нет сущности submenu. Лично я посчитал это скорее достоинством. Как я уже писал, по сути меню конечный автомат в явном виде. Количество состояний конечно. Древовидное меню или какое угодно, это не важно. Сама суть меню конечна. Будет ли это индекс, или адрес во flash не суть. Почему submenu появилoсь в вашем проекте? В свое время я изучал как меню устроено в DOS, системах мультизагрузки. Что то ещё смотрел, лень вспоминать и перечислять. И пришёл к такому выводу. По сути нужен парсер. В этом случае было бы вообще чудесно...
потому что логически это более понятно. меню - это интерфейс с пользователем. пользователь - в общем случае не программист, поэтому ему надо оперировать понятными терминами. в винде меню состоит именно из главного меню и субменю (подменю). иногда говорят о дочерних меню, но мне больше нравится именно термин подменю. вот я его и использую.
Demiurg писал(а):
В этом случае было бы вообще чудесно
еще более чудесно было бы, если бы вы все-таки вникли в суть того, что я сделал, а не судили бы об этом исключительно по придуманным вами вещам. вы постоянно противопоставляете мой вариант и MicroMenu - почему? между ними НЕТ разницы! оба варианта построены на СВЯЗНЫХ СПИСКАХ пунктов. навигация по этим спискам тоже одинакова. в чем вы видите разницу?
опыт показал, что у меня получился переносимый код. я его немного подчищу-причешу, чтобы мультипатформеность была еще более удобной, и дело будет сделано. предположу, что и разными компиляторами этот код соберется. помнится, это было одним из ваших требований к меню "по-взрослому"? теперь парсер какой-то выдвигается? это без меня.
WiseLord писал(а):
Ещё одно предложение по меню. При его формировании вместо самой строки с текстом вносить некий индекс. При выводе меню, соответственно, брать не текст, а вызывать функцию, возвращающую текст по этому индексу. Самая простая реализация такой функции - это просто вывод строки из массива таких строк. Более сложная, по желанию, может, учитывая настройки, выводить текст на другом языке и т.д.
тут ведь вот какая загогулина получается... изначально идея была именно в том, чтобы сделать описание меню простым: все собрать в один макрос и, при необходимости что-то поправить, делать это в одном месте, не лазя по файлам и не скролля текст. предлагаемый вами вариант фактически возвращает нас к исходной точке: все расползается... при вынесении строк в отдельные массивы уже теряется та прозрачность, которая достигается в текщем подходе, ведь использование строки не в виде ясной константы, а в виде какого-то идентификатора или того хуже - индексного обращения к массиву, - сделает код менее удобным... так что я даже не знаю, насколько это целесообразно. технически - возможно, но логически - не уверен, что будет хорошо...
Добавлено after 24 minutes 43 seconds:
WiseLord писал(а):
в разных подменю могут быть пункты с одинаковым именем
интересно, зачем? как-то это не логично... WiseLord, а вот в порядке необязательной дискуссии: с какой целью вы решили сделать многоязычный интерфейс? я некоторое время назад был поглощен проблемой многоязычного интерфейса в программах для винды... городил сложные системы изменения интерфейса "на лету"... но потом, после размышлений, пришел к выводу, что это совершенно лишнее: язык интерфейса выбирается всегда только 1 раз. предположим, для серийного изделия большого тиража, распространяемого в разных странах, какой-то смысл в возможноти выбора интерфейса есть... но для любительских конструкций, имхо, достаточно сделать выбор языка на этапе компиляции, и все.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
с какой целью вы решили сделать многоязычный интерфейс?
Чтобы уменьшить количество генерируемых прошивок при очередном релизе.
В предыдущей версии проекта того же анализатора спектра мультиязычность достигалась наличием разных файлов eeprom, в которых хранились текстовые метки. В STM32 с eeprom ситуация сложнее, поэтому и решил сделать способ выборя языка через меню.
Плюс этот способ в принципе легко переделывается назад в вариант с одним языком, если вдруг упрусь в размер flash и понадобится способ как-то подрезать размер прошивки.
Ну и опять же - раздельные текстовые метки можно использовать не только в меню, но и проще "расшаривать" на другие экраны. Ведь проект не только из меню состоит.
Мне пока трудно судить о вашем проекте в полном объёме. Для примера, проект с easyelectronics.ru я перематерился, но перенёс на IAR. В WINAVR Я никогда не работал, даже не знаю как его ставить, настраивать и тем более, как составлять makefile. Попробовал запустить в AVR Toolchain, оказывается у вас зависимость от версии. Что нужно мне, на примере chipenable.ru архивы проектов собранные для разных компиляторов. Считаю, что подход этого автора более дружелюбен. Скачал проект под IAR, тут же обкатал его. Итак, чтобы оценить ваш проект. IAR, МК, к примеру, ATMEGA32A. Скомпилированный рхив для LCD (при этом без опроса флага готовности) , архив для терминала. Это не моя личная хотелка. Именно такой подход охватит бОльшую аудиторию.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 46
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения