Evgeny_CD, Архитектор (15.01.2013 00:01, просмотров: 110) ответил fk0 на Для виртуальных проще, лучше и выгоднее по многим причинам (вплоть до софта) купить один сервер на группу разработчиков. Для полувиртуальных всё упрётся в ввод вывод. Ну там платы Moxa и IPCDAS. И будет в первую очередь искать матьплату с кучей
нет, вселенная изменилась. http://caxapa.ru/379934.html
Стоит такой NUC 120 х 120 х 40 мм и тихонько жужжит своим кулером. К нему БП ноутбучный. Или свинцовый аккум размером с него, от которого он сможет проработать часа 2.
* полная развязка. WiFi, оптика с конвертером для связи с "базой"
* резервирование питания. Чтобы от моргания света, вызванного стартом бооольшого асинхронного движка, не похерилась статистика, которую 2е суток собирали.
* просто переключить прибор, не потеряв данные.
В нем Linix и целевая прога под ним. И test suite. Который натягивает прогу по все щели.
Потом добавляем модельку несуществующей пока железяки на SystemC. И наша прога начинает натягиваться тем же тест сьютом, но уже с железом, которого в реале нет.
Code Coverage по полной. Статистика обращений к железяке.
По итогам натяга решаем, правильная ли у нас модель железяки, надо ли ее делать так или еще как - дает она нужное ускорение для софта или нет.
Теперь надо бы показать нашу модельку зокозчегу. В реальном мире. И модельки дополнительно верифицировать.
Берем контроллер с Ethernet, благо их сейчас не мало, и отгоняем данные по простому протоколу на основе RAW Ethernet на нашу "симуляционную машину". Обратно также выдаем данные.
В контроллере ничего не обрабатываем. Просто капчурим данные, ставим метки времени от таймера, пакуем и даем комамнду DMA "отослать блок нахрен".
Контролируем латентность петли управления. - метка, когда пакет отправили, и кода пришел ответный пакет. Учет ошибок при превышении задержки.
Когда все проверено - начинаем делать целевую плату и целевую FPGA. SystemC модель используем для верификации кода FPGA.
eCos штатно имеет синтетический порт под Linux. Т.е. ставишь дефайны - и прога под eCos под Linux имеет тот же код, как и в железе (за вычетом дров).
Интерес к POCO -> тоже вызван его вроде бы как портируемостью.
Разумеется, применение такого подхода зависит от решаемых задач. Когда решение залачи - 1к строк на C под "профессиональный контроллер", и никакого вопроса в поведении реальных ообъектов нет - тогда это избыточно.
А вот когда задача до конца не ясна, и Заказчик тоже ясностью не страдает, вот тогда наличие такого отработанного подхода убережет от разводки ненужных плат и написания ненужного целевого кода.
Буду признателен за критику.
P.S. "аппаратные оверхеды" на все эти "средства виртуализации" стоят меньше месячной ЗП весьма низкоквалифицированного разработчика.
P.P.S. однажды нечно подобное было мною использовано на практике - удаленная отладка GSM модема в другом городе с кривым ОПСОСОм. Моксовский конвертер RS-232 <-> Ethernet, мудем на фирменной отладочной плате, хороший Интернет у Заказчик со статическим публичным IP. В общем, оно получилось, но в силу неспециализированных средств было много геморроя - пришлось эникейщика посадить "с той стороны" кнопки нажимать, питание передергивать и пр.