Система с несколькими сменными модулями

[Reystlin]

Доброго времени суток уважаемые форумчане
разрабатываю многомодульный гитарный усилитель с цифровым управлением
для управления будет использоваться сенсорный экран.
столкнулся с проблемой вывода всех параметров модулей на экран
существует 3 тиа модулей,которые одновременно стоят в устройстве(модуль преампа, модуль DSP процессора, модуль эмулятора ачх динамика)
на основной плате есть тоже яд некотоых настроек,которые должны управляться с дисплея.
на каждой плате модуля будет стоять микроконтроллер для управления периферией на этом модуле(в основном это будут реле, переключающие аналоговые цепи обработки, либо управляемые ШИМом куски схем.), с модулем DSP конечно будет посложней.
проблема в том, что у меня контроллер основной платы(который занимается взаимодействием с экраном и сенсором) не в курсе какие элементы управления у вставленных в него модулей
засунуть в него сразу таблицу всех модулей со всеми характеристиками не получается т.к. все модули будут разрабатываться после разработки основной платы.
сделать так, чтобы каждый подключенный модуль говорил что у него за параметры тоже не выходит т.к. для этого в основном контроллере нужно динамическое выделение памяти под элементы интерфейса а куча у контроллеров маловата.
мне видится два варианта:
1. шину дисплея заводить на каждый модуль и при переходе из настроек одного модуля к настрйокм другого просто выдавать приоритет тому или иному модулю для доступа к шине.
2. на каждом модуле ставит простой мк для управления периферией и ещё ставить небольшую флешку, которая бы в себе содержала часть программы для МК на основной плате, при перехое к настройкам этого модуля программа бы считывалась в SRAM основной платы и туда бы передавалось управление

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

у кого какие мысли по поводу реализации данной задачи?
заранее благодарен

[STM32F0]

Блажь а ля Виндовс, со всеми недостатками, как не крути.

А вот и дежавю.

У меня в аппарате несколько независимых систем, выполненных в виде отдельных блоков. Каждый блок – непростой узел. Я поставил в каждом блоке по МК и связал их по SPI.
Думаю, в моей ситуации переход к применению нескольких МК – отличное решение.
1 Резко упростилась написанием программ. Каждый МК занят своей задачей.
2 Резко упростилась доработка и модернизация аппарата.
3 Резко упростилась ремонт – для быстрой диагностики можно легко заменить подозреваемый в дефекте блок.

Обосновываю. Подсознательное стремление к аппаратному "упрощению", стремлению разбивания на модули с МК в каждом из них, узловой конструкции говорит о проблемах с управлением сложностью. При отсутствии методик кодирования проект очень быстро усложняется, и его становится очень сложно модифицировать и поддерживать. Так же если язык не позволяет создавать гибкие системы, которые можно легко собирать "из кубиков" на этапе компиляции, появляется такое стремление выделить под каждую задачу свой контроллер. Эдакая простая "тупо в лоб" модульность. На деле же это несет за собой следующий негатив:
1. Дополнительные аппаратные затраты на связь модулей. Каждый отдельный модуль теперь должен не только реализовывать свой функционал, но и поддерживать модуль связи с остальными модулями. Причем в актуальном состоянии. А это значит что нужно поддерживать протокол обмена в актуальном состоянии на всех модулях сразу. А если будут обновления, то обновления нужно накатывать на все модули. Или сразу делать протокол обмена "на будущее", а это дополнительные ресурсы.
2. Дополнительные затраты человекочасов на поддержку связи всех этих модулей.
3. Эффективность и надежность связи модулем драмматически падает, по сравнению с внутрипроцессорным взаимодействием. А это значит что получаем ограничение возможностей по быстрому и надежному реагированию.
4. Стоимость компонентов (микоконтроллеры, дублирование их обвязки), стоимость печатных плат, размер готового изделия, энергопотребление увеличивается.
Думаю в вашей ситуации переход к многопроцессорному решению это попытка решить проблемы сложности кодирования. Якобы упрощение модернизации вашей системы появилась только из за того, что это позволило отказаться от большого неподдерживаемого проекта на АБ, и прийти к маленьким, более менее поддерживаемых проектам на АБ.

