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

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

[makc]

Т.е. получается, что Вы предполагаете априори, что обернутая задача будет на целевой платформе работать точно так же. Но ведь это будет так далеко не во всех случаях. И такие случаи, как правило, самые сложные, по моему опыту. И в подобных ситуациях выходов не много - либо отладчик, либо полноценный симулятор целевой платформы, например, Simics (внутренности которого, кстати, тоже на Python'e ).

Причин подобный проблем может быть множество. Самый простой пример - используются разные библиотеки С. Все, понеслось - поехало. А прикручивать нестандартную библиотеку (от целевой системы, да еще собранную в отладочной платформе) тоже непростая задача.
Другой пример - x86 относятся к невыровненным по границе слова обращениям к чтению слова вполне нормально. Читают и пишут правильно. Если попробовать сделать нечто подобное на ARM'e, то работать не будет. У меня один коллега наступил именно на такие грабли и убил на отладку около недели - это было в драйвере USB, который сначала был отлажен на x86 в некоем подобии обертки, сделанной на С, а после перенесен на ARM. И начались проблемы...

Вы не подумайте, что мне не нравится этот подход. Мне тоже хочется, чтобы было что-то подобное, позволяющее отлаживаться в более удобных условиях и экономящее время, которого так не хватает. Я лишь хочу сказать, что не все так радужно и на этом пути существует множество подводных камней, для нахождения которых могут понадобиться совсем другие средства. Т.е. может получиться, что отладку придется выполнять не один раз, а два. Хотя, конечно, на втором этапе отладки некоторые вещи отлаживать уже не придется...

[Evgeny_CD]

...Самый простой пример - используются разные библиотеки С. Все, понеслось - поехало. А прикручивать нестандартную библиотеку (от целевой системы, да еще собранную в отладочной платформе) тоже непростая задача.
Другой пример - x86 относятся к невыровненным по границе слова обращениям к чтению слова вполне нормально. Читают и пишут правильно. Если попробовать сделать нечто подобное на ARM'e, то работать не будет...

Хорошие примеры! Тут и возразить нечего.

[makc]

...Самый простой пример - используются разные библиотеки С. Все, понеслось - поехало. А прикручивать нестандартную библиотеку (от целевой системы, да еще собранную в отладочной платформе) тоже непростая задача.
Другой пример - x86 относятся к невыровненным по границе слова обращениям к чтению слова вполне нормально. Читают и пишут правильно. Если попробовать сделать нечто подобное на ARM'e, то работать не будет...

Хорошие примеры! Тут и возразить нечего.

Да нет, возразить можно. Правда это уже получается спор самого с собой.
Суть в том, что модель, разрабатываемая под оберткой должна учитывать специфику аппаратной реализации целевой платформы. Это раз. А два - сузив область применения этого подхода мы можем обосновать возможность его применения.

Как пример могу привести эпизод из своей практики разработки, при которой использовался в некотором роде предложенный Вами подход: необходимо было разработать маленькую файловую системы для AT45DB, которая была бы журналируемой и минимальной по ресурсам. Понятно, что отлаживать такую файловую систему в МК дело довольно хлопотное, тем более, что нормального отладчика под рукой не было. Я пошел иным путем, довольно распространенным - создал реализацию файловой системы на С и обертку (тоже на С, мне так было проще), которая позволяла выполнять все необходимые операции файловой системы, а вместо AT45DB выступал обыкновенный файл. Т.е. обертка предоставляла ограниченный набор необходимых низкоуровневых функций для работы с этой памятью. Это позволило выявить большинство возможных ошибок в алгоритмах файловой системы еще на модели и избавиться от этого утомительного процесса на целевой платформе. Вот такая история и если бы я использовал SWIG, то сделал бы модель быстрее и лучше, и, возможно, выявил бы еще некоторые проблемы реализации... Так что этот подход тоже имеет право на жизнь, просто область его применения не такая глобальная, как может показаться с самого начала.

[Evgeny_CD]

...Суть в том, что модель, разрабатываемая под оберткой должна учитывать специфику аппаратной реализации целевой платформы...

Специфика должна быть спрятана внутри сущности! Так же как драйвер прячет от оси многие подробности железа.

Что касается либов - это серьезный вопрос! В моих проектах особой завязки на стандартные либы нет. Всякие printf вынесены отдельно, чтобы их дефайнами можно было "переколбасить" под рабочую среду.

Насчет выравнивания по границе - ну тут иж за этитм придется следить. Кстати, компилеру GCC при компиляции под x86 нельзя объяснить, чтобы он строго следил за такими вещами?

Как пример могу привести эпизод из своей практики разработки, при которой использовался в некотором роде предложенный Вами подход: необходимо было разработать маленькую файловую системы для AT45DB, которая была бы журналируемой и минимальной по ресурсам. Понятно, что отлаживать такую файловую систему в МК дело довольно хлопотное, тем более, что нормального отладчика под рукой не было. Я пошел иным путем, довольно распространенным - создал реализацию файловой системы на С и обертку (тоже на С, мне так было проще), которая позволяла выполнять все необходимые операции файловой системы, а вместо AT45DB выступал обыкновенный файл. Т.е. обертка предоставляла ограниченный набор необходимых низкоуровневых функций для работы с этой памятью.

Вот тут

http://sourceforge.net/projects/efsl/

файловая система как "отладочный девайс" заложена изначально в структуре проекта.

Насчет мегауниверсальности - только вскрытие покажет! Моя задача сейчас - понять, нет ли грубых ляпов в логической цепочке, чтобы по возможности, выправить их в начале пути. Ну и потихоньку идти по намеченному пути...