Evgeny_CD 0 10 августа, 2006 Опубликовано 10 августа, 2006 · Жалоба ************* Предыдущие обсуждения по теме ************* Маркетинговое исследование в догонку к ТЕОРЕМЕ (+) http://www.telesys.ru/wwwboards/mcontrol/1...es/105965.shtml Фундаментальня размышлизма о RTEMS. http://www.caxapa.ru/echo/arm.html?id=64965 http://electronix.ru/forum/index.php?showtopic=19756 Microsoft's.NET MicroFramework, Даешь "контроллеры светодиодов" с мегабайтом кода! http://electronix.ru/forum/index.php?showtopic=18948 http://www.caxapa.ru/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.princeton.edu/~diego/professional/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.keplerproject.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.keplerproject.org/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$ тулзов! Более того, описанная выше идея "внешней сокетной отладки" позволит проводить тестирование в реальном времени. Затраты процессорного времени на "внешние соткеты" гораздо выше, чем на "внутренние", но зато скриптовый движек не нагружает процессор. Так что фактически при такой отладке мы будем хорошо эмлировать автономную систему. Ну а отллаживаь на пЫсюке - одно удовольствие - тут и файловая система, и всякие рисровалки-отображалки, и языки любые. Кайф! ВСЕ! СПУСТЯ ГОД КАРТИНА В МОЕЙ БАШКЕ ОКОНЧАТЕЛЬНО СЛОЖИЛСЬ! АМИНЬ! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Evgeny_CD 0 10 августа, 2006 Опубликовано 10 августа, 2006 · Жалоба Dream Board - текст от 18 июля 2005 года --------------------------------------------- Dream Board - продолжение ТЕОРЕМЫ (+) >>>>>>>>>>>> краткое содержание предыдущих серий <<<<<<<<<<<<<<<<<<<<<< В хронологическом порядке "Членомер" производительности микроконтроллеров http://www.telesys.ru/wwwboards/mcontrol/1...es/104416.shtml http://forum.electronix.ru/index.php?showtopic=6279 http://www.caxapa.ru/mcu/wwwboard.html?id=35158 ТЕОРЕМА о ненужности и бесполезности ((С) на название - великий VLV) x86 архитектуры во встраиваемых приложениях http://www.telesys.ru/wwwboards/mcontrol/1...es/105243.shtml http://forum.electronix.ru/index.php?showtopic=6352 К вопросу о теореме http://www.telesys.ru/wwwboards/mcontrol/1...es/105467.shtml Сертификация ОСей http://www.telesys.ru/wwwboards/mcontrol/1...es/105851.shtml Кто чего к ТЕОРЕМЕ добавит? http://www.telesys.ru/wwwboards/mcontrol/1...es/105876.shtml Маркетинговое исследование вдогонку к ТЕОРЕМЕ http://www.telesys.ru/wwwboards/mcontrol/1...es/105965.shtml Втискивание MicroBlaze в различные Spartan 3 http://forum.electronix.ru/index.php?showtopic=6459 Средства разработки для MicroBlaze, NIOS http://forum.electronix.ru/index.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.com/dev/pdf/ARM%20Cross%...h%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.embeddedarm.com/epc/ts7250-spec-h.html http://www.embeddedarm.com/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.axis.com/products/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.com/eps/devkits/sharp/sdk/sharp_sdk/ Цена кита http://www.digikey.com $420. http://www.sharpsma.com/press/press.php?ArticleID=38 пресс релиз по поводу LH79524/25. Правда, судя по errata, релиз A0 чипа, который все продают, покупать не стоит (USB серьезные ошибки). Вообще, когда доведут LH79524/5 - чип будет просто сказка! Все шарпы изначально industrial. FreeScale MPC5200 - вообще идеальная вещь, PowerPC, но BGA ("правильный" шаг 1.27), и ,все-таки, тяжеловата и дороговата для данной платы. http://www.freescale.com/files/microcontro...t/MPC5200TS.pdf NetSilicon NS9750 - тоже хорошая вещь, LCD, PCI - но непонятно, как с доступностью. BGA ("правильный" шаг 1.27) - но тут оно того стоит. По моей информации его пока до конца не допатчили. http://www.netsilicon.com/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 завтра вышел новый и дешевый - тоже не проблема, Linux он и есть Linux. Крутизны захочется - MPC5200 к Вашим услугам. **** Технологические особенности **** Девайсы должны быть не BGA. Пусть плата будет сложной и дорогой (в партии все равно не очень дорого даже 6-слойка), но вот чтобы паять их можно было по мере необходимости. (BGA можно запаять и на коленке, но вот убедиться, что качественно запаян - это вряд ли. Нужно специальное оборудование - всякие "боковые микроскопы" и т.д.) Что-то типа http://www.nonzero.narod.ru/sm510pci.htm Т.е. платы сделаны - а паяешь по мере необходимости. В самом крайнем случае, пусть будет 1 BGA камень (процессор). Чтобы запаять его у того же фаствелла за $30, а потом, по мере необходимости, все остальное. Все компоненты (опционально) должны быть -40. Чтобы в случае чего можно было прямо в целевое изделие поставить. Дизайн платы должен предусматривать покрытие ее лаком (как опция) (разъемы с одного краю и т.д.). ***************** Критика ****************** ** TI OMAP тоже самое!!! Что Вы велосипед изобретаете? * Да, может я только сейчас понял красоту OMAP! * GNU тулзы для OMAP (для DSP его части)? * Завязанность на одного производителя. Вот не хватит Вам возможностей DSP OMAP - тогда что? * Никто не мешает с этой платформы на OMAP перейти * BGA корпуса ** 16 (а еще лучше 32Мбайт) SDRAM - это какие же глюки будут при непрерывной работе!!!! * Никаких. Со времен 565РУ5 прошло много времени, технологии усовершенствовались. * Возьмем, для примера, ADSL маршрутизатор. Там, как минимум, 8М памяти и какой-нибудь NetBSD/VxWorks/Linux. И ничего, если девайс исправен - работает круглосуточно без глюков. * SDRAM бывает industrial * Качественная разводка и многослойная плата - залог отсутствия проблем с SDRAM. Так что лучше юзать готовую плату, чем пытаться прикрутить SDRAM на двухслойке и шуметь, что типа "одни глюки". ** А почему бы не взять NIOS II, MicroBlaze, и не сделать все, что касается SCPU на одной FPGA? * Теоретически красиво, но дорого. Например, Nios II/e требует не менее 700 LE, но он весьма посредственный - Executes at most one instruction per six clock cycles. Nios II/s требует уже 1400 LE, да еще периферию неплохо бы сделать. В EP1C3 влезет, но... * Под сами процессоры GNU/GCC тулзы есть, но вот с бесплатностью среды разработки самого камня есть вопросы. Все эти System Generator денег стоят, NIOS II вообще чуть ли не индивидуально лицензируется. * У автора пока есть некоторая боязнь столь кардинального решения. Слишком много сущностей в проекте будет. Разбираться с созданием процессорного ядра в FPGA, потом со всеми тулзами... Пока по-проще хочется. ** А чего так слабо? Вот взяли бы Virtex-II (PowerPC 405) и залудили вообще все на одном кристалле. * GNU/GCC тузлзы? * Цена камня? По моим данным, такой камень под $100 будет стоить, и едва ли он у кого на складе в России будет. * Сложность будет запредельной по сравнению с решаемой задачей. ** А если на Spartan 3 / Cyclone 2, взять самый крутой soft процессор, и поставить uClinux, как вот эти сделали http://www.atmark-techno.com/en/product/suzaku.html * А как насчет "шарахнуть по памяти"? * Камень, который нормально потянет этот софт процессор, SDRAM контроллер и прочее - он уже не такй простой, денег стоит немалых. IMHO, реализация LCPU на специализированном куске кремния дешевле и ничем не хуже. ** А делал ли кто что-то подобное в мире * На двух АРМах - пока не знаю. Наверняка кто-то делал. * Очень похожие идеи есть у FreeScale MC9S12XD http://www.freescale.com/files/microcontro...ATECOPROCFS.pdf http://www.freescale.com/files/microcontro...C9S12XFAMFS.pdf * TI OMAP * Вот что-то очень похожее, но там CPU и DSP, насколько я понял, по разным ядрам не разнесены. http://www.hyperstone.com/portal/downloadc...t32XS_flyer.pdf http://www.hyperstone.com/portal/downloadc...et32S_Flyer.pdf Цены я везде указывал по http://www.einfo.ru от фирм, которых знаю по опыту работы. Очень хорошие предложения по Altera, как правило, делает http://www.gamma.vyborg.ru/ (не путать с http://www.gamma.spb.ru/ !!!), но они не любят их публиковать в инете... Если кто сможет навести аргументированную критику на этот опус - я будут самым счастливым человеком на свете!!!!! (С) Евгений Белянко. esp1[пcюг]kbkcc.ru Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
