Evgeny_CD (10.08.2006 22:31, просмотров: 1) ответил Evgeny_CD на Dream Platform II, или нафига я за RTEMS взялся.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