Есть у меня давняя мечта - научиться запускать eCos на симуляторе. Прелестей у такого решения очень много - и отладка логики проекта, и автоматический запуск test units, проектирование разделения функций между аппаратурой и железом (когда железа еще нет), и многое другое.

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

============== Симулятор ARM (и не только) SID ==============

Вот тут
http://sourceware.org/ml/ecos-discuss/2003-08/msg00274.html

Обнаружилась очень интересная вещь:
eCos and SID on ARM PID target HOWTO
http://www.asisi.co.uk/ecos_sid.html

Порт eCos, который там упоминается
http://ecos.sourceware.org/ecos/boards/arm-pid7.html

Вот еще
http://sourceware.org/ml/ecos-discuss/2003-08/msg00277.html
No, but it is a very convenient way to emulate target hardware, especially as you specify ARM. Some other simulators are supported directly by eCos (notably Power PC) but as far as I know, the ARM Instruction Set Simulator (ISS) in GDB isn't as such. The main advantage of using SID for me was that it looks like a real bit of hardware and it's thus like developing and debugging on a real platform. You don't really get that with an ISS built into a debugger.

SID
http://sourceware.org/sid/
SID is a framework for building computer system simulations. Specifically, a simulation is comprised of a collection of loosely coupled components. Simulated systems may range from a CPU's instruction set to a large multi-processor embedded system.

SID defines a small component interface which serves to tightly encapsulate them. Components may be written in C++, C, Tcl or any other language to which the API is bound. Typically, components are separately compiled and packaged into shared libraries. A standard run-time linking/loading interface is defined for these.

user's guide
http://sourceware.org/sid/sid-guide.pdf

developer's guide
http://sourceware.org/sid/cdk-guide.pdf

Component Reference - подробное описание компонентов, готовых для симуляции
http://sourceware.org/sid/component-docs/index.html

Мне особенно понравились вот эти два "компонента"
Members of this family of components perform I/O on a TCP socket and relay data across a pair of pins to some other component
http://sourceware.org/sid/component-docs/sid-io-socket.html

This component performs input/output on the standard input/output.
http://sourceware.org/sid/component-docs/sid-io-stdio.html

Основной кайф этого симулятора в том, что он симулирует полноценную систему, а не только сам процессор. При этом создание своих компонентов описано достаточно внятно - если писать модели для несложных компонентов - это это вполне подъемная задача.

Список готовых компонентов тоже внушительный
http://sourceware.org/cgi-bin/cvsweb.cgi/~...ain&cvsroot=sid
на его основе можно сделать чего угодно - все модели идут вместе с иходниками

Скриншоты впечатляют
http://sourceware.org/sid/screenshots/index.html

Особенно этот
http://sourceware.org/sid/screenshots/finale.jpg

Быстродействие этого симулятора, судя по всему, умеренное - сказываеся широкое использование Tcl. Но, с учетом полной автоматизации процесса, это не так и страшно.

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

SID поддерживает не только ARM, он еще много чего поддерживает. Но везде он почему-то фигурирует как ARM симулятор - то ли эта часть была написана лучше всего, то ли отлажена лучше всего...

Но самое одна из самых интересных вещей, которые я нарыл, ковыряясь с SID - это вот эта строчка на домашней странице SID'а:
Existing components are extensively tested using a DejaGNU test harness. If you are developing new components or enhancing existing ones, you must submit test cases along with your contributions. The test suite currently passes with zero failures.

============== Система тестрования DejaGnu ==============

DejaGnu
http://www.gnu.org/software/dejagnu/
DejaGnu is a framework for testing other programs. Its purpose is to provide a single front end for all tests. Think of it as a custom library of Tcl procedures crafted to support writing a test harness. A test harness is the testing infrastructure that is created to support a specific program or tool. Each program can have multiple testsuites, all supported by a single test harness. DejaGnu is written in Expect, which in turn uses Tcl -- Tool command language.

Expect
http://expect.nist.gov/
http://sourceforge.net/projects/expect
Expect is a tool for automating interactive applications such as telnet, ftp, passwd, fsck, rlogin, tip, etc. Expect really makes this stuff trivial. Expect is also useful for testing these same applications. And by adding Tk, you can also wrap interactive applications in X11 GUIs.

Expect can make easy all sorts of tasks that are prohibitively difficult with anything else. You will find that Expect is an absolutely invaluable tool - using it, you will be able to automate tasks that you've never even thought of before - and you'll be able to do this automation quickly and easily.

Книжка есть - совсем не дорого
http://www.amazon.com/gp/product/156592090...9350336?ie=UTF8
A book on Expect is available from O'Reilly with the title "Exploring Expect: A Tcl-Based Toolkit for Automating Interactive Applications", ISBN 1-56592-090-2.

