[Evgeny_CD 0]

Задумался я тут о создании универсальной среды для разработки и

отладки 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 и пр. являются

только частью такой вселенной, но не могут ее заменить.

 

Кто наведет грамотную критику на мои размышлизмы - тому большой

:a14: ! А то может у меня уже крыша съехала от долгого размышления...

[makc 199]

Если я правильно Вас понял, то Вы хотите с помощью SWIG обернуть ваш рабочий проект и использовать в качестве среды для его отладки Python или другой интерпретируемый язык?

 

Но ведь это автоматически означает, что Вам придется самому создать эту среду, в то время как имеющиеся эмуляторы делают ее для Вас, т.е. Ваши трудозатраты меньше. А при использовании предлагаемого пути - трудозатраты возрастут.

 

Мне SWIG видится средством для простого расширения функций какого-либо интерпретируемого языка за счет использования оберток функций на другом языке для дальнейшего встраивания этого расширения в большой проект. Как это например сделано в ModelSim, где TCL встроен в среду и органично в ней существует для расширения имеющихся в среде базовых функций.

[Evgeny_CD 0]

...Если я правильно Вас понял, то Вы хотите с помощью SWIG обернуть ваш рабочий проект и использовать в качестве среды для его отладки Python или другой интерпретируемый язык?...

Тут малость все смешалось по моей вине:)

 

"Отладочная вселенная" судествует сама по себе. Это Linux (наверное когда-нибудь я стану настоящим юниксоидом - ортодоксом, и сяду на "солярку" по причине ее масштабируемости - но пусть пока будет Linxu) + IP. Если какой-либо компонент может сам использовать IP для обмена - обертки особо не нужны.

 

Python мне нужне как отладочный инструмент, и для оберток. Как отладочный инструмет - генерить тестовые воздействия и записывать результат.

 

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

 

Я никогде не смогу пустить eCos (напимер) под симулинком. А вот как запустить под eCos задачу из симулинка, похоже, придумалось.

[makc 199]

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

 

Причин подобный проблем может быть множество. Самый простой пример - используются разные библиотеки С. Все, понеслось - поехало. А прикручивать нестандартную библиотеку (от целевой системы, да еще собранную в отладочной платформе) тоже непростая задача.

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

 

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

[Evgeny_CD 0]

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

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

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

[makc 199]

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

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

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

 

Да нет, возразить можно. Правда это уже получается спор самого с собой.

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

 

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

[Evgeny_CD 0]

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

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

 

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

 

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

 

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

Вот тут

 

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

 

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

 

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

[makc 199]

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

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

 

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

 

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

 

Большой завязки и не нужно. Некоторые, даже относительно простые функции типа mktime (если мне не изменяет память), например в newlib и в glibc реализованы по-разному. Проблема в том, что не знаешь на что нарвешься...

 

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

 

Вы, кажется, неправильно понимаете роль компилятора в проблеме выравнивания. GCC может правильно выровнять для платформы x86. Но проблема в том, что при обращении к некоему буферу по указателю на его начало это обращение будет не выровнено. На x86 все будет хорошо, а вот на ARM'e хорошо если будет DataAbort. LPCшки, например, просто возвращаяют черти чего при подобном обращении (но это допустимое поведение, описаное в руководстве на ядро процессора). Так что следить за подобными вещами должен программист и никто другой. Но одно дело, когда сам пишешь все от начала и до конца, и совсем другое когда используемый код генерится чем-то или хочется использовать чужие наработки.

 

[quote name='makc' post='78270' date='Jan 15 2006, 22:13']Как пример могу привести эпизод из своей практики разработки, при которой использовался в некотором роде предложенный Вами подход: необходимо было разработать маленькую файловую системы для AT45DB, которая была бы журналируемой и минимальной по ресурсам. Понятно, что отлаживать такую файловую систему в МК дело довольно хлопотное, тем более, что нормального отладчика под рукой не было. Я пошел иным путем, довольно распространенным - создал реализацию файловой системы на С и обертку (тоже на С, мне так было проще), которая позволяла выполнять все необходимые операции файловой системы, а вместо AT45DB выступал обыкновенный файл. Т.е. обертка предоставляла ограниченный набор необходимых низкоуровневых функций для работы с этой памятью.[/quote] Вот тут 

