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

Dream Board - текст от 18 июля 2005 года. Часть I Dream Board - продолжение ТЕОРЕМЫ >>>>>>>>>>>> краткое содержание предыдущих серий <<<<<<<<<<<<<<<<<<<<<< В хронологическом порядке "Членомер" производительности микроконтроллеров http://www.telesys …/messages/104416.shtml http://forum.elect …dex.php?showtopic=6279 http://www.caxapa. …wwwboard.html?id=35158 ТЕОРЕМА о ненужности и бесполезности ((С) на название - великий VLV) x86 архитектуры во встраиваемых приложениях http://www.telesys …/messages/105243.shtml http://forum.elect …dex.php?showtopic=6352 К вопросу о теореме http://www.telesys …/messages/105467.shtml Сертификация ОСей http://www.telesys …/messages/105851.shtml Кто чего к ТЕОРЕМЕ добавит? http://www.telesys …/messages/105876.shtml Маркетинговое исследование вдогонку к ТЕОРЕМЕ http://www.telesys …/messages/105965.shtml Втискивание MicroBlaze в различные Spartan 3 http://forum.elect …dex.php?showtopic=6459 Средства разработки для MicroBlaze, NIOS http://forum.elect …dex.php?showtopic=6456 =========================================================================== Меня всегда интересовал ___системный___ способ решения следующей проблемы. Есть контроллер (например, связной, который передает / принимает битики по каналу). У него есть часть (будем называть ее "целевым ядром"), которая жестко привязана к real time, и есть куча всего остального (интерфейс конфигурирования, протоколы высокого уровня, FLASH всякие разные для логгинга и пр.), которая к нему отношения не имеет. Целевое ядро почти всегда простое. Его хоть на C пиши, хоть на ASM - все равно "два экрана". Его можно написать или переписать под любой процессор, у которого хватит скорости - не вопрос. Если же нужно что-то серьезнее, тот тут без OS не обойтись (ее можно купить/спереть, самому написать простейший task switcher - суть от этого не изменится). Если это целевое ядро пытаться повесить на RTOS, то: * нужно специально исследовать вопрос, а всегда ли успеет? * сложность проекта сильно возрастает, и появляется очень много лишних связей (я не хочу знать и думать о том, что у меня делает коммуникационная часть системы, пока я свои битики по таймеру вывожу!) * стандартных сервисов этой RTOS может не хватить, значит придется либо докупать модули (не все есть в free / warez варианте), либо дописывать. Есть RTOS всякие разные (их так много, что можно найти все, что угодно). Они либо очень RT, но тогда у них хреново с сервисами, либо "не очень" RT, у них очень здорово с сервисами, с периферией (и никак с RT). Linux - хороший представитель второго класса. Мне очень хочется иметь "шизофреническое" решение. Чтобы, когда я пишу ядро, то у меня не было ничего ОСевого. Как класс. Когда же я пишу все остальное - мне нужна надежность, удобство писанины, отладки и пр., и я не хочу даже думать о том, а что будет, если я вызову функцию - хватит ли у меня места в памяти, а на сколько она запретит прерывание и т.д. Я хочу, чтобы у меня было много процессов, чтобы они общались между собой в лучших традициях Unix. IMHO - в Linux все межпроцессное взаимодействие давно отлажено, все эти streams вылизаны - можно расслабиться и тейкать фан. Понятно, что на фоне этого *nix совершенства относительно неплохие сервисы uCOS выглядят как неудачная шутка. Кроме того, все алгоритмические вещи я хочу отлаживать на PC - гораздо проще и удобнее. А что касается RT - тут симулируй, не симулируй - все равно кончается отладкой целевой платы (если не хочешь вначале отдебагерить симулятор). Еще мне очень хочется простоты и понятности. Оттестировать целевое ядро, как следует вылизать код – все это происходит естественным путем в процессе решения целевой задачи. Сделать то же, например, "подключив" к проекту uCOS - куда сложнее. Анализировать ядро Linux я точно не буду :). С другой стороны, сами по себе OS, как правило, отлажены. Если программа работает в виртуальном режиме, напрямую в железо не лазит, криворукие дрова не использует – Ось будет жить долго и счастливо. Вот и хочется совместить несовместимое. Вдоволь наизучавшись ОСей всяких разных, я понял, что красивого решения нет (не будет???). Нельзя скрестить ужа и ежа, и не уколоться. Не мне первому ( :) ) пришла в голову мысль разделить задачи по процессорам. Я лишь попытался свести мысль к конкретной плате, которую и предлагаю (виртуальную пока (?) плату) на суд читателей. Итак, требования к Dream Board. ***1. Недорогая борда с понятными, удобными и бесплатными средствами разработки. ***2. Рост возможностей борды должен оборваться в точке перегиба - когда следующая фича резко повышает ее себестоимость ***3. В марках выбранной платформы софт должен выжимать из аппаратуры 105% возможностей! ***4. Большой ОСью должен быть Линух, а "малой" вообще быть не должно (в идеале). Далее процессор целевого ядра - SCPU (Slave CPU), "большой процессор" - LCPU (Linix CPU). К вопросу об оптимальности по цене. В понятие недорогая входит не только цена платы, а то, сколько всего ресурсов будет потрачено до появления версии 1.0 изделия. Если у кого-то есть готовый Заказчик, который отфинансирует НИОКР - он может не читать. Для всех остальных (IMHO) очень актуально - с минимальными усилиями сделали прототип, проверили его (а вообще идея то нормальная или как???). Не получилось (заказчик не выполнил обещание купить партию, идея не прокатила) - не жалко, затраты были маленькие (и если Вы не глупы, Заказчик покрыл их при заказе первого изделия). В свете этого, удобство среды разработки ПО является главнейшей основой этого проекта. Не будут вдаваться в дискуссию, выскажу свою точку зрения - GNU есть очень хороший выбор для данной задачи. * море target платформ всяких разных в рамках одного инструментария * host платформы разные, включая Linux/Win * полноценный инструментарий * сейчас уже стала появляться нормальная дока http://www.olimex. …t%20with%20Eclipse.pdf * сохранение (С). Если в Вашем исходнике нет ничего из GNU/GPL исходников, и внутрь Вашего статического объектного файла не прилинковано ничего GNU/GPL (пусть либы живут в другом статическом объектнике) - Ваши исходники Ваша собственность. * кумулятивность обучения. Последнее очень важно! Разработка есть процесс непрерывного обучения и самосовершенствования. И в варианте GNU тулчейна, IMHO, полученные знания удобнее всего конвертировать под что угодно. Надо будет почему-то использовать другую среду разработки - пересядете без проблем. Что касается "престижа", то замечу, что в последнее время очень много дорогих, коммерческих вещей стали делать в расчете на IDE http://www.eclipse.org/. Altera NIOS II, http://www.ecoscentric.com (контора, которая за деньги продает собранные и настроенные eCOS под разные платформы - 2.5k фунтов, между прочим!) - они что, будут юзеров пичкать хламом в надежде немного сэкономить? ******** Блок схема ********* На мой взгляд такая борда должна состоять из двух АРМов. Тулчейн один, и вообще ARM платформа не самая плохая. *** Выбор LCPU **** Ресурсы проца и соответствующей части платы * ARM920+ или ARM720, с MMU - чтобы Linux работал очень устойчиво, и нельзя было "шарахнуть по памяти" * SDRAM - 16, еще лучше 32 - цена вырастет несильно, а польза может быть большая. 64 Mbyte, IMHO перебор. * FLASH – 4Mbyte (~2…3 под образ линуха и 1…2 под JFFS какой-нибудь для пользовательских зачад. * Ethernet - очень хорошо, чтобы был интегрированный (DMA и т.д.) * RS-232/422/485 (конфигурируемо джумперами) - 2..4 штуки * USB 1.1+ (2.0 Highly Recommended) Host - 1...2 штуки (USB FLASH брелки цеплять и прочую периферию) * I2C - пусть и не real time, очень полезно бывает прицепить какой-нибудь IO expander. Должны быть готовые функции для работы с ним * SPI - аналогично * разъем расширения типа PC-104 - чтобы можно было на шину девайсы подключать - когда real time не важен, но скорость обмена важна, либо нужно "по бырому" подрубить нестандартную периферию. Linux, boot loader, патченный тулчейн должны быть. Cirrus Logic EP9302 - что-то типа http://www.embedde …epc/ts7250-spec-h.html http://www.embedde …epc/ts7200-spec-h.html Cirrus Logic EP9307 был бы очень хорошим вариантом: * EP9301/2 + LCD контроллер * шина памяти нормальная, 32 бита * LCD контроллер в нем имеет 2D акселератор, который умеет блоки мувать, заливать, линии рисовать, маски накладывать, конвертировать удобные для CPU представления данных в LCD представления *- BGA 0.8, а это уже совсем не пушисто. * errata уже на детектив не похожа. Cirrus'ы еще хороши тем, что по UART/SPI бутиться умеют. Еще вариант на роль LCPU - AXIS ETRAX 100LX http://developer.a …/etrax100lx/index.html Это не ARM (но очень похож), не очень быстрый (100 Мгц), но DMA шикарное, Ethernet встроенный, тулчейн есть. Еще не очень понятно как у него с industrial temp. BGA. Atmel AT91RM9200 ОК, но не долюбливаю я его. Sharp LH79520 хорошо, контроллер LCD шикарный, PQFP, относительно быстрый. Дешевый (http://www.digikey.com/ 1-14.54, 100 - 11.628). Но нет Ethernet. 77 Мгц - с одной стороны, не быстро, по сравнению с 200 Мгц, но поскольку у нас real time живет своей жизнью, вполне хватит. На графике 320х240 8 бит я лично с этим чипом работал (uCOS GUI) - скорость достаточная, торможения не чувствуется. Пусть под Linux это будет даже в 2 раза медленнее - терпимо. Есть более современный вариант - LH79525 * 10/100 BaseT Ethernet MAC * USB 2.0 Full Speed Device * 10 Input, 10-bit A/D Converter with Integrated Touch Screen Controller * I2C * SPI * NAND Flash Support *! умеет бутиться с NAND, I2C, UART (правда, только в версии силикона А1) *- 16 бит внешняя шина, *- который год в Development висит. Сейчас вроде образцы поставляют. Его вариант с 32 битной шиной LH79524 есть только в корпусе BGA 0.8мм, он недорог (~$14 достать можно), под него есть кит. http://www.logicpd …s/sharp/sdk/sharp_sdk/ Цена кита http://www.digikey.com $420. http://www.sharpsm …press.php?ArticleID=38 пресс релиз по поводу LH79524/25. Правда, судя по errata, релиз A0 чипа, который все продают, покупать не стоит (USB серьезные ошибки). Вообще, когда доведут LH79524/5 - чип будет просто сказка! Все шарпы изначально industrial. FreeScale MPC5200 - вообще идеальная вещь, PowerPC, но BGA ("правильный" шаг 1.27), и ,все-таки, тяжеловата и дороговата для данной платы. http://www.freesca …ta_sheet/MPC5200TS.pdf NetSilicon NS9750 - тоже хорошая вещь, LCD, PCI - но непонятно, как с доступностью. BGA ("правильный" шаг 1.27) - но тут оно того стоит. По моей информации его пока до конца не допатчили. http://www.netsili …pdf/prd_nap_ns9750.pdf Цена >$50 в малых количествах тоже не вдохновляет. Тогда уже проще идти на MPC5200 + внешний PCI LCD контроллер типа Silicon Motion SM712 (его баксов за 12 достать можно) http://www.siliconmotion.com/dcsg.htm Что касается граф. контроллера - тут много вопросов. В большинстве случаев можно обойтись и без него, но, на худой конец, можно иметь две версии платы. Фактически, вырисовываются следующие варианты LCPU * продвинутый вариант №1 200 Мгц, Ehternet, без LCD, PQFP - Cirrus Logic EP9301/2 * продвинутый вариант №2 200 Мгц, Ehternet, LCD, BGA 0.8 - Cirrus Logic EP9307 * дешевый вариант №1 77 Мгц, Ehternet, LCD, PQFP - Sharp LH79525 * дешевый вариант №2 77 Мгц, Ehternet, LCD, BGA 0.8 - Sharp LH79524 * дешевый вариант №3 77 Мгц, Ehternet внешним чипом по DMA (например, LAN91C111 хоть дорог, но ничего не поделаешь), LCD, PQFP - Sharp LH79520 <- я бы выбрал это, проверенное решение! * тяжеловесный вариант №1 400 Мгц, 700 Dhrystone MIPS, PCI, Ethernet, LCD вторым чипом, BGA - FreeScale MPC5200 * тяжеловесный вариант №2 200 Мгц, 200 Dhrystone MIPS, PCI, Ethernet, LCD, BGA - NetSilicon NS9750 *** Выбор SCPU **** Если разобраться, процы со встроенным флешком не нужны нам. Можно и с ним (не сложно наладить прошивку SCPU со стороны LCPU проца), но зачем? Поразмышляв, я пришел в выводу, что реально есть всего два кандидата (распространенность, наличие, проверенность в деле чипов, наличие и изученность средств разработки). >>>>AT91R40008-66AI [$12.51 Группа компаний "КТЦ-МК"]<<<< * до 75 Мгц * PLL нет - плохо! Нужно ставить внешний высокочастотный тактовый генератор, это шумы, помехи и т.д. * Internal 256K Bytes RAM - здорово для нас * 16 bit внешняя шина данных * 20 bit внешняя шина адреса * 8 Chip Selects * 1 блок 3 х 16 bit Timer Counter (хоть и 16 бит, но весьма продвинутые - LPC2xxx отдыхает) * 2 x USART (с Periferial Data Controller - DMA) - не сильно надо в нашем случае. * 1 x FIQ Fast Interrup Request * 3 x IRQ обычные входы * Watchdog Timer * ядро 1.8В * 3.3В периферия В камне много памяти, во всем остальном очень бедно. >>>>AT91M55800A-33AI [$11.62 Группа компаний "КТЦ-МК"]<<<< * 33 Мгц * Clock Generator PLL (умножает от 2 до 64). Супер. Ставим кварец 1.8432*n, и большинство нужных на практике частот (IMHO) у нас в кармане (например, 3.6864 * 9 (PLL) = 33.1776 Мгц) * 16 bit внешняя шина данных * 24 bit внешняя шина адреса * 8 Chip Selects * Internal RAM 8K Bytes - мало, но если не заниматься стеками и прочей ерундой, то для простой обработки данных хватит * 3 х USART (с Periferial Data Controller - DMA) - не сильно надо в нашем случае. * SPI (с Periferial Data Controller - DMA), даже 4 выделенных пина для SPI CS есть - очень полезно для внешних ЦАП/АЦП * Watchdog Timer * 2 х (4-Channel ADC0 10 bit) - очень полезно для нас * 2 x (DAC 10 bit) - очень полезно для нас * 2 блока 3 х 16 bit Timer Counter (хоть и 16 бит, но весьма продвинутые - LPC2xxx отдыхает) - то что нужно в данном случае!!! * 1 x FIQ Fast Interrup Request - полезно * 6 x IRQ обычные входы - очень хорошо для нас * Advanced Power Management Controller - едва ли нужно в данном случае, но пусть будет * Real Time Clock с отдельным питанием - едва ли нужно в данном случае, но пусть будет * Питание 3.3В - не самый малопотребляющий вариант, зато хорошо, что не будет лишней цепи Камень староват, но "старый конь борозды не испортит". 33 Мгц - с одной стороны, не много, но с другой (коль скоро у нас нет накладных расходов на RTOS и пр.) достаточно. Набор периферии очень хороший, по цене тоже эффективно получается. Для расширения ОЗУ можно предусмотреть место для >>>>K6R4016V1D-JI10 [$3.2 OOO "МТ-Систем"]<<<< * 256K x 16 Bit High-Speed CMOS Static RAM 44-SOJ 3.3V 10 ns (медленнее все равно нет, а так 0 wait будет! У Samsung хоть ток потребления в пределах разумного - 65ма для 10 нс версии) IMHO, AT91M55800A-33AI - наш выбор. Можно и Sharp LH75410 (16к внутреннего ОЗУ + 16 кеша, можно отмапить как SRAM, до 90Мгц, АЦП, 3 таймера (Atmel таймера круче), внутренний стабилизатор для ядра) - но в нем есть лишний для нас LCD контролер. Он как-то непопулярен у нас, хотя камень хороший. http://www.digikey.com 25 штук - 9.97. **** Межпроцессорный обмен **** **** Логика **** Всю логику проще построить на двухпортовом ОЗУ. Это избавит от необходимости городить протоколы обмена и пр. А так все просто. Записал/считал память, послал другому процу сигнал (прерывание или просто уровень на пине). Можно сделать память с ограниченным доступом (один пишет/читает, второй только читает). Можно и вообще тупо байт в памяти опрашивать - if изменился - есть данные. Начальная загрузка - LCPU заресетил SCPU, загрузил в память стартовый код, отмапил его на адрес reset SCPU, разресетил. Нормальная работа - обмен блоками (можно через двухпортовое ОЗУ, можно переключать страницы - как удобнее и эффективнее с точки зрения экономии ресурсов FPGA). + прерывания - короче, аппаратные "mail boxes". Конфигурацию FPGA можно менять как угодно - например, вначале всю встроенную память на один большой двухпортовый блок (для начальной загрузки), затем, перестусовали под "mail boxes" **** Аппаратура **** >>>>EP1K10QC208-3 [$12.24 Корпорация "Точка Опоры"]<<<< Total RAM bits 12 288 Блоков памяти 256 х 16 - 3 Logic elements (LEs) 576 208-Pin PQFP >>>>EP1K30QC208-3 [$16.8 Корпорация "Точка Опоры"]<<<< Total RAM bits 24 576 Logic elements (LEs) 1,728 Блоков памяти 256 х 16 - 6 208-Pin PQFP * Почему ACEX 1K? -* ресурсов более чем достаточно для нашей задачи, нет ничего лишнего - что очень приятно -* родной двухпортовый блок памяти 256 х 16 -* один из самых дешевых кристаллов -* 5В совместимые входы. Очень полезно в плане универсальности. -* питание ядра 2.5В, скорость нарастания напряжения ядра и порядок подачи питания на ядро и периферию не имеют значения - сравните с тем, что маленькими буковками про Spartan 3 написано!!! * Почему 208-Pin PQFP? Чтобы пинов хватило. В этом корпусе есть все ACEX 1K - так что свобода для творчества полная. Для сравнения >>>>EP1K100QC208-3 [$27.5 Корпорация "Точка Опоры"]<<<< Total RAM bits 49,152 Блоков памяти 256 х 16 - 12 Logic elements (LEs) 4,992 На этом камне все, что угодно можно сделать (в рамках рассматриваемых задач, компл. БПФ 1024 - это круто, но не всем и не всегда нужно)! Часть ресурсов FPGA можно задействовать для организации PC-104 подобной шины для LCPU (тут 5В совместимость будет очень в тему). Конфигурационная EEPROM нам не нужна - загружать будет LCPU (уверен, можно сделать схему так, что LCPU стартует без FPGA, а потом конфигурирует ее). В принципе, можно и Cyclone заюзать - хотя и не понятно, зачем? Ядро 1.5В, совместимости с 5В нет.

                                    EP1C3          EP1C6           EP1C12
