Универсальная среда, для разработки и отладки embedded систем Опции

[Evgeny_CD]

Задумался я тут о создании универсальной среды для разработки и
отладки embedded систем. Есть классика жанра - Matlab + Simulink -
"это просто празник какой-то!". Смотрю я на работы AlexandrY
http://aly.projektas.lt/Projects/MATLAB/DT...coderEvanse.htm
и зависть профессиональная гнетет меня. Я тоже так хочу!
Доступный мне инет пропылесосил, книжек по теме собрал, осталось их
прочесть и осознать. Но уже сейчас я понимаю, что хочу большего.

Просто пример. Пусть передо мной стоит задача разработки некоего
девайса, который будет в себя включать
* голосовые диалоги (довольно сложные)
* захват видео (одиночные кадры) от аналоговой камеры
* сжатие этих фотографий 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 и пр. являются
только частью такой вселенной, но не могут ее заменить.

Кто наведет грамотную критику на мои размышлизмы - тому большой
! А то может у меня уже крыша съехала от долгого размышления...