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

[NewWriter]

А вот я так думаю, что вначале надо бы все таки как-то систематизировать параметры всех модулей. Как разрабатывать устройство, если неизвестно из чего оно состоит?
Все таки ведь набор параметров ограничен, и во многих модулях они повторяются. Надо найти эти общие параметры.

А как например вот протокол MIDI? На нем ведь многие музыкальные приборчики работают. Там набор параметров уже придуман, расписан в спецификации. Причем, довольно обширный список параметров и их можно назначать любым элементам управления.
В создаваемой системе нужно один раз распределить параметры, и все подключаемые устройства будут использовать их. Либо сделать настраиваемую конфигурацию. чтобы корректировать в случае чегою
PS/. Я делал устройства управления по MIDI, управлял плагинами в муз.редакторе по миди. Вообще нормально всё получалось! просто шикарно даже

[Yurkin2014]

систематизировать параметры всех модулей

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

Для начала всё можно сделать гораздо проще. Модуль имеет любое разумное число параметров. Часть параметров просто ВКЛ/ВЫКЛ. Остальная часть параметров - это число. Думаю, даже одного байта хватит на численное значение параметра. Основной контроллер не парится, что к нему подключено. Он просто на каждое нажатие посылает команды: параметр №5="ВКЛ", параметр №17="134". А модуль уж сам разберётся, что ему включить, а что установить на уровень 134.
Так что делайте любой модуль, составляйте список параметров модуля, когда спросят - отправляйте список на основной контроллер и ждите указаний от него, что куда включить/установить.

[NewWriter]

Но почему же! МИДИ используется даже там, где нет компа. По миди соединяются между собой даже "железные" прибамбасы, а не только плагины. Ведь то, что делает топикстартер, как раз относится к музыкальным приборам. И в его разработке как раз есть те параметры, которые уже систематизированы в миди-протоколе.
Так что лично я - обеими руками и ногами голосую за MIDI!
Тем более, что я сам так делал и у меня получалось! Я описываю то, что у меня реально получилось запустить в железе.

Дело в том, что все эти параметры типа "параметр №5 вкл" уже прописаны в протоколе MIDI. Сообщения NoteOn, NoteOff в основном предназначены для включения и отключения. Номер параметра - это номер ноты. Их 127.
И кроме этого, есть разные типы сообщений. Тип сообщений определяется по старшему полубайту первого байта посылки. Этим фактически еще больше расширяется число параметров управления.
Например, "параметр №17=134" можно передать, используя сообщение Control Change, и у него номер контроллера будет 17 (второй байт), а величина =134 (третий байт). Аа..даа.. Кстати, величина не может быть больше 127. Так принято по протоколу - второй и третий байт содержат 0 в старшем разряде. Но этого хватает для большинства случаев. А если надо большее значение параметра передать, то есть сообщение Pitch Bend Change.
И этот же самый "параметр №17=120" можно передать, используя опять же сообщение NoteOn (NoteOff) благодаря третьему байту в сообщении (Velocity).
Есть еще интересное сообщение Program Change, предназначенное для смены программ в управляемом устройстве. Набор параметров меняется целиком, выбирая из сохраненных в самом устойстве.
Есть 16 независимых миди-каналов с одинаковым количеством всех параметров, управляемых раздельно. То есть, на одну миди-шину можно подключить 16 независимых устройств с одинаковым типом управления.
И это не считая некоторых специфических системных сообщений и сообщений реального времени.
Итого, получаем ооочень большой объем управляемых параметров, которые могут почти свободно использоваться по усмотрению разработчика. Главное, чтобы все подключаемые устройства одинаково понимали наборы параметров.


Все уже придумано было. И неплохо работает в масштабах продаваемых устройств
Позвольте тут подробно не описывать протокол MIDI, интересующиеся найдут и посмотрят - http://www.midi.org/techspecs/midimessages.php#2
Я думаю,очень даже подходит топикстартеру, особенно когда он еще не определился с числом параметров и вообще с тем, как и что передавать.

Например, если любому подключенному устройству передать сообщение от управляющего устройства, например, трехбайтное B0072C, подключенное устройство поймет, что пришло сообщение Control Change об изменении громкости (второй байт, параметр Volume control) до уровня 0х2С (третий байт), на канале 0 (младший полубайт первого байта). И если в подключенном устройстве задумано, что приняв это сообщение на канале 0, будет изменена величина параметра громкости, то все получится.
И в управляющем устройстве на дисплее в нарисованном интерфейсе, если покрутить ручку громкости у преампа, то должно отправляться сообщение B007хх, а преамп, получив это сообщение, однозначно поймет его, даже если управляющее устройство заранее не знает, что к нему был подключен преамп.

