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

[ARV]

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

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

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

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

имхо

[Dimon456]

В основном модуле у меня только вот это

Спойлер

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

        menu = Menu_GetCurrentMenu();

        id = menu->id;

        if(id) proc_device(id);

К каждому пункту меню привязан свой идентификатор id, к каждому id привязана своя функция.
Последнюю можно было бы заменить на это

Спойлер

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

        switch(id)
        {
        case setting_enter:
           settings_enter();
              break;
        case calibrations_devices:
           Calibrations_Devices();
              break;
        case calibration_voltmeter:
           Calibration_Voltmeter();
              break;

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

Спойлер

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

#define STATE(name, func) name
#include "func.h"
#undef STATE
  PROC_DEVICE_STATES,
}proc_device_t;

То есть что бы добавить пунктик я должен отредактировать три файла:
в 1 добавить

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

STATE (TIMING,						standard_screen			), 	// время

во 2 написать фукнцию standard_screen()
и самое сложное в 3 файл добавить пункт меню

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

MENU_ITEM(Menu_0_6, Menu_0, NULL_MENU, NULL_MENU, NULL_MENU, TIMING);

Вот тут, ПОЖАЛУЙСТА, покажите как с помощью скрипта линкера добавить этот пункт меню, да еще и на свое место определить?

[ARV]

Я не представляю как с помощью скрипта линкера написать "это"

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

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


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

[Dimon456]

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

Спойлер

[ARV]

я бы не отказался от вашего скрипта

ну так в Digiscript все есть! И скрипт, и заголовки, и применение!

[Demiurg]

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

device.jpg

(126.1 КБ) 258 скачиваний

[Dimon456]

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

[Dimon456]

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

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

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

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

[Demiurg]

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

[ARV]

Так вот, уважаемые, высокоинтеллектуальные программисты

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

ваше высказывание

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

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

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

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

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

как вы поступаете при традиционном подходе? описваете структуру этого самого повторяющегося элемента, заводите массив из таких структур... так же, да? и вот затем вопрос: поскольку выгодно иметь статический вариант этих данных (для экономии ОЗУ, в первую очередь актуально для AVR и т.п. маленьких платформ), то и инициализация этого массива должна выполняться статически, т.е. на этапе компиляции. как известно, в Си статическая инициализация массива делается в момент его описания, т.е. как-то так

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

my_data_struct_t my_array[DATA_COUNT] = {
  // и тут многократно повторенные инициализаторы наших-ваших данных
};

вроде все просто и понятно, но ведь ваши данные (см. условие) вам нужны В РАЗНЫХ местах кода! и по ходу пьесы может возникать ситуация, когда количество этих данных будет меняться - вам пришла в голову очередная идея и вы решили добавить парочку таких структур. что же получается? описание статического массива может быть только в одном месте, а это неудобно, поскольку заранее неизвестно, сколько именно таких структур будет надо, и где они будут требоваться. начинается чехарда с включением заголовочных файлов, с корректировкой констант, с дополнением инициализатора массива... все это не сложно, но, имхо, очень муторно.

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

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

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

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

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

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

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

что касается второй части ваших идей

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

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

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

нашел себе оправдание я вот тоже на даче

[lizard66]

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

[bezobraznic]

[uquote="lizard66",url="/forum/viewtopic.php?p=3886749#p3886749"]Выдержал паузу, в надежде, что все камни уже брошены и давно приземлились…
Хотел показать менюху, которую делал для своего сатфайндера, этот код на асме, но если кто то хочет сломать мозг, могу выложить. Ща неторопливо пробую повторить тоже самое на С и для stm32, но показывать пока нечего.[/uquote]

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

[sunjob]

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

[lizard66]

[uquote="sunjob",url="/forum/viewtopic.php?p=4017645#p4017645"]lizard66, а в чем "хитрость" реализации кнопок LEFT / RIGHT - в разрыв? (я не в тяму с "симуляторами")[/uquote]
Линия "KBD" - общая для всех клавиш, подключена на 18й пин М8

[sunjob]

понял, спасибо

[Dimon456]

то сделать это, естественно, можно, но это будет лишь поводом для очередного "фу, не решает мою проблему",

Попытался я создать этот, "фу, не решает мою проблему", велосипед

Спойлер

Поле состоит из 100 на 100 элементов, и 100 пунктов меню.
Управление

Правая кнопка мыши создает пункт меню,
щелчок левой кнопкой мыши по "Ключевому полю" стирает пункт меню.
Поел "Name" не редактируемый параметр.
Чтобы создать переход, нужно щелкнуть мышкой, к примеру, поле "Next" и "Ключевой поле" пункта меню.
Перемещения всего поля клавишами управления курсором.
Все созданные файлы располагаются в папке с программой.

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

На выходе создается файл с содержимым

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

// Menus	Name	| Next	| Prev	| Parent	| Child	| SelectFunction
MENU_ITEM(m_0, m_1, null_menu, null_menu, null_menu, SETTINGS);	// SETTINGS
MENU_ITEM(m_1, m_2, m_0, m_6, m_9, SET1);	// SET1
MENU_ITEM(m_2, null_menu, m_0, m_3, m_2, SET2);	// SET2
MENU_ITEM(m_3, null_menu, null_menu, m_4, m_2, SET2_1);	// SET2_1
MENU_ITEM(m_4, null_menu, null_menu, m_5, m_3, SET2_2);	// SET2_2
MENU_ITEM(m_5, null_menu, null_menu, m_2, m_4, SET2_3);	// SET2_3
MENU_ITEM(m_6, null_menu, null_menu, m_7, m_1, SET1_1);	// SET1_1
MENU_ITEM(m_7, null_menu, null_menu, m_8, m_6, SET1_2);	// SET1_2
MENU_ITEM(m_8, null_menu, null_menu, m_9, m_7, SET1_3);	// SET1_3
MENU_ITEM(m_9, null_menu, null_menu, m_1, m_8, SET1_4);	// SET1_4

Сама программа

[ARV]

не работает

[Dimon456]

Все работает.
Проверено на двух компах, включая и виртуалку.
На одном компе win7 64, из компиляторов установлен только gcc_arm, инета ни разу не видел, даже антивируса нету.
На виртуалке winxp, даже дрова не стоят, виртуалка хоть инет видела.