Ну так вы описали идею пакета "MATLAB Link for Code Composer Studio" Только MathWorks не тешит себя иллюзиями, что JPEG и voice кодеки серьезно можно разрабатывать для процессоров общего применения.
Берите DSP или OMAP, и юзайте в любых положениях. Хоть ось в проце, а JPEG в PC или наоборот JPEG в проце, а ось в PC. Это все уже реализовано.
Если же все таки будете портировать DSP алгоритмы на ARM да еще под осью, то напоритесь на такие проблемы скорости выполнения, что ваши решения станут золотыми в смысле инвестиций в разработку.
Тут, к стати, с вашим eCos (не в обиду ;-)) и вылазят первые проблемы. Серьезные софтварные компании в области моделирования и отладки в помине не знают о существовании какой-то eCos. Вот OSEK/VXD, vxWorks и т.д. пожалуйста, с ними работают серьезные специалисты думающие о моделировании и тестировании. А у eCOS одна идея - халява, а халявщикам зачем тестировать?
Еще, как видно, у вас наблюдаеться наличие событийно управляемых программ c человеко-машинным интерфейсом. Для этого есть инструменты построенные на концепции Model Driven Development использующие как один из языков UML. Они как правило имеют способность автоматической проверки ваших моделей на непротиворечивость и генерят исходники на С под заданную операционку и могут интерактивно отлаживаться на целевой платформе, но они тоже ни в какую не признают eCos.
Т.е. технология бы выглядела так: в Rhapsody разрабытываете логигу работы и все интерфейсы взаимодействия. DSP алгоритмы отлаживаете изолированно в MATLAB, потом их подключаете к UML модели в виде функциональных макроблоков.
Пара может быть и другой, например: Telelogic TAU и LabView.
Но ваша концептуальная проблема останется, eCos - бесперспективная ось, под нее постоянно придется изобретать велосипеды.
-
- Большое спасибо! Но я как-то интуитивно недолюбливаю всякие визарды, кодогенераторы и пр. Может, я и не прав... - Evgeny_CD(16.01.2006 00:47, )