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

"Open You Mind" > Как то пришлось портировать движок распределенных систем CORBA для > uCOS. Исходник был сделан одновременно и для Windows и для uCOS. > Очень удивило, что конфигурация исходников проводилась с помощью > нескольких простых макросов. Для каждого сервиса Windows системы > обеспечения мультизадачности была найдена адекватная функция в uCOS > без всяких дополнительных наворотов, функций прокладок и т.д. . Т.е. > портирование с Windows на uCOS можно было сделать простой > механической заменой некоторых вызовов. Это к сравнению сложности > портирования на uCOS и eCos. Сильно! Воистину, "оптимизирующий программер - самый главный add-on для любого компилятора". > Также портирование uCGUI сводилось лишь к созданию для него своей > задачи и все, больше исходники GUI ни в чем не модифицировались > из-за RTOS. > C файловыми системами также, если не нужен был жесткий realtime. Со > стеком TCP была похожая ситуация. Т.е. uCOS совсем не страшен тем, > что он такой голый. Зато он легко профилируется, что очень важно для > жесткого реалтайма. Конфигурируемость - да, это колоссальный плюс uCOS. Но asm в таком случае просто бесконечно конфигурируем. :)) Просто хочется не утонуть в ручной работе, пусть простой и понятной. Тот же uCOS не имеет понятия дров на уровне OS, много другой системщины опущено. > Но когда нужно было добиться стабильной работы системы потянулись > месяцы. А все из-за того, что компиляция долго длилась. Одна > итерация исправления кода могла длиться четверть часа. Копмилятор > мог делать ошибки, а проверить на другом компиляторе было невозможно > из-за кривого выбранного диалекта. JTAG-а не было, симулятор был > отвратительный, а отладка через монитор была очень медленной. Это и > есть те ощибки выбора платформы которые проявят себя когда вы уже > втянетесь в проект. Ужас! Хочется верить, что к этому моменту логика приложения была отлажена на писюке, и тут уже была борьба только с нюансами портирования и "дровами" uCOS для всякой периферии. > Поэтому думаю, что легче и безопасней унифицировать хардварную > платформу. И ARM-ы лучше всего подходят. Это есть большой философский вопрос. Каждая архитектура имеет пределы масштабирования. Тот же ARM 11 пока не виден в виде готовых чипов, а MISP пока недоступен в виде LPC2XXX. Embedded проц в 90% не должен быть суперскоростным - 200 МГц ARM за глаза хватит для большинства задач (при условии наличия DMA и адекватной периферии - тупым IO можно и гиговый проц загробить). "Тяжелые" алгоритмы надо пускать на DSP и не выпендриваться. Но вот многопроцессорность (или хотя бы логичная возможность такой) - очень важная вещь. Если мы берем обычный ARM, то для организации эффективной многопроцессорности придется сделать свой аналог PCI, т.е. придется повести крутой и совершенно ненужный рисеч. Я знаю только один не очень дорогой и доступный ARM с PСI - netsilicon NS9750. Монстры от Intel (IO процессоры с ARM и PCI - на них RAID любят делать) отпадают по причине цены и излишней монстровости. Если мы берем проц с PCI, то мы решаем массу задач. Тот же OMAP5912 хорош всем, кроме цены и гибкости. Если мне не хватает ARM 720, я возьму MIPS от IDT с PCI (20$ в мелком опте) + FPGA на шину ($10) для изготовления микроконтроллерной периферии, которую в MIPS не завезли. Если мне и этого не хватит, я воткну _второй_(3...до 5 штук) такой же проц в PCI. Не хватит - BF535 с PCI (~40 в мелком опте). И этого мало - TI C67 и пр. монстры. При этом основная платформа будет меняться очень слабо, а сопроцессор - его все равно разрабатывает отдельный человек. Вот за такой плавный переход ARM -> MIPS, ARM -> PowerPC я и воюю. По симуляторам. MIPS, PowerPC имеют очень хорошие, проверенные в деле симуляторы. Они бутят Linux | FreeBSD без проблем. Их несколько. Тот же http://www.gavare.se/gxemul Для ARM мне пока известен один такой - http://www.skyeye.org/index.shtml В общем, к чему я веду? Если надо создать девайс размером со спичечный коробок, то выбор камня первичен. Если устройство имеет размер хотя бы видеокассеты, то нужно сделать простую операцию "Open You Mind". При современной цене 4-х слоек 4 класса (150 за образцы, менее 5$ за дм. в серии от 50 штук), SDRAM (64Mbit менее 2$), FLASH (1Mbyte менее 2$), FPGA (от 9$ - много ли надо ресурсов, чтобы сделать таймер или SPI, который нужны именно для специфической задачи - зато сколько программных ресурсов можно сэкономить) _ВЫБОР ПРОЦЕССОРА ВТОРИЧЕН_!!! И вообще, никто не мешает сделать на 4-х слойке ядро, и сменную плату периферии на двухслойке (между ними какой-нибудь проверенный разъем типа DIN) (все высокоскоростные сигналы живут только в ядре, на разъем - только I/O). А поскольку стоимость почти любой разработки определяется стоимостью разработки софта, то программную платформу надо выбирать из этого. eCOS хорош тем, что даже в однокристальных вариантах он позволяет работать при RAM более 64К (LPC2106, SAM256). А грядущие варианты с 128 или 256К ОЗУ на кристалле вообще будут идеальной платформой для него. LPC22xx + 1MB SRAM вообще позволит творить что угодно под eCOS. Повторюсь, Linux на LPC2106 не портировали (пока?) :)) Ау, любители бесплатного сыра в мышеловке по кличке IAR, Вы готовы хотя бы попробовать MIPS?