Logic elements (LEs)                2 910          5,980           12,060
M4K RAM blocks (128 х 36 bits)      13             20              52
Total RAM bits                      59,904         92,160          239,616
PLLs                                1              2               2
144-Pin TQFP (цена)                 EP1C3T144C8    EP1C6T144C8     - не бывает -
                                    $12.6          $28.28
                                    Точка Опоры    неизв. пост.

240-Pin PQFP (цена)                 - не бывает -  EP1C6Q240C8     EP1C12Q240C8
                                                   $21.95          $57.42
                                                   Точка Опоры     неизв. пост.

**** Основные преимущества **** *** Универсальность. Универсальнее некуда. *** Эффективность отладки. Написали Вы целевое ядро. Отлаживаете систему. Лажа получается. Нужно задампить выход датчика и понять, что к чему. Ок, формируете в двухпортовом ОЗУ пакеты (с метками времени таймера SCPU) - и на USB FLASH при помощи LCPU. Или на DVD-RW. Или ftp на другую сторону Атлантики - для кода целевого ядра это безразлично!!!! Алгоритмическая отладка. Пишется процесс, который эмулирует SCPU (либо выдает реальные данные, снятые с системы и сохраненные в файле). Его выход - на вход другого процесса, который и делает алгоритм верхнего уровня. Вся отладка идет на PC, cygwin (а может, на супер кластере - если считать много надо). Вы сидите в Пскове, Ваш программист "верхнего уровня" - в Новосибирске. Потом Вы берете исходник, компилируете его под Вашу платформу и вперед. Поскольку алгоритм отвязан от аппаратуры, не думаю, что будет очень большие проблемы с переносимостью (если код грамотно написан - дык нефиг тупорылых программеров нанимать!). *** Маштабируемость. Надо SCPU заменить на DSP - вперед! Ничего в системе верхнего уровня не изменится. LCPU завтра вышел новый и дешевый - тоже не проблема, Linu