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

Ну что, давно я ничего взрослого не постил? Оно есть у меня! Виртуализируемая встраиваемая Ось: наш ответ копроэкономике. Пусть мы делаем некий индустриальный прибор с тиражами от 1к/мес. Который состоит из трех частей: • Некая hard RT подсистема, которая что-то там измеряет, вычисляет, принимает решение и выдает управляющие воздействия. Характеристическое время – микросекунды и менее. • Некая аналитическая подсистема, которая корректирует алгоритмы работы hard RT. Темп работы миллисекунда и более. Soft RT • Навороченная сетевая подсистема TCP/защита от сетевого хака/SNMP/SSH/SSL/FTP/Web сервак с гламурным контентом. RT в подсистеме никакого, чистая асинхронщина, но нужная надежная работа. Современный «обресурсенный» контроллер 2М FLASH/128 K SRAM / 100MIPS+ все это вытянет, при одном маленьком условии: кто-то напишет для всего этого безглючный софт. RT и soft RT подсистемы относительно просты, и их можно создать обычными embedded методами. Тем более, что люди, делающие такой прибор, хорошо понимают предметную область, и сумеют придумать эффективные алгоритмы тестирования и отладки этих подсистем. Что касается «сетевых наворотов», то тут все сложнее, и народ, который не спец в сетевом программировании, будет долго и нужно дебажить SSH при помощи JTAG. Есть некий «вроде бы путь» - взять готовые либы от «индусских говнокодеров» и надеяться, что оно заработает. Я ничем не могу помочь идущим по такому пути. Что касается Linux, то это весьма и весьма спорный путь. Идеология многопроцессорной дримборы («просто процессор» для Linux с сетью и микроконтроллер для RT) неплохо подходит для такого случая, но надежность и цена… FLASH контроллер – он все же надежнее всех этих SDRAM Linux, взрослые процессоры типа PowerPC с ECC на SDRAM жрут много, стоят еще больше. Если «обресурсенный» контроллер стоит $10 (сейчас в эти деньги влазит очень жирный камень при закупках от 1к/мес), а «правильная Linux дримборда» стоит $30, то при тиражах 1к/мес и более я лично буду сильно думать. Вопрос, как всегда, в стоимости разработки софта для навороченного контроллера. Я предлаю поступить так. Пусть будет простая, проверенная и хорошо подвергающаяся модификации Оська типа uCOS. Пусть все в системе работат как объекты под управлением RTOS. Драйвера, обработчики прерываний, апликухи. Весь обмен только средствами Оси. Пусть у процессора будет нормальная внешняя шина, и DMA, который эффективно с ней работает. Чтобы обмен 10Мбайт/сек через эту шину отжирал не более 10% производительности проца. В качестве канала связи с писюком выбираем чипы от FTDI или гигабитный Ethernet. Первое при правильном программизме дает чуть ли не 30 Мбайт/сек, второе – чуть ли не 100. Вопросы канального уровня пока не рассматриваем. Ставим FPGA, которая является интеллектуальным мостом между контроллером и писюком. Т.е сформировал проц структуру в памяти, через DMA сунул ее в FPGA, там оно упаковалось, добавилось CRC, и аппаратно пихнулось в писюк. На стороне писюка все программно распаковалось и передалось программе. Обратно аналогично – писюк упаковал, пихнул, FPGA приняла, распаковала, и по DMA оно всосалось в контроллер. При 10 Мбайт/сек в обе стороны и размере типовой транзакции 1 кбайт (очень много для реальных условий) мы будем иметь латентность распространения через такой канал от 100 мкС, что приемлемо для многих применений. Модифицируем ОСьку. Вернее, пишем ее заново . Чтобы она могла работать в режиме «двух копий». Есть одна копия Оси, которая живет в контроллере. У нее есть свои задачи, живущие там же, и локальные объекты, которые замкнуты только на Ось и на локальные задачи. Есть другая копия, которая живет «где-то», со своими локальными объектами. И есть глобальные объекты, которые синхронизируются между ними. Локальное API Оси учитывает гонки синхронизации для глобальных объектов (на уровне проектирования идеологии), но все это скрыто внутри Оси – прикладухе пофиг, с локальным или глобальным объектом она имеет дело. Пусть у нас будет хороший программный симулятор системы команд контроллера. Который симулирует ядро, память (разных классов), прерывания и DMA. Симулятор быстрый и удобный: с программной реализацией RDI, например (чтобы дебажить прямо из IDE контроллера), и со собором статистики – сколько раз обращались к каждой ячейке памяти. К симулятору прилагаются тулзы для полного профайлинга, сбора данных по памяти – наехал ли у нас стек на данные или нет и пр. Симулятор доступен в исходниках. И к нему мы прикручиваем интерфейс нашего канала связи. Т.е. послал «железный» контроллер структуру – через задержку «виртуальный» контроллер ее же и получил. Далее на симуляторе мы пускаем вторую копию Оси и прикладухи под ней же. Только асинхронную и soft RT части. Что нам это дает? 1. В отличие от синтетических портов, который я тут много раз описывал, это исключает все нюансы конкретной кривой релизации С для контроллера. Тулчейн для разработки целевого кода один и тот же. (Кривизну так не исключить, оно она будет одинаковая для имитатора и целевой системы, и это дает шанс ее обороть). 2. В силу кастомизируемости симулятора и мощи писюка дебажить код куда приятнее. Например, не меня исходников Оси, можно написать перехватчик для каких-то особых ситуаций, запустить его в отдельном треде на многоядерном писюке, и он, анализируя данные управляющих структур Оси (их адреса после линковки известны – значит, симулятор можно настроить на эти ячейки памяти), сделает остановы по условиям или дамп чего-то там – чтобы потом понять, как же оно пришло к падению. 3. Ситетический подход никто не отменял. Ко всей этой красоте можно прикрутить один из процессов, который реализован в «матлабе». И после отладки функционала втаскивать его в С. 4. Железо и программа живут параллельной жизнью. В силу осецентричности процесса на железной плате может быть один проц, в симуляторе – другой. Еще не существующий в кремнии :). И при помощи того симулятора мы тут же поймем – а насколько эффективен новый проц для наших задач :). 5. Что касается различных ГУЕв, то тут вообще простор для творчества. Имея скорость выгрузки данных из писюка 30 и более Мбайт/сек, мы можем тупо выливать кадр в целевой процессор, и он с двойной буферизацией отображает его на экране. VGA экраны пойдут на ура – мечта гаджетостроителей. А в симуляторе целевой код на целевом процессоре патчит пиксели прямо так же, как это будет происходить в реальной жизни в будущем контроллере. Очень удобно отрабатывать разные ускорители. Типа есть библиотека графических примитивов. Часть из них меняем на симуляторы аппаратных ускорителей. Прогоняем набор тестов и сравниваем – а что там дал тот или иной ускоритель при отрисовке тестового набора HTML страниц :). Если есть предложенного мамонта по частям, то небольшая команда ~ за год сможет сделать базовый инструментарий (параллельно с текущими проектами, чтобы было на что жить), а потом можно бабло зарабатывать по взрослому :)