"Скриптованный" симулятор AVR

Ответить

Evgeny_CD 0

11 августа, 2006

Опубликовано 11 августа, 2006 · Жалоба

Нужен симулятор для AVR, который бы полностью управлялся из вне через систему команд. Т.е. чтобы можно было автоматически прогонять test suite:

* собрали проект

* загрузили в симулятор

* запустили, дошли до точки останова

* прочитали/записали память, регистры проца и симулируемой периферии

* повторили

Симулировать над ядро, прерывания, таймера, FLASH (включая само-программирование), EEPROM, UART. Все остальное желательно, но не обязательно.

Жалетельно, чтобы был некий "членомер" для измерения "реального времени". В циклах процессора, например. Чтобы грубо оценивать время исполнения.

Также желателен интерфейс для написаниях своих компонентов. Либо виртуальный компонент - регистр <-> (сокет | файл): транзакция по некоторум адресу в памяти "маршрутизируется" в сокет или файл.

GUI и прочая "юзеровщина" волнует слабо.

Win32, Cygwin. Можно и pure Linux, но не так интересно.

Что есть подобного?

http://www.amctools.com/atmel.htm - насколько оно нормально работает? Не нашел доку по нему - там внешнее управление через скрипты есть?

Мои взгляды на автоматическое тестирование применительно к embedded устройствам:

*** TDD (Test-driven Development) применительно к embedded системам: похоже, я догнал, как это должно быть устроено.

http://www.caxapa.ru/echo/arm.html?id=63285

http://electronix.ru/forum/index.php?showtopic=18859

*** Развитие идей по упрощенной отладке.

http://www.caxapa.ru/echo/arm.html?id=63474

http://electronix.ru/forum/index.php?s=&showtopic=18859

Цитата

Поделиться сообщением

Ссылка на сообщение

Поделиться на другие сайты

bodja74 0

11 августа, 2006

Опубликовано 11 августа, 2006 · Жалоба

Читал,читал...

Но я так и не понял основной сути,для чего это все нужно?

Вы сделать это хотите для себя?

Или собрать коллектив единомышленников?

Или просто потренировать мозги ради интереса?

Чем Вас не устраивает допустим какой нибудь виртуальный симулятор?

Тут народ вообще обходится printf ,а мне и не влом ледом моргнуть для проверки прохождения кода

или правильности результата.

Цитата

Поделиться сообщением

Ссылка на сообщение

Поделиться на другие сайты

Deka 0

12 августа, 2006

Опубликовано 12 августа, 2006 (изменено) · Жалоба

Думаю что всё это необходимо для автоматического тестирования больших проектов. Применение такого симулятора очень хорошо укладывается в "экстремальное программирование". Жаль не знаю такого. Думаю, что весчь будет полезная. После прогона тестов даёт уверенность в том, что добавляя что-то новое или меняя существующее не пострадали остальные функции. Правда надо много тестов писать и как можно подробнее.

Изменено 12 августа, 2006 пользователем Deka

Цитата

Поделиться сообщением

Ссылка на сообщение

Поделиться на другие сайты

big256 0

14 августа, 2006

Опубликовано 14 августа, 2006 · Жалоба

VMLab довольно мошная штука - в связке с винавром или кодевиженом(делаете на выходе кофф файлик и вперед).

