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

[Reystlin]

to jump не совсем понимаю как именно будут выглядеть драйвера общения в данном варианте

[jump]

как именно будут выглядеть драйвера

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

[omercury]

каким быть драйверу - ... - выбирать вам

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

[Reystlin]

вся обработка звука будет идти в аналоге
кроме модуля DSP ессно.
преампы ламповые будут
всю обработку звука в цифру переносить не планирую

[omercury]

Тогда о чём разговор?

Есть стандартизированный интерфейс, есть стандартизированный протокол.
Что ещё нужно-то?

[Yurkin2014]

На колу мочало, начинай сначала.

[omercury]

Yurkin2014, Вы можете написать драйверы, чтобы мышь подключалась к видеокарте, а монитор к LPT-порту?

А почему до сих пор себе так не сделали?

[Reystlin]

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

[Yurkin2014]

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

Вот этот массив и будет хранилищем Ваших экземпляров классов. Размер одного экземпляра, например, 10 байтов. По мере опроса модуля о виджетах, Вы заполняете массив с самого начала после каждого сообщения модуля об имеющихся виджетах. Можете называть это созданием экземпляров классов. Все экземляры будут лежать в этом самом массиве.
При получении описания очередного виджета программа посылает контроллеру экрана команды, что рисовать в зависимости от типа виджета. При этом в ОЗУ процессора больше ничего не создаётся, никаких дополнительных экземпляров. Используются подпрограммы вывода на экран: "нарисовать кнопку(x,y,width,height)", "нарисовать RadioButton(x,y,width,height)","написать текст(x,y,text)" и т.д.

не получится отследить нажатия на нем

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

А для начала Вам нужно приобрести STM32F4-Discovery и LCD экранчик, соединить их вместе и вывести на экран "Hello world!".
Пока это не сделано, все обсуждения этого проекта - просто трёп и витание в облаках. Я так думаю.

[Reystlin]

у меня уже есть STM32F103 и LCD с сенсором на который вполне себе выводятся виджеты кнопочек и всего остального так что сие общение уже не треп

т.е. вы предлагаете сделать вот как:
int memory[255];//заранее выделенная область памяти в которую будем создавать экземпляры классов
int shift;//смещение до пустой ячейки
if(...)//если нужно создать кнопку
{
CCButton Button1=(*memory[0]+shift);
shift+=sizeof(CButton);
}