http://forum.easyelectronics.ru/view...ee3b26#p399560

[Reystlin]

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

[Easyrider83]

Очень порочный путь вы придумали. Лучше осваивайте бутлодырь. Главный камень должен уметь прошивать все остальные.

[Reystlin]

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

[Easyrider83]

Пока что хорошо заметно, что вы сами еще не знаете, как и что у вас будет работать. Когда есть четкое ТЗ, таких проблем не возникает.

[Yurkin2014]

Я бы сделал так. Основной контроллер: управляет экраном и воспринимает нажатия на тачскрин. Из него выходят только линии UART: передачи Tx и приём Rx. Основной контроллер - мастер, т.е. он посылает в Tx данные и получает ответ. Модуль может рисовать на экране примитивы графического интерфейса: текст, кнопки, движки регуляторов, поля ввода текста и т.д. Всё.
Все модули вешаются на эту шину UART. Они только слэйвы. Каждый модуль имеет уникальный номер/адрес, например 2 байта. Модули слушают линию Tx. От линии контроллера Rx они отключены. Данные передаются пакетом, т.е. первые 2 байта в пакете - номер модуля. При совпадении адреса какой-то модуль принимает весь пакет, подключается к линии Rx и отвечает мастеру подтвеждением приёма.

Вот такая наша диспозиция.
При включении, после сброса все системы основной контроллер пробегает по всем возможным адресам от 0х0000 до 0хFFFF и определяет, что подключено. При ответе с какого-то адреса котроллер запоминает этот адрес и тут же запрашивает имя модуля. После опроса рисует на экране главное меню, типа, кнопки с именами найденных модулей.
Далее. При нажатии на кнопку с именем в главном меню контроллер очищает экран и по запомненному адресу запрашивает интерфейс модуля.
Модуль отвечает: элементов интерфейса, например, 7.
Главный: какой первый элемент?
Модуль: кнопка с текстом "Частота" и координатами 20,30
Главный: какой второй элемент?
Модуль: ручка-крутилка, min=0, max=50, координаты на экране 100, 30
и т.д.
Получая эти данные и используя готовые графические прмитивы, основной модуль рисует экран управления выбранным модулем.
При нажатии на тачскрин основной модуль отправляет сообщение, типа, элемент номер 5 "нажат". Модуль соответственно своей программе реагирует на нажатие.

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

[Reystlin]

to Easyrider83 поэтому то я и обратился на форум, у меня есть представление какой должен быть результат со стороны пользователя а вот как его внутри реализовать, тут сомнения.

to. Yurkin2014 по сути именно так мне и нужно. основная проблема, мешающая это реализовать, заключается в том, что тогда основному контроллеру нужно использовать операции new или malloc, тобишь динамическое выделение памяти т.к. заранее он не знает сколько элементов управления у того или иного модуля, а вот с динамическим выделением памяти в контроллерах проблемы... я пока ни к какой архитектуре не привязывался, может посоветуете какой МК для основного взять, чтобы нормально получилось реализовать с динамической памятью?

[Yurkin2014]

основная проблема, мешающая это реализовать, ... нужно использовать операции new или malloc

Если проблема, то - не используйте, забудьте про динамическую память.

Сколько элементов управления может поместиться на экране? Пусть 50. Каждый элемент будет иметь параметры, например:
порядковый номер - 1 байт
тип элемента - 1 байт
Положение на экране x,y,width,height - 4 байта
Минимальное значение - ну, пусть 2 байта
Максимальное значение - 2 байта
Ну, и хватит, 10 байт на элемент. В программе объявляете массив в памяти размером 50х10=500 байт, в котором будет хранится информация о текущем интерфейсе. Этого хватит на любой возможный интерфейс. При переключении на другом модуль информация обновится в том же массиве.

посоветуете какой МК для основного взять

любой с ОЗУ от 1кБ и выше

[Easyrider83]

Начнем с того, какой дисплей планируется и на каком интерфейсе собирать? Можно взять проверенную связку STM32F103VC FSMC + SD1289 320x240 и запустить это все на RTOS c GUI. Но кодить придется много, конечно.