Средства и методы разработки

eCos на ARM симуляторе SID, автоматическое тестирование при помощи DejaGNU - очень интересно!!! Есть у меня давняя мечта - научиться запускать eCos на симуляторе. Прелестей у такого решения очень много - и отладка логики проекта, и автоматический запуск test units, проектирование разделения функций между аппаратурой и железом (когда железа еще нет), и многое другое. Разумеется, симулятор нужен взрослый, "скриптованный", чтобы можно было написать скрипт - и поставить его на тестирование хоть на несколько суток. Как выяснилось - все уже готово! ============== Симулятор ARM (и не только) SID ============== Вот тут http://sourceware. …/2003-08/msg00274.html Обнаружилась очень интересная вещь: eCos and SID on ARM PID target HOWTO http://www.asisi.co.uk/ecos_sid.html Порт eCos, который там упоминается http://ecos.source …s/boards/arm-pid7.html Вот еще http://sourceware. …/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. …ponent-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. …ocs/sid-io-socket.html This component performs input/output on the standard input/output. http://sourceware. …docs/sid-io-stdio.html Основной кайф этого симулятора в том, что он симулирует полноценную систему, а не только сам процессор. При этом создание своих компонентов описано достаточно внятно - если писать модели для несложных компонентов - это это вполне подъемная задача. Список готовых компонентов тоже внушительный http://sourceware. …/plain&cvsroot=sid на его основе можно сделать чего угодно - все модели идут вместе с иходниками :) Скриншоты впечатляют http://sourceware. …screenshots/index.html Особенно этот http://sourceware. …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. …985634-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 …/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 воспитывает писать код: * модульный: разделять специфичные и неспецифичные вещи * портабильный - все должно быть настраиваемо и конфигурируемо * многократно использованый: если кто-то придумал хорошую "штуковину" -> ее начинают активно использовать -> быстро вылавливаются баги и придумываются новые фичи -> "штуковина" становится еще лучше. А это очень и очень правильно!!! Это неибежно приводит к повышению качества кода. Блин, ну почему нет учебников, где бы все это было подробно описано!!! Приходится по крупицам собирать инфу, до всего додумываться самому...