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