mr-x (09.02.2026 11:17, просмотров: 2965)-
- Ваш вопрос касается модуляризации программы для устройства с
несколькими режимами (до десятка), где в каждом режиме по-разному
обрабатываются клавиатура, индикатор, внешние интерфейсы, АЦП, звук
и т.д. Это классическая задача в embedded-программировании или
системном дизайне, где нужно балансировать между повторяемостью
кода, удобством поддержки и производительностью. Бoмж(5937 знак., 09.02.2026 21:50)
- Спасибо. - mr-x(10.02.2026 13:05)
- если я тебя правильно понял LordN(82 знак., 09.02.2026 17:29, картинка)
- Хе, хе. В реальности совсем не так, больше похоже на клубок. Не
понятно, что есть селектор и коммутатор, ведь данные разнородны и
асинхронны. Помимо вопроса как ходят данные есть ещё интересный
вопрос, кто, когда и от кого получает управление. Исходный вопрос
был скорее про то, писать ли в одном месте функционал с разбиением
на режимы, или режимы, с разделением по функционалу. Понимаю, что
сумбурно изъясняюсь, прошу пардону. - mr-x(10.02.2026 12:56)
- опять же, если я правильно понимаю, то надо сперва произвести декомпозицию/разбиение задачи на какие-то достаточно независимые элементали. LordN(324 знак., 10.02.2026 14:09)
- именно так.... - Лaгyнoв(09.02.2026 20:52)
- Хе, хе. В реальности совсем не так, больше похоже на клубок. Не
понятно, что есть селектор и коммутатор, ведь данные разнородны и
асинхронны. Помимо вопроса как ходят данные есть ещё интересный
вопрос, кто, когда и от кого получает управление. Исходный вопрос
был скорее про то, писать ли в одном месте функционал с разбиением
на режимы, или режимы, с разделением по функционалу. Понимаю, что
сумбурно изъясняюсь, прошу пардону. - mr-x(10.02.2026 12:56)
- Программу разбивал бы в точности как и "раньше". Модуль "стратегия"
импортирует из модуля "режим" настройки, а все остальное ничего ни
о стратегии, ни о режиме не знают. - Cкpипaч(09.02.2026 17:08)
- И вообще, проектировать нужно сверух вниз. И "высокие" абстракции изолировать не менее важно чем "низкие". - Cкpипaч(09.02.2026 22:12)
- у меня фриртос. есть модуль клавиатуры, который генерит коды(аналог
клавы ПС) есть обработчик кодов, есть модуль индикации. Все режимы
запускаются в обработчике кодов. Каждый режим сам может принимать
коды от клавиатуры, при этом обработчик кодов ждет возврата из
режима. - abivan(09.02.2026 15:24)
- Спасибо. - mr-x(09.02.2026 15:56)
- Могу только догадываться, что каждый режим - это список какой-то функциональности. =AlexD=(135 знак., 09.02.2026 14:45)
- Зачем мешаете ортогональные понятия в одну кучу, теплое с мягким? Хотите в каждом модуле режима 1, 2 и т.д. писать модули индикатора, клавиатуры и прочее? Чтобы файлов было меньше? Ну да, их станет меньше :-) il-2(243 знак., 09.02.2026 13:46)
- Такие разговоры хорошо вести с ИИ. Уж в этих делах он не одну
собаку съел, а тысячу, если не миллион. - SciFi(09.02.2026 12:49)
- Всё хорошо он пишет, всё правильно. Но счастия не добавляет. Нет такого решения, чтобы раз, и всё. Ну что ж, будем прозябать и далее. - mr-x(09.02.2026 13:47)
- Не доверяю я теперь железному болвану. Уж сколько раз меня обманывал. Тем более не хочется обсуждать с ним представление о прекрасном. Но попробую. - mr-x(09.02.2026 13:20)
- Нарисовать функциональный граф с временами реакций,
взаимодействием, потоками данных в разных режимах, если сильно
отличаются. Затем делить сложность до уровня, чтоб удобнее
разбираться в отдельных файлах. - jlm(09.02.2026 12:49)
- С функционированием проблем нет, с реакцией тоже всё в порядке. А вот файлов в проекте много, задрало то, что куча времени тратится на попытки понять, чего нахреноверчено и где это искать. Хочется красоты и изящества. - mr-x(09.02.2026 13:18)
- (совершенно не претендую на истину). У меня как раз все эти работы и события, и режимы. В бесконечном цикле идут функции - что там нажали, не поменять ли индикацию, не прислали что-то по UART, не сменился ли режим отпуска топлива и проч. Внутри функций - по режимам. Может не надо выводить индикацию по отпущенному топливу, если клиент в режиме настройки? Ну и т.д. - Лaгyнoв(09.02.2026 12:31)
- Я конечно не программист, но я бы кое-что совместил: в HAL вынести
общую логику работы "железа", а остальное поделить на независимые
функциональные модули, которые можно отлаживать по-отдельности друг
от друга. - reZident(09.02.2026 11:20)
- Про низкий уровень понятно. Для примера клавиатура. Есть отдельный
модуль, который обрабатывает кнопки и родит флаги событий, это
низкий уровень. В разных режимах кнопки работают по разному,
поэтому можно обработку кнопок уровнем повыше вынести в модуль
клавиатуры для всех режимов, или растолкать функции работы с
клавиатурой по модулям режимов. Вот в чём вопрос. - mr-x(09.02.2026 11:26)
- У меня нажатия и таймер генерируют события, а уж события
обрабатываются в зависимости от актуального режима VLLV(1 знак., 09.02.2026 16:15, картинка)
- Понятно, спасибо. - mr-x(10.02.2026 12:23)
- ага - Лaгyнoв(09.02.2026 20:53)
- Много кнопок в устройстве? Если объединять, то возможно придется
зарядить полный функционал: устранение дребезга, нажатие, отжатие,
длительность нажатия, сочетание нажатий, e.t.c. Зато все в одном
месте и все можно отладить чохом. - reZident(09.02.2026 12:41)
- Кнопок 8 штук. Дребезг, нажатие, длительные нажатия, автоповтор,
задержка автоповтора - в отдельном модуле. Там всё хорошо написано
и хорошо работает. Дело в том, что если растащить обработку событий
от клавиатуры по модулям режимов, то схожий клавиатурный функционал
будет растащен по куче мест в программе, что противно. А если
затолкать всё клавиатурное в одно место, то там вроде всё красиво,
но тогда специфика режимов размазана по программе. Всё работает, но
как-то неловко. mr-x(64 знак., 09.02.2026 13:14)
- "Работает? Не трожь!" (с) любой админ :-) - reZident(09.02.2026 13:23)
- Кнопок 8 штук. Дребезг, нажатие, длительные нажатия, автоповтор,
задержка автоповтора - в отдельном модуле. Там всё хорошо написано
и хорошо работает. Дело в том, что если растащить обработку событий
от клавиатуры по модулям режимов, то схожий клавиатурный функционал
будет растащен по куче мест в программе, что противно. А если
затолкать всё клавиатурное в одно место, то там вроде всё красиво,
но тогда специфика режимов размазана по программе. Всё работает, но
как-то неловко. mr-x(64 знак., 09.02.2026 13:14)
- у меня по кнопкам. А внутри обработки кнопки - разные действия по
режимам - Лaгyнoв(09.02.2026 12:36)
- Понятно, спасибо. - mr-x(09.02.2026 12:47)
- Разбивайте по рабочим режимам. Которые будут пользовать ваши
ресурсы(клавиши, индикатор, АЦП итыды). - mse homjak(09.02.2026 12:00)
- Спасибо. - mr-x(09.02.2026 12:47)
- У меня нажатия и таймер генерируют события, а уж события
обрабатываются в зависимости от актуального режима VLLV(1 знак., 09.02.2026 16:15, картинка)
- Про низкий уровень понятно. Для примера клавиатура. Есть отдельный
модуль, который обрабатывает кнопки и родит флаги событий, это
низкий уровень. В разных режимах кнопки работают по разному,
поэтому можно обработку кнопок уровнем повыше вынести в модуль
клавиатуры для всех режимов, или растолкать функции работы с
клавиатурой по модулям режимов. Вот в чём вопрос. - mr-x(09.02.2026 11:26)
- Ваш вопрос касается модуляризации программы для устройства с
несколькими режимами (до десятка), где в каждом режиме по-разному
обрабатываются клавиатура, индикатор, внешние интерфейсы, АЦП, звук
и т.д. Это классическая задача в embedded-программировании или
системном дизайне, где нужно балансировать между повторяемостью
кода, удобством поддержки и производительностью. Бoмж(5937 знак., 09.02.2026 21:50)