[url="http://sourceforge.net/projects/efsl/"]http://sourceforge.net/projects/efsl/[/url]

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

 

И это правильно!

 

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

 

Очень правильный подход. Сам стараюсь пользоваться этим подходом и стараюсь повернуть в эту сторону начальство. Но пока получается не всегда, а в большинстве случаев ответ один - "рано еще об этом думать, вот доживем до нужного момента - подумаем".

 

PS: Важным достоинством предложенного здесь подхода является возможность использования gcov на этапе тестирования ПО. На целевой платформе gcov не доступен. :(

[Evgeny_CD 0]

...Вы, кажется, неправильно понимаете роль компилятора в проблеме выравнивания. GCC может правильно выровнять для платформы x86. Но проблема в том, что при обращении к некоему буферу по указателю на его начало это обращение будет не выровнено....

Может я не прав, но если объявлять юнионы, и аккуратно пользоваться указателями, то проблем быть не должно.

 

Если у нас есть массив char, то компилятор может разметить его как угодно. Но если это union массива char и массива int, то компилер должен выровнть его по границе. Или я не прав?

 

Очень правильный подход. Сам стараюсь пользоваться этим подходом и стараюсь повернуть в эту сторону начальство. Но пока получается не всегда, а в большинстве случаев ответ один - "рано еще об этом думать, вот доживем до нужного момента - подумаем".

Я много лет так жил. Достало! :maniac: Столько всего полезного было сделано в разных проектах - и его так тяжело повторно использовать! А теперь вот набрался мужества послать все куда подальше и начать новое поколение проектов с "правильной" основы. Я понимаю, что на первых проектах экономичесикая эффективность будет не очень (хотя как сказать -быстрая отладка дорогого стоит!) и времени я потрачу немало (одна гора книг на моем столе, которые я пометил как must read, вызывает ужас, книжкой по питону вообще можно кого-нибудь зашибить -1к страниц!), но я чую, что освоив эту методологию, и заразив ею окружающих, можно получить настоящий эффект.

 

Хотя при наличии конструктивной критики и конструктивных предложений из вне процесс может быть не таким уж и страшным. :tort:

[makc 199]

...Вы, кажется, неправильно понимаете роль компилятора в проблеме выравнивания. GCC может правильно выровнять для платформы x86. Но проблема в том, что при обращении к некоему буферу по указателю на его начало это обращение будет не выровнено....

Может я не прав, но если объявлять юнионы, и аккуратно пользоваться указателями, то проблем быть не должно.

 

Абсолютно верно. Ключевое слово - аккуратно. Если этой аккуратности не будет, то жди беды. Уж сколько лет говорят о проблеме указателей, столько же лет люди совершают ошибки при работе с ними.

 

Если у нас есть массив char, то компилятор может разметить его как угодно. Но если это union массива char и массива int, то компилер должен выровнть его по границе. Или я не прав?

 

Вы правы. Но проблема в другом, отчасти это проблема неаккуратной работы с указателями. Например, если вы имеете указатель на массив целых чисел, то преобразовав его к типу (char*) и обратившись по полученному указателю к элементу типа char - все будет в порядке. Но если Вы имея указатель на массив типа (char*) преобразуете его к типу (int*), причем это будет элемент (char*) чье смещение не кратно 4, то при обращении по полученному адресу на АРМе будут проблемы. А union тут особо не поможет. Да начало будет выровнено, но ведь можно при определенном стечении обстоятельств, обратиться по невыровненному смещению в середину... Т.е. решение этой проблемы - аккуратность. Ну или можно написать макрос, который будет проверять смещение, по которому будет производиться обращение и в одном случае непосредственно возвращать данные по указателю, а в другом вызывать специальную функцию. Т.о. решение этой проблемы можно автоматизировать и сделать переносимым. :)

[framer 0]