PS. И в догонку - еще один плюс за MIDI-протокол - многие фирменные музыкальные устройства, процессоры звука и типа того имеют встроенный протокол MIDI, разъем MIDI и управляются по нему. Взяв миди за основу, топикстартер сможет подключить к своему устройству любой фирменный прибамбас и запросто управлять им со своего тач-скрина.

[Reystlin]

to Easyrider83 именно на этом контроллере и планируется дисплей и именно STM32 я и хотел ставить, правда думал с запасом ресуров поставить STM32f407. но останавливало меня то, что я пытался там использовать динамическую память и у меня не вышло, но основываясь на методе предложенном товарищем Yurkin2014, видимо должно все получиться

to NewWriter Миди также планировалось реализовать для связи со внешними устройствами. идея конечно интересная, но она не совсем подходит т.к. у преампа могут быть такие параметры, которые в стандарте миди не заложены заранее всвязи с их индивидуальностью, к примеру у некоторых преампов есть ручка Sweep, у некоторых есть перключатель Contour и эти параметры индивидуальны именно для этих преампов, где они встречаются и я более чем уверен, что в MIDI Они не описаны, так что в любом случае прийдется как-то информировать основной контроллер о тех параметрах, которые в миди не учтены.
Миди я думал использовать для переключения режимов. т.е. иметь таблицу пресетов в которой для каждого пресета был бы список значений всех параметров
но идея вся пока в процессе формирования, все нюансы пересматриваются, размышляю как ичто лучше реализовать.

[NewWriter]

Ой, дак в миди большинство параметров - свободно назначаемые. Например, у сообщений NoteOn, NoteOff, Aftertouch свобода назначений вообще не ограничена. 127х3=381 параметр для каждого канала. И разве не хватит??? Для ручки Sweep бери любое сообщение, например, 9001xx, где xx - величина поворота ручки (от 0 до 127). Либо сообщение B010xx - General Purpose Controller 1.
Для включения переключателя Contour возьми сообщение например 90027F, а для выключения - 80027F. Либо, включение - 90027F, а выключение 900200.
Ну я ж делал - вообще управлял произвольными плагинами с вообще фиг знает каким набором параметров - и ниче, все работало.
Главное, если планируешь связь с внешними сторонними миди-приборами, придерживайся общих рекомендаций протокола. Например, MainVolume канала - сообщение Bn07xx, где n - номер канала, хх - значение громкости. Ну и резервированные сообщения (Bn78xx - Bn7Fxx) не занимай.
Программы переключаются двухбайтными сообщениями Cnxx, n - номер канала, хх - номер программы от 0 до 127.
Устройства, которые будут подключаться, оснасти джамперами или DIP-переключателями типа DS1040-04 для выбора канала, либо жестко пропиши канал ему, либо сделай назначение каналов из главного МК по принципу "следующего свободного канала".
В принципе, каналы назначать не обязательно, можно все оставить в одном канале, а выбирать только номера параметров, благо их много.
Сделай основной контроллер с настройкой, какое сообщение формируется в ответ на изменение какого параметра. Или сделай выборочную настройку в подключаемых устройстах.
Создай в основном управляющем устройстве базовые элементы управления - кнопки, крутилки, движки. Присвой им типы сообщений. То есть, кнопкам - сообщения NoteOn, крутилкам и движкам - сообщения Control Change. И сделай для них выбор номера параметра. Потом уже в процессе создания плат, которыми управлять будешь, подкорректируешь номера параметров, задашь им имена. Кстати, по MIDI может передаваться инфа о подключенном устройстве в составе системных эксклюзивных сообщений.
Ну и вообще, я ж говорю, постарайся сразу определиться с тем, что и как будет там. Хотябы на уровне блок-схем.

Ты просто до конца не понял суть миди-протокола. Так то вполне он нормальный. Че мучиться изобретать то, все уже изобретено же.
По крайней мере, это лучше, чем изобретать какой-то доступ по шине дисплея с каждого подключаемого устройства или делать динамическую память.
На физическом уровне MIDI - это UART со скоростью 31250 бод. Для связи с внешними устройствами, если по хорошему, то применяется опторазвязка - выход работает на светодиод (который установлен в приемном устройстве), на входе - транзистор оптопары.

[Yurkin2014]

обеими руками и ногами голосую за MIDI!

Спору нет. MIDI хорош для Роланда и Корга. И топикстартеру сгодился бы, если главное управление будет с компа.

