Универсальная среда, для разработки и отладки 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 и пр. являются
только частью такой вселенной, но не могут ее заменить.

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

[Evgeny_CD]

В общем, я не одинок в своих мыслях.

1. есть такая штука, как eXtreme Programming. Очень хорошее обсуждение получилось
http://www.caxapa.ru/echo/arm.html?id=49785

2. Есть статья с такими же мыслями
http://rapidshare.de/files/12172724/EmbeddedXp.pdf_.html
ek74

[Doka]

весьма занятная тема... и чрезвычайно (по кр. мере для меня) пользительная
.
в силу опыта грамотную критику врядли смогу навести, но вот попробовать применять данную методологию хотелось бы...
и тут имхо, достоинства либо недостатки предложенного метода можно проверить на конкретном проекте.
.
и как всегда всплывает "НО" : времени для решения текущей задачи как всегда нету, а для освоения несколькосотстраничных документов по Python, SWIG, XP, TestUNIT его еще меньше.
.
посмотрел с интернете по Питону - понравилось. SWIG еще не смотрел, но доку взял.

А вот с обертками чуть посложнее. Есть у меня С код. Можно к нему обертку прикрутить на С, но это будет дольше. Я лучше сделаю этот код ресурсом Python скрпита, а обертку напишу на самом питоне (там это полэкрана).

..а можно об этом попдробнее? т.е. как конкретно прикрутить Си файлы к Питону?!
в программизме (а особенно ООП) я не Копенгаген
нашел вот статейку: Интеграция кода на Python и Си http://www.linuxjournal.com/comment/reply/8497
но там ,как я понял, все предлагают писать на питоне а программа на Си состоит просто из вызова программы на Питоне.:(
о задаче:
у меня проект совсем не большой. полностью на Си с определением всех типов по typedef + критичные места с использованием intrinsics'ов от TI (файл gsm.h).
сам проект - демодулятор на сигнальнике.
вот его-то алгоритм и хотелось бы отладить - бо, регул.ручек, которые можно крутить для настройки его правильной работы - немеренно, а симулинк не описывает "один-в-один" его работу - где-то появляются несоответствия по тактам работы, по отношению чисел.
в конечном итоге хотелось бы отладить (хотя данном случае более подходит слово "настроить") код на х86 и на этом основании выставить все правильные насторойки констант в С55хх

про тестовые юниты немного читал на http://www.xprogramming.ru/
понятного мало. Там больше про ООП уклон - а если у меня нету ни классов, ни методов (и я вообще мало понимаю что это такое) - то с чего начинать писать т.юниты?!
да и потом - для всех случаев их всеравно не напасешьсЯ, и даже для программной отладки - если надо оттестировать алгоритм подсчета CRC - то тут как быть?! иметь над ним надстройку, которая заведомо верно считает CRC по нужному полиному?