ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Вторник
7 мая
48441 Топик полностью
AlexandrY (15.01.2006 23:49, просмотров: 1) ответил Evgeny_CD на Хочется большего!
Ну так вы описали идею пакета "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 - бесперспективная ось, под нее постоянно придется изобретать велосипеды.