Обсуждаем контроллеры компании Atmel.
Ответить

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

Пт авг 21, 2020 09:56:46

А в чем сакральный смысл наличия бита готовности, если можно по задержкам?

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

Что практичнее?

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

Пт авг 21, 2020 12:09:41

ARV, я даже и не думал что так будет работать

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

Пт авг 21, 2020 12:33:34

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

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

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

после того, как я освоил правку секций скрипта линкера (ну, как освоил: кой-чего могу делать), я сделал для себя несколько модулей (и в Digiscript активно применял), которые позволяют полностью децентрализовать все то, что раньше было обязано быть централизованным. и во многих случаях это СИЛЬНО УПРОЩАЕТ написание программы - когда голова не болит о том, что каждую новую функцию надо увязать в общий список других аналогичных (потому что все делается "само по себе") - это удобно.

имхо

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

Пт авг 21, 2020 14:25:10

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

То есть что бы добавить пунктик я должен отредактировать три файла:
в 1 добавить
Код:
STATE (TIMING,                  standard_screen         ),    // время
во 2 написать фукнцию standard_screen()
и самое сложное в 3 файл добавить пункт меню
Код:
MENU_ITEM(Menu_0_6, Menu_0, NULL_MENU, NULL_MENU, NULL_MENU, TIMING);
Вот тут, ПОЖАЛУЙСТА, покажите как с помощью скрипта линкера добавить этот пункт меню, да еще и на свое место определить?

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

Пт авг 21, 2020 15:10:48

Dimon456 писал(а):Я не представляю как с помощью скрипта линкера написать "это"
как - вы можете посмотреть в моём проекте Digiscript, который вы, как я в курсе, неплохо освоили. я не уверен, что при вашем подходе мой подойдет на 100%, но как идею для дальнейших размышлений можете использовать.

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


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

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

Пт авг 21, 2020 19:32:14

ARV, я бы не отказался от вашего скрипта.
А пока вот мое видео как это работает

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

Пт авг 21, 2020 19:49:08

Dimon456 писал(а):я бы не отказался от вашего скрипта
ну так в Digiscript все есть! И скрипт, и заголовки, и применение!

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

Пт авг 21, 2020 20:06:47

ARV, не тебе.
Застрелиться и не встать. Без обид. Даже учитывая на видео нечитаемый код, у меня уже волосы дыбом встали. Конечно, можно взять расческу, и причесать волосы обратно (@ЛИ (Ридико Леонид Иванович)). Но. Давайте возьмем за пример один действующий прибор. Это пластиковая коробка. Прозрачная передняя стенка. Сенсорные кнопки. Меню... Ни хрена не поддается вменяемому структурированию. Так как кнопки сенсорные, блок может залить дождем, туман, утренняя роса. 10 нажатий. 20 нажатий. Чтобы войти в сервисные настройки. Традиционное программирование идет лесом. Все массивы, как любят начинающие менюшки упрощать, идут лесом. Только автоматы. Этот проект я слил. Заказчик неадекватный попался. До меня было порядочно претендентов. Но, я единственный, кто хоть как-то структурно довел проект до работоспособности. Помню, пришел студент, увидел мои конечные автоматы и X-Macro. И это у него был полный разрыв шаблона. Там такая истерика была... Я этому студенту много чего дал. В ответ увидел махровую неблагодарность. Скажу честно, тогда я подумал, да что б хоть еще одному студентику что-то обьяснял и показывал... Позже отошел...
Аналог устройства на фото.
device.jpg
(126.1 KiB) Скачиваний: 137
Последний раз редактировалось Demiurg Сб авг 22, 2020 08:39:06, всего редактировалось 1 раз.

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

Пт авг 21, 2020 20:54:43

Ну вы даете, что первоначальный вариант показать?
Какие будут ваши предложения?

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

Сб авг 22, 2020 09:06:21

ИзображениеПоходу дела предложений не будет, ни от одного ни от другого.

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

Demiurg, ваше фото прибора оказалось наиболее полезным, да же лучше чем скрипт линкера ARV.

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

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

Сб авг 22, 2020 10:20:22

Вообще то я на даче...

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

Сб авг 22, 2020 10:29:55

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

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

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

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

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

как вы поступаете при традиционном подходе? описваете структуру этого самого повторяющегося элемента, заводите массив из таких структур... так же, да? и вот затем вопрос: поскольку выгодно иметь статический вариант этих данных (для экономии ОЗУ, в первую очередь актуально для AVR и т.п. маленьких платформ), то и инициализация этого массива должна выполняться статически, т.е. на этапе компиляции. как известно, в Си статическая инициализация массива делается в момент его описания, т.е. как-то так
Код:
my_data_struct_t my_array[DATA_COUNT] = {
  // и тут многократно повторенные инициализаторы наших-ваших данных
};
вроде все просто и понятно, но ведь ваши данные (см. условие) вам нужны В РАЗНЫХ местах кода! и по ходу пьесы может возникать ситуация, когда количество этих данных будет меняться - вам пришла в голову очередная идея и вы решили добавить парочку таких структур. что же получается? описание статического массива может быть только в одном месте, а это неудобно, поскольку заранее неизвестно, сколько именно таких структур будет надо, и где они будут требоваться. начинается чехарда с включением заголовочных файлов, с корректировкой констант, с дополнением инициализатора массива... все это не сложно, но, имхо, очень муторно.

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

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

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

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

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

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

как-то так вот.

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

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

Вт сен 01, 2020 22:17:37

Выдержал паузу, в надежде, что все камни уже брошены и давно приземлились…
Хотел показать менюху, которую делал для своего сатфайндера, этот код на асме, но если кто то хочет сломать мозг, могу выложить. Ща неторопливо пробую повторить тоже самое на С и для stm32, но показывать пока нечего.

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

Чт дек 10, 2020 10:43:54

Выдержал паузу, в надежде, что все камни уже брошены и давно приземлились…
Хотел показать менюху, которую делал для своего сатфайндера, этот код на асме, но если кто то хочет сломать мозг, могу выложить. Ща неторопливо пробую повторить тоже самое на С и для stm32, но показывать пока нечего.


Прикольная менюшка! К ней удобно энкодер прикрутить.
Если замутили на С, и не жалко поделиться, буду благодарен!

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

Вс апр 18, 2021 08:56:37

lizard66, а в чем "хитрость" реализации кнопок LEFT / RIGHT - в разрыв? (я не в тяму с "симуляторами")

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

Вс апр 18, 2021 16:53:55

lizard66, а в чем "хитрость" реализации кнопок LEFT / RIGHT - в разрыв? (я не в тяму с "симуляторами")

Линия "KBD" - общая для всех клавиш, подключена на 18й пин М8

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

Вт апр 20, 2021 17:21:42

понял, спасибо
Ответить