Комментарии 11
Интересно, что помешало реализовать остальную сверхскоростную часть внутри FPGA в виде связки быстрой логики (что-то вроде двухпортовая RAM + логика + конечный автомат + если надо DSP) + встроенного в чип PowerPC для общей координации процесса, если фреймграббер уже реализован.
Хотя вопрос наверно не к вам, и у него были причины переносить обработку изображения на «ранних стадиях» на CPU.
Хотя вопрос наверно не к вам, и у него были причины переносить обработку изображения на «ранних стадиях» на CPU.
Самый ценный ресурс — время.
Отлаживать CPU-код (особенно на PC!) гораздо легче и быстрее, чем городить сигнал-процессинг внутри ПЛИС.
На последующих стадиях разработки, когда заказчик уже убедился что железяка реально работает и готов раскошелиться на оптимизацию — тогда да, значительную часть DSP можно спокойно упаковать в ПЛИС и портировать в Линукс или винду.
Отлаживать CPU-код (особенно на PC!) гораздо легче и быстрее, чем городить сигнал-процессинг внутри ПЛИС.
На последующих стадиях разработки, когда заказчик уже убедился что железяка реально работает и готов раскошелиться на оптимизацию — тогда да, значительную часть DSP можно спокойно упаковать в ПЛИС и портировать в Линукс или винду.
а в Линуксе цикл модификация кода — компиляция драйвера – перезагрузка – анализ printk-сообщений занимал неприемлемо долгое время
А зачем именно перезагрузка? Возможно, я что-то не понимаю, но модуль же можно выгрузить и загрузить новый без проблем.
Передаю ответ art_zh из чата на форуме board.kolibrios.org
в том смысле что на ранних этапах разработки новое, неотлаженное PCIe-устройство часто виснет само и вешает всю систему.
пока не будут выловлены все баги (и в драйвере, и в ПЛИС) — приходится перезагружаться сотни раз
А, тогда понятно. В таком случае Колибри чем выигрывает — не виснет намертво или быстрее перезагружается?
Гораздо быстрее перезагружается: 3-5 сек
Очень быстрый цикл компиляция — перезагрузка.
Во-первых, быстрее перезагружается (POST+BIOS + 2 секунды),
а во-вторых, с экзоядром отпадает необходимость в отдельной компиляции отладочного драйвера кернелспейса — printk-прослойки между отлаживаемым приложением и налаживаемым железом.
(у кода — отладка, у аппаратуры — наладка. Хотя, если железо построено на ПЛИС, то наверное и там тоже правильнее говорить «отладка»?)
а во-вторых, с экзоядром отпадает необходимость в отдельной компиляции отладочного драйвера кернелспейса — printk-прослойки между отлаживаемым приложением и налаживаемым железом.
(у кода — отладка, у аппаратуры — наладка. Хотя, если железо построено на ПЛИС, то наверное и там тоже правильнее говорить «отладка»?)
Испытываю громадное уважение к таким проектам. Ребята вы молодцы! Продолжайте!
Добавлю про GPU. К сожалению, единственный реальный путь к использованию GPU ATI/AMD лежит через портирование LLVM. Первая попытка закончилась неудачно, но я не теряю надежды.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Применение KolibriOS. Часть 2: Экзоверсия ядра для разработчиков железа