Но тут другой случай. Управление от микропросессора с маленьким LCD. Что делать, когда ТС сваяет новый модуль? Придётся переписывать программу основного контроллера - добавлять новые экранные интерфейсы управления этим модулем, назначать MIDI сообщения для этого нового модуля, ДИП-переключатели опять же надо помнить, чтобы не пересекались с предыдущими модулями.
И так с каждым новым. В конце концов, получится гигантская программа, которая помнит о всех модулях, когда-либо подключавшихся, и может давно уже снятых с производства. Память контроллера не резиновая и скоро кончится.
И потом, такая это морока, когда захочешь добавить одну единственную кнопку-параметр в уже существующий интерфейс: это снова поднимать программу главного контроллера, находить место, где описывается экран данного модуля, изменять расположение кнопок, отыскивать новые свободные MIDI-сообщения, компилировать-прошивать и т.д.

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

Я с MIDI дело не имел, поэтому главный вопрос - реально ли на его основе сделать так: разработали-спаяли новый модуль фуз-ревербератор REYSTLIN-2100, воткнули в систему, аудио в аудио, MIDI в MIDI, и сказали: "Управляй мной!"? Или контроллер пошлёт подальше, типа, кто такой этот Рейстлин, знать - не знаю. Давай плагин, тогда смогу?

[Reystlin]

to Yurkin2014 именно в этом и есть основная задумка

на данный момент мне видится все вот так, объединив предложение от Yurkin2014 и от NewWriter:
основной МК в момент перехода в настройки модуля опрашивает модуль, на что он ему отвечают какие у них параметры в виде [тип, название, расположение, номер MIDI команды].
при получении такой команды МК в заранее выделенной памяти размещает параметры всех элементов.
при изменении параметра происходит отправка MIDI сообщения модулю с указанием номера команды за которой закреплен этот параметр и с новым значением

[NewWriter]

поэтому главный вопрос - реально ли на его основе сделать так: разработали-спаяли новый модуль фуз-ревербератор REYSTLIN-2100, воткнули в систему, аудио в аудио, MIDI в MIDI, и сказали: "Управляй мной!"? Или контроллер пошлёт подальше, типа, кто такой этот Рейстлин, знать - не знаю

Я когда делал сам, перечитал по этой теме кучу инфы и смотрел, как это делается в фирменных устройствах. (и пробовал так же подключаться к ним - нормально). У них во-первых основные функции управления одинаковы по передаваемым сообщениям и имеют одинаковые (ну или похожие) органы управления, благодаря чему устроства разных фирм понимают друг друга. А во-вторых, управляющее устройство имеет возможность настройки элементов управления и сохранения пресета управления. А подключаемое устройство передает информацию о себе в составе системного эксклюзивного сообщения (SysEx, начало сообщения - F0, конец F7, между ними - любое количество байт, у который старший бит =0) и управлялка определяет, что у нему подключено и как управлять, ведь по SysEx может быть передано и то, какие функции как управляются.
Вот тут есть документация по SysEx -
http://www.midi.org/techspecs/ca22.pdf
http://www.midi.org/techspecs/ca24.pdf
Взяв это за основу, можно приспособить под свои задачи.

основной МК в момент перехода в настройки модуля опрашивает модуль, на что он ему отвечают какие у них параметры в виде [тип, название, расположение, номер MIDI команды]. при получении...

примерно так и сделано в некоторых фирменных устройствах.

Новый модуль при подключении сам расскажет главному где какие кнопки-движки.

Ну в принципе, можно и не привязываться к MIDI, а создать что-то свое, если хочется так. Взять физически тот же UART, а протокол обмена придумать самому. А midi оставить только для связи с внешними устройствами.
Я согласен с Yurkin2014 в плане того, что подключаемое устройство должно "рассказать" главному контроллеру о том, какие параметры управления у него есть, а главный контроллер должен отобразить на экране эти параметры в виде набора из стандартных элементов управления - кнопок, движков, крутилок и присвоить им названия те, которые переданы будут от подключенного устройства.
Наверно можно и так. Наверно... Опять же, это касается только расположения и количества элементов управления.

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

[Reystlin]

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

[jump]

Reystlin,
обобщая часть вышесказанного:
- МК должен быть с ОС, видеопримитивами и большим ОЗУ для хранения программ модулей
- модули передают главному МК драйвера общения и виджеты (либо указатели на видеопримитивы, из которых они собраны)
- опрос наличия модулей можно производить двумя способами: программно, с адресацией, и аппаратно, например, "бегущей 1" при наличии 2-х аппаратных выводов МК модуля. кстати, устанавливая ближе-дальше от главного МК модули, можно будет назначать приоритет обслуживания по первенству загрузки драйверов
в результате получится что-то вроде ПК - ОС и подключаемые файлы периферии.