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

Dream Platform II, или нафига я за RTEMS взялся. ************* Предыдущие обсуждения по теме ************* Маркетинговое исследование в догонку к ТЕОРЕМЕ http://www.telesys …/messages/105965.shtml Фундаментальня размышлизма о RTEMS. http://www.caxapa. …echo/arm.html?id=64965 http://electronix. …ex.php?showtopic=19756 Microsoft's.NET MicroFramework, Даешь "контроллеры светодиодов" с мегабайтом кода! http://electronix. …ex.php?showtopic=18948 http://www.caxapa. …echo/arm.html?id=63502 ************* Где-то год назад я впервые сам для себя сформулировал идею Dream Board. Тогда был написан этот текст, который по разным причинам не был опубликован. Теперь я рашил исправить этот пробел - опубликовать его, а заодно и новые мысли, коих за год появилось предостаточно. Исторический текст, написаный 18 июля 2005 года, публикую после этого поста без правок. Видно, как за год модернизировались мои взгляды. :) Задача, стоящая перед Dream Platform - это создать эффективную среду разработки embedded устройств, позволяющую: * reuse кода * комфортная среда исполнения программы - OS и другие "стандартные сервисы" * "разделение мышления" на системный и прикладной уровни - чтобы при решении целевой задачи можно было оперировать "обобщенными сущностями", оптимизированными под эту задачу, а не катеогриями прерывание, регистр и пр. - с другой стороны, чтобы при написании дров не думать о целевой задаче. Сейчас Dream Board выглядит так: ### Аппаратура * 32 битный CPU - ARM, MIPS, ColdFire, PPC -- x86 - "фтопку" * Стандартные контроллеры -- таймера -- I2C -- SPI -- UART -- Ethernet -- SD/MMC - жалательно -- NAND FLASH - желательно * DMA с обработкой запросов по внешней шине * FPGA на шину -- специализированные контроллеры -- мелкие процы типа PicoBlaze для "умной периферии" * по необходимости - мелкие периферийные "сопроцессоры" типа ATmega48, Luminary, LPC2101. ### Софт * asm, дрова * C, RTOS; "базовые сущности" как процессы под управлением RTOS. * Скриптовый движек, который оперирует "базовыми сущностями" * симулятор всей системы на PC * среда для полностью автоматического тестирования софта. Обо всем этом кусками уже писал, повторяться не буду. ### Взаимодействие скриптового движка с "базовыми сущностями". Центральное место! Долго я думал над этим. Понятно, что можно взять и прикрутить C код к скриптовому движку (все серьезные движки это позволяют сделать). Но возникает задача тестирования и пр. !!! Я тут меня осенило !!! Сокеты!!! Если есть нормальная ОСь, то ее процессы могут общаться между собой через сокеты. Будут некоторые накладные расходы, но ниже понятно, почему на них можно пойти. Но ведь сокеты могут быть и на разных машинах!!! Т.е. я делаю RTOS + "базовые сущности" на целевой плате, а скриптовый движек для этого ставлю на пЫсюке. При этом: * не возимся с портированием движка на целевую платофрму вначале * можно экспериментировать - выбирать скрпитовый язык, который лучше всего подходит для целевых задач, а затем его уже портировать * среда для автоматического тестирования получается как бы сама собой :) Сокеты есть во всех современных скриптовых языках, в Matlab и пр. Т.е. можно такую среду для тестирования "залудить"... В частности: LuaSocket is the most comprehensive networking support library for the Lua language. It provides easy access to TCP, UDP, DNS, SMTP, FTP, HTTP, MIME and much more. http://luaforge.net/projects/luasocket/ http://www.cs.prin …rofessional/luasocket/ И вообще http://luaforge.net/ - занятно место! Вот только некоторые проекты: ############################################################################### LuaFileSystem is a Lua library developed to complement the set of functions related to file systems offered by the standard Lua distribution. LuaFileSystem offers a portable way to access the underlying directory structure and file attributes. http://www.keplerp …ect.org/luafilesystem/ ############################################################################### RemDebug is a remote debugger for Lua 5.0 and 5.1. It lets you control the execution of another Lua program remotely, setting breakpoints and inspecting the current state of the program. RemDebug can also debug CGILua scripts. http://www.keplerp …rg/remdebug/index.html ############################################################################### Copas (Coroutine Oriented Portable Asynchronous Services) offers a dispatcher that can be used by socket request/response server programs. Although the first uses of Copas are HTTP oriented, it can be used for other protocols like FTP, SMTP etc. http://luaforge.net/projects/copas/ ############################################################################### LuaTask is a portable multithreading library for Lua 5, with message queues. http://luaforge.net/projects/luatask/ ############################################################################### CGILua is a tool for creating dynamic HTML pages and manipulating input data from Web forms. It is simple but powerful, allowing complex tasks to be carried out with minimum effort. http://luaforge.net/projects/cgilua ############################################################################### Xavante is a Lua embeddable standalone Web server based on Copas and coxpcall. It handles HTTP 1.1 requests and uses CGILua 5.0 as the native template engine. http://luaforge.net/projects/xavante/ Xavante is a Lua HTTP 1.1 Web server that uses a modular architecture based on handlers. Xavante currently offers a file handler, a redirect handler and a CGILua handler for general files, URL remapping and CGILua 5.0 scripts respectively. A WebDAV handler is in the works. http://www.keplerproject.org/xavante/ ############################################################################### Таким образом, требования к ОСи - качественная реализация BSD Sockets. uCOS + LwIP - это уже немного не тот уровень. Остается только eCos или RTEMS. Поскольку для RTEMS есть готовые порты на все интересные процы средного и тяжелого классов - то она и победила :) ### Еще одно центральное место. DotGNU Portable.NET http://www.dotgnu.org/ Понятно, что в силу POSIX'ности портировать его на RTEMS будет гораздо проще. А это даст возможность для разработки "верхнего уровня" нашей embedded железяки использовать всю мощь M$ тулзов! Более того, описанная выше идея "внешней сокетной отладки" позволит проводить тестирование в реальном времени. Затраты процессорного времени на "внешние соткеты" гораздо выше, чем на "внутренние", но зато скриптовый движек не нагружает процессор. Так что фактически при такой отладке мы будем хорошо эмлировать автономную систему. Ну а отллаживаь на пЫсюке - одно удовольствие - тут и файловая система, и всякие рисровалки-отображалки, и языки любые. Кайф! ВСЕ! СПУСТЯ ГОД КАРТИНА В МОЕЙ БАШКЕ ОКОНЧАТЕЛЬНО СЛОЖИЛСЬ! АМИНЬ!