The book is filled with detailed examples and explanations, and is a comprehensive tutorial to Expect. The book also includes a tutorial on Tcl written specifically for Expect users (so you don't have to read the Expect papers or the man pages). Exploring Expect is 602 pages.

Документауция по DejaGnu
http://www.gnu.org/software/dejagnu/manual/dejagnu.pdf.gz

Как выясняется, DejaGnu и симуляторы могут использоваться для тестирования GCC
How to test GCC on a simulator
http://gcc.gnu.org/simtest-howto.html

Трафик в мейл листе DejaGnu никакой, но проект жив. Судя по всему, его просто довели до совершенства.

Идея DejaGnu просто великолепная. Есть код. Компилируем, запускаем на целевой платформе (не обязательно локально - хоть по Telnet, хоть по GDB). Далее работаем с примитивами stdin/stdout. На специализированном (подмножество Tcl с уже готовыми объектами) языке подаем на stdin тестовые воздействия - при помощи того же языка анализируем stdout, и пишем лог - прошел тест или нет.

Таким образом, если настроить мозги так, что вместе с написанием каждого модуля пишется test unit, код каждого модуля организован правильно - есть define, и модулю безразлично, с чем он работает - с реальным железом или с его имититатором - то сбудется мечта идиота: часть работы можно переложить на плечи машины.

Т.е. после глобальной правки репозитория запускаем test suite (например, на выходные), и потом смотрим - то там у нас творится. Все ошибки, конечно, так не отловить, но значительную часть тупорылых ошибок при правильном написании test suite - запросто! Типа файл удалили, что-то не то задефайнили и т.д.

Ну что же, я, похоже, зашел на очередной виток понимания идеологии GNU. Прелесть всего этого, безусловно, не в хялявности (я тут список составил - что надо знать, чтобы более-менее нормально работать с GNU тулзами и проектами - года на три самообразования хватит...) Просто вся идеология GNU воспитывает писать код:

* модульный: разделять специфичные и неспецифичные вещи
* портабильный - все должно быть настраиваемо и конфигурируемо
* многократно использованый: если кто-то придумал хорошую "штуковину" -> ее начинают активно использовать -> быстро вылавливаются баги и придумываются новые фичи -> "штуковина" становится еще лучше.

А это очень и очень правильно!!! Это неибежно приводит к повышению качества кода.

Блин, ну почему нет учебников, где бы все это было подробно описано!!! Приходится по крупицам собирать инфу, до всего додумываться самому...

Симулятор - первый шаг на пути к резиновой женщине. Окромя тестирования математических алгоритмов (что можно сделать и так на любом PC) ценность сего симулятора весьма сомнительна. "просто довели до совершенства" - наверное лучше оставить без комментариев :-D :-D . Вобщем очередная игрушка Евгения :-) (без обид). Ну а к повышению качества кода ведет в основном самодоисциплина программистов, а не очередная примочка

Именно к такому выводу и пришёл Evgeny_CD в конце (3-й абзац снизу) своего спича.

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

Без обид. Второй раз DASM постит эту фразу - оставлю без комментария. Не хочу флейма.И это говорит человек, который собаку съел на JTAG

Да, в варианте IAR, как я все больше и больше убеждаюсь, ценность многих вещей точно сомнительна.

Рассмотрим простой пример. Файловая система.

Берем EFSL
http://www.efsl.be/
http://sourceforge.net/projects/efsl/
http://gandalf.arubi.uni-kl.de/avr_project..._arm/index.html

Все замечательно, но часть народа жалуется на глюки. Возможно, они аппаратные - ибо другая часть народа говорит, что у них это работает в десятках проектов и все ОК.

При помощи JTAG, GDB и DejaGNU создаем среду для автоматического тестирования на реальном железе:

* откомпилили, собрали, загрузили, запустили
* Программа отработала кусок - до точки останова. При помощи GDB считали/записали память. Снова запустили, например, с новыми параметрами (просто через GDB перезаписали переменные)
* на DejaGNU пишим скрипт:
-- записать файл
-- считать
-- проверить - то ли мы считали
-- т.д.

И на пару суток все устройство на автоматическое тестирование. В результате будем неплохо представлять, что у нас с файловой системой.

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

По поводу аппаратных глюков - тоже выход. Например, мы можем автоматически протестировать несколько вариантов нашей проги, с разными задержками (условно). И потом по логам понять, что влияет на глюки.

"Руками" такое не повторить. Ну или ждать "благодарности" от клиентов...Качество кода - сложная вещь. Тут все начинается с Философии. И только потом уже дисциплина и тулзы. Собственно, о философии я и толкую.

