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

Ну есть конфигураторы периферии, как у того же Cyan-а или IAR-а или Cypress-а и т.д. Но это тулсы исключительно для студентов. Они пытаются скрыть от юзеров особенности периферии, но и сразу же лишают гибкости. На примере того же Ethernet контроллера. Допускаю существование такого тулса который сразу создаст исходники из десятка процедур, типа: - послать пакет в связный список отправки, - ISR которая непосредственно отправляет пакеты из списка - ISR которая принимает пакеты, оповещает основную задачу, фиксирует пакеты в списке приема - обработчики всяких ошибок. и т.д. Никаких битов и регистров, все чинно-благородно. Но! У юзера есть ось, и куда ему эти нереентерабельные (а оно так и будет) функции всунуть. Хорошо, тулза знает об осях и использует функции переходники в стиле POSIX, которые надо еще потом самому заполнить под свою ось. Тут сразу проблемы встают колом. Возникает как минимум проблема лишних копирований буфера. Скорость TCP от этого автоматически деградирует. Взрослые пацаны используют технику zero-copy. Но эта техника требует ломки всех общепринятых методов передачи данных через очереди или связные списки буфферов. А ведь еще есть технология VLAN которая требует мультиплексирования на пакетов на уровне ISR. И еще есть техники ускороения обмена по Ethernet основанные именно на специфике некоторых контроллеров Ethernet-а. Как их реализовать в универсальном конфигураторе? Дальше больше. Драйвер Ethernet-а не юзает только один контроллер Ethernet-а, ему нужны сервисы точных таймингов, т.е. надо сконфигурить еще и какие-то таймера и ISR к ним. А еще DMA тут же приплетается. Опять конфигурируй. Как и таймеров так и каналов DMA есть весьма ограниченное количество и они все на расхват другими драйверами. А еще у них есть приоритеты. Неправильно выбрал приоритет и привет... тормоза обеспечены если вообще заведется. А еще есть конкуренция за мультиплексированые внешние пины для периферии. Скажем понравился вам таймер для Ethernet-а, а оказывается он еще нужен для зумера и только он для него и подходит поскольку имеет свободный внешний пин, а тут еще софтовый UART тоже потребовал пин от этого таймера и понеслось... И как конфигуратор сможет оптимально распределить все эти ресурсы? Допустим смог, очень умный оказался. Но! В течении жизненного цикла исходников их не раз и не два приходится рефакторить. К конфигураторам же обратной связи нет. Если изменили исходники, то конфигуратор к ним уже не применишь. И опять конфигуратор в пролете. Моя идеология остается прежней: метод тыка самый эффективный, ничего не симулируем (речь веду только о драйверах), все усилия прилагаем на поиск платформ с наиболее продвинутыми средствами внутрисистемной отладки. Например Ethernet контроллеры Freescale имеют пару десятков аппаратных счетчиков всевозможных ошибок Ethernet-а. Понятно, что имея такие счетчики установить причину ошибки гораздо легче чем в контроллере какого-нибудь LPC. Ну и конечно выбираем такой софт чтобы цикл от исправления до отладки был минимальным. Это - скорость компиляции, линковки, загрузки кода, и гибкость брекпойнтов.