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

и еще немного о целях всего проекта.. Salute! Тут еще немного на досуге подумалось.. А в чем вообще может состоять цель этой самой отладочной платы? Отладка боевой программы в железе? Но, поскольку, производительность измеряется в попугаях, то это полная ерунда. К тому же, конечная программа может рассчитывать на аппаратные особенности железа, которые на удасться сэмулировать в реальном времени. Отладка алгоритма реальной программы? Но то ведь можно замечательно сделать и в полностью софтварном режиме. Написать эмулятор на ПК и подсовывать ему нужные данные. Но тут сразу возникает интересный момент: а откуда брать эти данные? Как, грубо говоря, поведет себя сигнал на входе "B", если за 1 мс до этого дернуть вывод "A"? Вот здесь эта Dream platform и может оказать существенное подспорье. Сишная программа, получается, должна взаимодействовать с железом путем системных вызовов. На выводах железяки появляются/снимаются нужные сигналы. Все сохраняется на ПК и передается в симулятор. А вот там уже, собственно, и начинается процесс отладки тяжелых алгоритмов. К тому же приедтся ответить на такие интересные вопросы, а что если отлаживаемая установка не допускает своего оключения? Получается, пользовательский код должен заливаться "на ходу", выполнятся, а потом, по запросу, заменятся обратно. Как обеспечить поддержку неквалфицированного пользователя? Некоторые, ведь, хорошо составляют схемы, но разобраться в сложном коде будут не в состоянии. Значит потребуется интерпретируемый язык и набор функций к нему. А что если скорости ввода/вывода окажется мало? При пакетной передаче пиковая скорость может оказаться весьма высокой. Что делать с ЭМС? Если уж и городить самопальный канал, так сделать его, к примеру, на оптическом трансивере. Все равно он через ПЛИС подключен. Появится железо, по софту заковырок станет еще больше.. Best regards, Sergei