Evgeny_CD, Архитектор (24.05.2013 19:53, просмотров: 88) ответил Лeoнид Ивaнoвич на Синтетическая теория. Различия периферии разных МК заставляют решать задачи совсем разными методами. Какая тут может быть переносимость? И почему переписывать "абсолютно всё"? Работа с периферией - очень маленькая часть кода.
Это сложный вопрос о малости или великости работы с периферией. Вот простой пример "полусинтетического подхода силами C++". Пусть на борту будет некий вычислитель|регулятор, работающий на пределе перфоманса MCU.
Причем он использует свойства конкретного АЦП (например, одновременный семплинг нескольких входов) и свойства конкретного ШИМ. А "посредине" - вычислялка.
Классический подход гворит нам - делаем драйвер АЦП, ШИМ, и вычислялка вызывает их.
Но реурсов может быть мало, посему так может и не влезть.
Пусть мы пишем некий обобщенный класс АЦП, и класс ШИМ. Который описывает интерфейс к АЦП и ШИМ. И пусть будет отдельно реализация вариантов этого интерфейса подж разные контроллеры - синтетический порт (читаем из сокета|пайпа Matlab модели целевого объекта), контролле А, контроллер Б.
Теоретически можно все сделать макросами, всю эту реализацию интерфейса, но это будет адов говнокод без проверок, что есть в шаблонах С++.
А сама техника кодирования примерно такая:
несколько строк вычислителя;
работа с интерфейсом аппаратного блока АЦП|ШИМ
еще несколько строк кода вычислителя
работа с таймером - не упустили ли реальное время
еще несколько строк кода вычислителя
Если мы делаем С++ темплейты, то переход от синтетического порта к реальному контроллеру будет состоять в замене хидеров при сборке целевого кода.
И вычислитель, размазанный по коду задачи, как описал выше, будет полностью отлажен в "синтетическом порту".
Аналогично, пока знаток матана отлаживает вычислитель, аппаратчик отлаживает код интерфейса реального МЦУ тестовыми задачами, и добивается, что все живет гладко.
В итоге мы получаем:
* модульную структуру ПО
* переносимость его между всеми видами МЦУ, которые в принципе тянут вычислитель в RT.
* отсутствие оверхедов по памяти и быстродействию при ГРАМОТНОМ использовании С++
Минусы:
* квалификация разработчика нужена ++ сильно
* различного "кода" в шаблонах и прочем будет гораздо больше, чем при написании "С кода с нуля"
* тестирование must use
Насчет экономии времени разработки все зависит от сути вычислителя. Если он сложный, то без указанного подхода Вы его точно не отладите. Если он простой - в общем, можно рискнуть пойти на "plain C" вариант.
А когда речь идет о линейке приборов, то без описанного подхода вообще трудно жить.