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

Хочется большего! Matlab + Simulink - "это просто празник какой-то!". Смотрю я на работы AlexandrY и зависть профессиональная гнетет меня. Я тоже так хочу! Доступный мне инет пропылесосил, книжек по теме собрал, осталось их прочесть и осознать. Но уже сейчас я понимаю, что хочу большего. Просто пример. Пусть передо мной стоит задача разработки некоего девайса, который будет в себя включать * голосовые диалоги (довольно сложные) * захват видео (одиночные кадры) от аналоговой камеры * сжатие этих фотографий JPEG. Я хочу провести эту разработку "сверху". Т.е. я беру eCos, синтетический порт под Linux, и начинаю писать с _целевых функций_. Надо мне голосовой диалог? Ок! Да день работы. Но вначале я напишу его в режиме диалога через tty, где вместо проигрыша голоса будет проигрыш текстовых файлов, вместо DTMF - ввод с клавиатуры. И в таком виде начну обкатывать вместе с кустомером. Когда логика (а оно там весьма нетривиальная, и точное ТЗ без такой модели никто не напишет) будет готова, перейдем к следующим упражнениям. Заметим, что уже после первого шага у меня будет готовый, отлаженный кусок кода под целевой ОСью (только переписать _внутренности функций типа play_msg() - а внешний интерфейс такой функции у меня будет уже отлажен - ей пофиг, что и куда проигрывать :) ) Переходим к задаче выбора кодека для голоса. Оценив запас по быстродействию целевой платформы и объем FLASH, я выберу кодек. И начну его писать? ДУДКИ! Я найду его готовую реализацию, и пущу в виртуальном режиме - как C приложение на том же Linux, под MATLAB и пр. Обмен данным - через IP сокеты. Хоть на другой машине. Заметим, что управляться этот кодек будет из моей целевой программы под целевой ОСью. Опять же, если я не буду кретином, то напишу универсальную обертку для любых кодеков. Поэкспериментировав с кодеком, выбрав подходящий с подходящим битрейтом, я опять же проведу тестирование с кутомером, мы все окончательно решим, и можно выделять ресурсы на портирование кодека на целевую платформу (или даже его покупку). Аналогично с фотками. Я не хочу вначале тратить ни одного часа на понимание того, как работает JPEG!!! По описанной выше технологии я прикручу готовый JPEG кодек (коих мульон есть), и будут отлаживать систему _целиком_. Далее можно хоть на асме написать супероптимальный кодек - когда будет точное ТЗ на него, и все будут точно знать, каких параметров надо достичь в конце концов. К чему это я? Надо (IMHO) не RTOS пусть под Matlab, а "сущность" под управлением Matlab сделать ресурсом под управлением моей ОС. Это даст возможность с самого первого шага идти сразу к целевой задаче, по пути уточняя ТЗ (что совсем не маловажно! - в том же примере JPEG кодеки бывают сильно разные - оптимизированные на качество, скорость, объем данных и пр. - сразу далеко не очевидно, какой надо выбрать!), и ни тратя ни одного часа на "левые" вещи. Python (хотя я только начал изучать его) меня убил наповал. Такой красоты и кайфа от программизма я еще не встречал. IMHO, учить программировать надо не с C, С++ и пр, а именно с Python. Короче (не хочу флеймить) Python - это очень хорошая инструментальная платформа для такого рода комплекса. SWIG, судя по собранной информации - вполне рабочая штука, с нею имеет смысл возиться. Интуитивно я чувствую, что с "изобретением" идеи оберток я начал "изобретать" С++. Вообще, вероятно, грамотное (скорее даже концептуальное) использование идей ООП в embedded системах - это просто новая эра (по крайней мере для меня точно). Не знаю, может, у меня эйфория, но я чувствую, что такой подход безграничен, как вселенная. Есть сущность - моя целевая embedded ОСь. Она управляет другими сущностями. Любыми. Через сокеты, например. По мере необходимости эти сущности втаскиваются внутрь ОСи, становясь "локальными" задачами. А потом все это собранное и отлаженное хозяйство ставится при помощи BSP на целевую платформу. Понятно, что все гладко не будет. Те же глюки в BSP могут столько крови попортить, что мало не покажется (был у нас года два назад опыт - программеры месяц "джитагили" борду, пока ошибку в BSP uCOS для AT91RM9200 не нашли). Но при таком подходе за счет объектного подхода вся система легко разбирается на части, связи между ними конечны и понятны - так что глюки легко локализовать. Мне кажется, что системы типа KEIL симулятор, MATLAB и пр. являются только частью такой вселенной, но не могут ее заменить. Кто наведет грамотную критику на мои размышлизмы - тому большой респект!