угу. В варианте с компортом мы будем создавать свое уникальное творение и искать свои глюки. В варианте с симулятором к ним добавится поиск глюков самого симулятора
Не, безусловно в этом что-то есть, но когда встречается восторженный отзыв о чем-то, что собственно Вы (как я понял) сами не проверяли и не работали - я автоматом ищу минусы такого решения. Плюсы Вы и сами нам сообщите Пожалуй добавлю. Большая часть глюков возникает либо на непредвиденный user input, либо на непредсказуемое поведение железных устройств, подключенных к процессору. Если первое просимулировать еще куда ни шло, то со вторым намного сложнее. Представляете сколько времени уйдет например на написание компонета, имитирующего GPRS модем и его реальное поведение в сети ? И сколько бы этого времени ни ушло, этот компонент будет очень далек от реалий. Подобные примеры можно продолжать бесконечно. Отсимулировать устройство с 2-мя кнопками и LCD 2-х строчным - это запросто. А вот что-то серьезное.... очень сильно сомневаюсь

Итак, тема симуляции разделилась на две: полностью виртуальную и полунатурную.

Возможны следующие конфигурации:

(1) DejaGNU -> GDB -> виртуальный симулятор ядра (пример: PSIM)
(2) DejaGNU -> GDB -(COM | Ethernet)-> GDB Stubs на виртуальном симуляторе ядра + периферии (пример: SID)
(3) DejaGNU -> GDB -(COM | Ethernet)-> GDB Stubs на реальном железе
(4) DejaGNU -> GDB -(JTAG)-> реальное железо

Разработка идет "сверху".

(STAGE 1) Вначала прописываем каркас системы:
* разделение на модули
* поток данных между ними
* механизмы IPC и взаимодействия с API оси.

Для этого чего-то типа PSIM хватит за глаза - нам нужно ядро и таймер. Все остальное - "объекты в памяти". Одновременно на этом этапе начинаем писать test suite для модулей.

(STAGE 2) Затем делаем "болванки дров" будущего железа. SID вне конкуренции. На этом этапе пишем test suite для дров.

(STAGE 3) Потом переходим к реальному железу. Тут уже полный прогон всего наработанного test suite на реальном железе.

(STAGE 4) Специфическое тестирование - например, что-то глючит только в условиях кустомера. Ноут, JTAG хороший, и к кустомеру - гоняем тесты в его условиях.

DASM, спасибо ему, задал отличный вопрос: "А сколько Вы будете трахаться, чтобы получить реалистичную модель GPRS мудема со всеми его реальными глюками?" Ответ - нисколько!

(STAGE 1) - тут все понятно.

(STAGE 2) - пишем реальный код, но вместо PPP сокета используем "виртауальный сокет" из компекта SID
Members of this family of components perform I/O on a TCP socket and relay data across a pair of pins to some other component
http://sourceware.org/sid/component-docs/sid-io-socket.html
Отлаживаем сервер, который принимает наши данные.

(STAGE 3) Тут уже поднимаем какой-нибудь LwIP, и доводим его до ума. Если ранее интерфейс всего остального софта с PPP частью был продуман, то отладки всей остальной части проекта не нужно, нужно лишь после доведения PPP до ума прогнать написанные (и отлаженные!!!) ранее тесты.

(STAGE 4) Вот это самое интересное! Приходит кустомер и говорит - "а у меня в моем медвежьем углу глючит страшно!" Ноут, и, как описано выше, гоняем тесты прямо у кустомера. Поскольку к этому моменту компект тестов хорошо продуман и отлажен - вероятность выловить, что же у него глючит, высока.

Еще несколько мыслей.

В мире пЫсюкового программизма одиночки не катят. Даже если человек в одиночку делает продукт - 90% кода его продукта написано другими (либы, визарды и пр.) Качество такого кода - отдельный вопрос, оставим его пока в покое.

Огладываясь назад на 10 лет сушествования нашей конторы, могу сказать, что %70 кода, как минимум, либо одинаково, либо могло бы быть одинаково при наличии у нас знаний и опыта в те годы.

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

Единственная реальная возможность выжить после открытия шлюза (вступление в ВТО - если кто в танке) - это освоить технологию распределенной разработки и единого репозитария применительно к embedded задачам.

Для понимания, как это сделать, я и затеял разговор.

Мысль, конечно, красивая и правильная. Но: 1) большинство попадавшихся лично мне эмбеддеров - инженеры, умеющие программировать. При рассмотрении многих абстрактных вопросов (стиль, управление версиями, модульность) это сказывается. 2) так ли велико у нас в стране количество embedded проектов, где действительно нужна распределённая разработка...

Я сам такой. Потратил много времени, чтобы дойти до простых истин. Если свести все знания в единую систему - обучить можно кого угодно.

Просто хороших книг по методологии разработки ПО, для embedded систем в частности, ничтожно мало. И тема эта почему-то не популярна в дискуссиях.Таких проектов просто море.

При правильно настроенной методике разработки сидит ли девелопер за соседним столом, или в 5 часов лета от меня - мне безразлично.