Можно применять и с Иаром , но там , покрайней мере в версии 4.11 не генерятся кофф файлы, соотв можно работать с хексами - но это хуже :( (может в более новых версиях Иара уже сделали кофф ?!)

Глюков в ней замечено мало было и те не критичные - помню варннги были на ресет вотчдога(хотя он был выключен :)

Цитата

Поделиться сообщением

Ссылка на сообщение

Поделиться на другие сайты

Evgeny_CD 0

14 августа, 2006

Опубликовано 14 августа, 2006 · Жалоба

Вот, на Сахаре подсказали (bialix -супермегареспект!): AVRORA.

http://compilers.cs.ucla.edu/avrora/

Avrora, a research project of the UCLA Compilers Group, is a set of simulation and analysis tools for programs written for the AVR microcontroller produced by Atmel and the Mica2 sensor nodes. Avrora contains a flexible framework for simulating and analyzing assembly programs, providing a clean Java API and infrastructure for experimentation, profiling, and analysis.

Вот краткое описание их идеологии:

Nonintrusive Precision Instrumentation of Microcontroller Software

http://compilers.cs.ucla.edu/avrora/papers...s_lctes2005.pdf

http://compilers.cs.ucla.edu/avrora/instru...instrument.html

Using GDB with Avrora - ваще мечта

http://compilers.cs.ucla.edu/avrora/gdb.html

Control Flow Graph Tool

http://compilers.cs.ucla.edu/avrora/cfg.html

Stack Checker Tool

http://compilers.cs.ucla.edu/avrora/stack.html

На AVRORA эмулируют в том числе TinyOS

TinyOS + Avrora Quick Start Guide

http://lists.ucla.edu/pipermail/avrora/2006-July/000447.html

http://www.cs.utah.edu/~regehr/tos_avrora.html

Схема борды, которую симулируют

http://www.tinyos.net/hardware/design/ORCA...06-01ACLEAN.pdf

на основе чипа

http://www.chipcon.ru/CC1000.htm

AVR GCC - брать тут

http://winavr.sourceforge.net

http://klen.org/Projects/Avr-gcc/avr-gcc_last_build.html

TinyOS - достаточно своеобразная штука. Я на нее косо смотрю, поскольку она не на C создана, но идеи в этой ОСи интересные есть.

http://www.tinyos.net/

TinyOS is an open-source operating system designed for wireless embedded sensor networks. It features a component-based architecture which enables rapid innovation and implementation while minimizing code size as required by the severe memory constraints inherent in sensor networks. TinyOS's component library includes network protocols, distributed services, sensor drivers, and data acquisition tools – all of which can be used as-is or be further refined for a custom application. TinyOS's event-driven execution model enables fine-grained power management yet allows the scheduling flexibility made necessary by the unpredictable nature of wireless communication and physical world interfaces.

The TinyOS system, libraries, and applications are written in nesC, a new language for programming structured component-based applications. The nesC language is primarily intended for embedded systems such as sensor networks. nesC has a C-like syntax, but supports the TinyOS concurrency model, as well as mechanisms for structuring, naming, and linking together software components into robust network embedded systems. The principal goal is to allow application designers to build components that can be easily composed into complete, concurrent systems, and yet perform extensive checking at compile time.

Getting Started with TinyOS and nesC

http://www.tinyos.net/tinyos-1.x/doc/tutorial/lesson1.html

TinyOS 2.0 Tutorials

http://www.tinyos.net/tinyos-2.x/doc/html/tutorial/

nesC is a compiler for a new language (based on C) designed to support the TinyOS project. nesC provides several advantages over the existing TinyOS compiler infrastructure: nicer synytax, complete error reporting, and interfaces to group related functio

http://sourceforge.net/projects/nescc/

Описание языка

http://www.tinyos.net/tinyos-1.x/doc/nesc/ref.pdf

Интересно, что Зюбин скажет по поводу этого nesC

http://reflex-language.narod.ru/ - его творение...

Теперь зачем это надо.

Отладочный printf был, есть и будет. Аминь.

Секту свою пока открывать и создавать не намерен - учение еще не до конца готово :)

Интеллектуальный онанизм - не мой вид спорта.

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

Применительно к AVR при помощи AVR ISP или AVReal (ну и COM порт на интерфейс взаимодействия с пЫсюком) можно без проблем построить систему автоматического тестирования компонентов ПО. 10к циклов записи - ну и бог сним, признаем контроллер расходным материалом. :)

Но очень хочется nonintrusive способа посмотреть, что творится в контроллере. AVR JTAG - это хорошо, но все равно он будет вносить некоторое возмущение в работу. Т.е. даже если с самим ядром мы будем нормально работать, но время для периферии не остановить, и как только мы "заморозили" процессор - все, процесс нарушился.

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

Хочется виртуальности, чтобы вместо какого-нибудь контроллера поставить модельку, которая мониторила работу ядра с ним. Профайлер продвинутый и т.д.

Все это в AVRORA есть. Жаль, она на джаве написана - так нехотелось разбираться еще с одним языком программирования....

Что касается гуевых дебуггеров - тут нет никакоего противоречия со скриптованными.

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

Что касается самих тестов - тут важен вопрос организации процесса. Писать их на том же С - гупость.

Есть готовые тулзы

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.

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

В общем, нет ниакакой проблемы на Python или любом другом "любимом" высокоуровневом язке написать свой фрейм ворк для тестов. Можно за основу взять PyUnit

http://pyunit.sourceforge.net/

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

Мои посты по тематике тестирования (и связанными с нею темами)

Продвинутая система тестирования софта:

http://www.caxapa.ru/echo/arm.html?id=48364

http://electronix.ru/forum/index.php?showtopic=11570&hl=

eXtreme Programming

http://www.caxapa.ru/echo/arm.html?id=49785

"Питон для Си-программистов"

http://www.caxapa.ru/mcu/wwwboard.html?id=57403

http://www.caxapa.ru/mcu/wwwboard.html?id=57960

http://www.caxapa.ru/mcu/wwwboard.html?id=57905

Концептуальный вопрос по написанию прототипа в среде "похожей на embedd Ось" (Ch и не только).

http://www.caxapa.ru/echo/arm.html?id=58541