Средства и методы разработки

Какие есть возможности разбить приложение на 2 части: ядро и алгоритм+настройки? Используется ЙарСи. В ядре реализованы интерфейсы и их буферы приёма-передачи, полный набор расчётных и управляющих функций (алгоритмов), возможно RTOS. Размер ядра >200Кбайт. Перепрошивка ядра должна быть однократной, только при изготовлении. В настройке - настраиваемые параметры и программа, отвечающая за функционал. Создаётсся автоматически исходя из схемы/конфигурации оборудования (например, задаётся число и назначение входов и выходов). Также задаётся последовательность выполнения функций, например: 1) прочитать состояние входа №1 2) проверить сигнал на дребезг в течении 3 с. 3) если вход №1 = 1, то сформировать на выходе импульс длительностью 30 с. Ядро поочерёдно для каждой функции подготавливает набор переменных, вызывает функцию и сохраняет результаты её работы. Размер настройки не более 4Кбайт. Перепрошивка - частое явление при настройке и ремонте (например, замена сгоревшего входа на соседний рабочий). Сделали в режиме интерператора, в результате чего скорость обработки уменьшилась в 20-30 раз, что неприемлимо. Вопрос: Как грамотно организовать взаимодействие ядра и части настройка+алгоритм? Вариант 1: Реализовать общую область памяти (по аналогии с двухпортовой) для обмена параметрами, но тогда нужно - или автоматически считывать физические адреса переменных из map-файла. Как быть, если потребуется добавить временную переменную?; - или ухитриться их задать в Xcl файле, что их при количестве в несколько сотен уже весьма проблематично. - или добавить операции чтения-записи в промежуточную область память по фиксированным адресам. При этом сразу же возникают дополнительные временные задержки, т.к. данные могут быть не только 8, 16, 32 разряда (chat, int, float), но ещё и типа "структура" произвольной длины. Вариант 2: обновлять прошивку целиком - крайне нежелателен. Причина 1: полный доступ к исходникам + риск внесения в ядро труднообнаружимых ошибок настройщиками, при их низкой квалификации и сложности определения ответственного за изменения. Причина 2: низкоскоростной канал и длительное время обновления полной прошивки при высоких помехах и интенсивно используемом другим оборудованием канале. В результате время простоя оборудования из-за обновления прошивки зависит от её размера (квадратичная зависимость)