Подозреваю что многие пробуют найти универсальный подход. И многие приходят к подобным выводам. Интересно получаеться .... оказываеться я тоже писал файловую систему которая была отлажена на РС а физическая память отображалась в файле. А это означает, что действительно потребность есть. Пробывал применать такой подход в следующих проектах и оказываеться, что для некоторых задач проблем не возникает но когда начинает прикручиваться РТОС либо специфические условия то появляються проблемы. А некоторые задачи вообще не подходят (вспомнил проект конвертера видео на светловолокно 90% задачи - это контроль потока даных и установка регистров). А пока тоже нахожусь в лесу и ищу выход. Что касаеться питона то действительно это очень помогает. А еще пригодилось бы: java, tcl/tk и octave. Вот когда это все изучить может и решение придет само собой но тогда уже и работать незахочиться и можно будет на писании книг зарабатывать :)

[Evgeny_CD 0]

...А еще пригодилось бы: java, tcl/tk и octave...

В tcl/tk лично я кайфа (IMHO много раз) пока для себя не узрел.

 

Octave - первый раз по Вашей наводке посмотрел, что это такое. Насколько я понял, это некий аналог MATLAB?

...Вот когда это все изучить может и решение придет само собой но тогда уже и работать незахочиться и можно будет на писании книг зарабатывать :)....

Сомнительно, что сейчас написание книг в Росси по таким фундаментальным вещам, как серьзеные фришные продукты типа Python, сможет прокормить. Сколько автор получит от тиража 2-3к экземпляров книги с продажной ценой 150-300р? Хорошо, если 1 k$. Если издатель будет очень добр и не кинет автора (а почему бы не указать тираж 1к, а отпечатать и продать все 10к?) (хотя я совершено не вижу основания для таких действий - как раз кинуть "ботана" - это святое для наших (и не только) бузинессмэнов), то, вероятно, 3к получить можно. А чтобы написать хорошую книжку, нужен год. Т.е. надо не менее 10к, чтобы хоть как-то оправдавть свое существование.

 

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

[iosifk 3]

...Вот когда это все изучить может и решение придет само собой но тогда уже и работать незахочиться и можно будет на писании книг зарабатывать :)....

 

Сомнительно, что сейчас написание книг в Росси по таким фундаментальным вещам, как серьзеные фришные продукты типа Python, сможет прокормить...

 

По поводу обсуждения:

Много раз я тоже пытался приучить начальников проводить разработки не от "гайки М3" а от задачи - алгоритма - процессора-... Дается такое трудно, поэтому сочувствую.

 

А вот по поводу книг могу точно сказать, чтобы написать книгу, для начала надо опубликовать из нее главы в журналах. Все "бльшие" так делают. А когда читаете материалы, то ОДНОВРЕМЕННО заносите все то что интересно в отдельный файл. Если будут по этой теме вопросы - то по почте.

 

Удачи и желаю Вам написать книгу!

[Evgeny_CD 0]

Интересная штуковина попалась. Как водится, случайно

 

http://comsec.com/wiki?UniversalSoftwareRadioPeripheral - железяка

The price for the motherboard is $550, and basic daughterboards cost $75 each. This setup with four daughterboards cost $850

 

http://www.ettus.com/index.html - изготовитель железяки

 

http://www.gnu.org/software/gnuradio/ - софт

 

http://webpages.charter.net/cswiger/ - примеры использования

 

http://webpages.charter.net/cswiger/psk_experiment.html

Как при помощи простых скриптов построить передатчик довольно продвинутых сигналов

 

Это в точности такая же идеология, как я писал в своих размышлениях!!!

Т.е. все простое (с точки зрения логики), но ресурсоемкое - на С/С++,

а вот вся логика работы на Python. + тот самый SWIG для связи.

 

Так что этот подход точно имеет право на жизнь!!!

 

...А когда читаете материалы, то ОДНОВРЕМЕННО заносите все то что интересно в отдельный файл...

У меня для этих целей http://treepad.com/ служит вот уже с 98 года :)

[Evgeny_CD 0]

Оказывается, есть free аналог Matlab и Simulink

http://www.scilab.org/

http://www.scicos.org/