Jump to content

    

Evgeny_CD

Свой*
  • Content Count

    2065
  • Joined

  • Last visited

Everything posted by Evgeny_CD


  1. Решил я тут пройтись по ColdFire - посмотреть, что там есть интересного. Посмотрел - и в осадок выпал. Есть несколько очень интересных чипов в PQFP, против которых все известные мне ARM выглядят каким-то недопатченным хламом. ***************** MCF5208 *********************** Страница продукта MCF5208 : V2 ColdFire® Integrated Microprocessor http://www.freescale.com/webapp/sps/site/p...sp?code=MCF5208 Борда ColdFire M5208EVB http://www.steroidmicros.com/micros/micro.aspx?ID=M5208EVB http://www.freescale.com/webapp/sps/site/p...2468rH3YTLCFqnN Цена борды на http://www.digikey.com M5208EVB-ND KIT DEV FOR COLDFIRE MCF5208 - 408.44 !!!! Цена камней (это для MCF5208CVM166 - BGA версия, PQFP пока еще не продаются) http://www.mouser.com $7.61 для 630 штук. Пусть для розницы будет 15 - все равно супер! Есть две версии MCF5208 - с Ethernet MCF5207 - без Ethernet В чем кайф? * !!! PQFP 160/144 * High Performance V2 ColdFire® core - 166 MHz, 159 DMIPS. * eMAC (32x32) module, hardware divide (40 битный аккумулятор, 32 * 32 + (результат можно сдвинуть на +-1 бит) 40 -> 40 за 1 такт. PXA270 напоминает. * 16 KB SRAM * 8 KB configurable as instruction-only, data-only, or split I-/D-cache * Integrated peripherals -- 10/100 Fast Ethernet Controller -- Flexible 16-bit DDR / 32-bit SDR SDRAM memory controller (на половинной частоте) -- Low-power modes and low-frequency clock divider -- Three UARTs -- QSPI -- I2C -- Four 32-bit timers -- Four Programmable Interrupt Timers (PITs) -- Phase Lock Loop (PLL) with optional bypass for reduced power consumption -- !!!! 16-ch DMA controller с внешним входом запроса * 8 Chip selects, Up to 50 GPIO * World-class BDM * JTAG * Technology: 0.13µ * Temperature range: -40°C to +85°C * MCF5208: 196-ball MAPBGA and 160-pin QFP packages Вообще чип взрослый - всего не перечислишь. Errata вполне разумная. Чип позиционируется как модернизация MCF5206e, вроде как они даже собираются документ по переходу MCF5208 -> MCF5206e выпустить. ***************** MCF5249 *********************** http://www.freescale.com/webapp/sps/site/p...sp?code=MCF5249 V2 ColdFire processor core * 140 Мгц, 125 DMIPS * !!! 96KB Static Random Access Memory (SRAM) * 8KB instruction cache * Enhanced Multiply-and Accumulate (EMAC) * Four (4) Programmable Chip Selects * Debug module - background and real time * Two (2) independent Universal Asynchronous Receiver and Transmitter (UARTs) * Two (2) independent 16-bit timers * I2C interface * Synchronous Dynamic Random Access Memory Controller (SDRAM) 16 бит * System integration (PLL, Software watchdog) * 4-channel Direct Memory Access (DMA) * !!! IDE интерфейс * SD контроллер, 4 бита, подсчет ECC * !!! PQFP 144, но этот вариант уже снимают uCOS port http://www.micrium.com/freescale/index.html http://www.micrium.com/downloads/ports/uco...CF5249-Diab.zip Cross GCC on a Win32 platform. http://brianrose.net/columns/CrossToolsWin32.html Отладочная плата MCF5249 based basic development platform http://www.hhcn.com/english/Coldfire.htm Type:HHCF5249-R2 CPU : MCF5249 Performance : 120-140MHz Ports: 1 RS232 serial port, 1 HDD-IDE port, 1 10/100M RJ45 , 1 BDM debug. ***************** MCF5206E *********************** http://www.freescale.com/webapp/sps/site/p...p?code=MCF5206E Version 2 ColdFire® Core * Multiply-Accumulate Module and Divide Unit * 4 KByte Direct-Mapped Instruction Cache * 8 KByte On-Chip SRAM * DRAM Controller, supports EDO and page node DRAMs * 2-channel DMA Controller * Two Universal Synchronous/Asynchronous Receiver/Transmitters (UART) * Dual 16-Bit General-Purpose Multimode Timers * I2C®-Compatible Bus * System Interface * System Debug Support * Fully Static 3.3V Operation with 5V tolerant inputs * 160 Pin QFP Package - Pin-compatible with MCF5206 * 8-bit general-purpose parallel I/O port * 50 MIPS at 54 MHz * Available at 40 and 50 MHz Старый чип. На него есть порты всего, чего угодно. Но он едва ли интересен. ***************** Порты ОСей *********************** ### uCOS ### Есть на MCF5206e, MCF5249 http://www.micrium.com/freescale/index.html http://www.micrium.com/downloads/ports/ucos-ii/m5206e.zip ### eCos ### Есть только на MCF5272, причем по порт написано, что он не до конца рабочий. ### RTEMS ### Есть порт только на MCF5206e. ### uClinux ### Идет вместе с M5208EVB ***************** Мониторы *********************** dBUG - некий монитор от Motorola. Описан в доке на M5208EVB. Исходники лежат на сайте FreeScale, но нужна какая-то особая регистрация для скачивания. ***************** Тулчейны *********************** ### GCC ### Подробно расписано, как собрать и настроить. Также есть примеры работы для сипа MCF5249 (он будет описан ниже) Cross GCC on a Win32 platform. http://brianrose.net/columns/CrossToolsWin32.html В блоге описано как собрать GCC 4, включая скрпит для этого http://www.brianrose.net/blog/ Brian said... I have a build script that automates the tool building process. As of today, it works with the following tools. Binutils - Snapshot on or after 5 Sept 2005. GCC - 4.0.2 Newlib - 1.14.0 Описания работы с GDB BDM Interface for MPC860/850/823 with gdb access http://www.vas-gmbh.de/software/mpcbdm/ BDM Interface for Motorola 683xx MCU Usage with GDB Debugger http://cmp.felk.cvut.cz/~pisa/m683xx/bdm_driver.html Building RTEMS for the ColdFire with Cygwin/WinNT http://sca.uwaterloo.ca/coldfire/ftp/david...rting-rtems.htm ### виндовые ### http://www.pemicro.com/ Подход к созданию тулзов напоминает MicroCross. GCC + своя обвязка. Цены относительно разумные. ### Классика жанра ### CodeWarrior http://www.freescale.com/webapp/sps/site/o...=01272694014080 Версия 6.1 лежит у нас с клизьмой. Кто-нибудь его использовал - как оно? Некая кросс среда, цены к разумным не относятся. http://www.crossware.com/coldfire/dsfirefly.htm ***************** BDM *********************** Фирменный моторольский интефейс для отладки. A good description can be found in Motorola Apnote AN1230 on how to build your own BDM. http://e-www.motorola.com/files/microcontr...note/AN1230.pdf GDB with BDM http://www.davehylands.com/avi/gdb_with_bdm.htm ### быстрые ### Совместимы с CodeWarrior http://www.pemicro.com/index.cfm Непонятно, как у них с работой под GDB. Цены отчасти разумные. ***************** JTAG *********************** У всех современных ColdFire есть, в качестве второго стандартного интерфейса. ***************** Симулятор *********************** Coldfire Emulator MCF5206e, MCF5307 http://www.slicer.ca/coldfire/index.php It will compile on windows using the Cygwin compiler. It boots uClinux! quick howto to make it run, http://www.slicer.ca/coldfire/uclinux-howto.php When the emulator starts, it will print two TCP port numbers. These correspond to serial port 1 and 2, telnet to these ports if you want to see output. Building a Cross Compiler http://www.slicer.ca/coldfire/cross.php В состав симулятора входит dBUG, так что можно ставить, выбирать борду, и тренироваться! ***************** Мой вывод *********************** Моторола (FreeScale) побеждает? PPC405 как топовый контроллер, MCF5xxx - как все остальное... У меня сложилось впечатление, что MCF5208 (MCF5207) - это killing chip от FreeScale, с которым она собирается расширить свое присутствие на рынке контроллеров очень "нипадеццки". Честно говоря, против него все ARMы, о которых мы тут так часто говорим, и тот же STR91, выглядят просто хламом: производительность немного хуже 180 Мгц ARM9/9E, DSP производительность будет точно не хуже, 40 битный аккумулятор... Ядро вполне конкурентоспособно с ARM по "крутизне" Цена, PQFP корпус, SDRAM SDR/DDR... ColdFire у нас не сильно распространен - но это временно? ***************** Вопрос *********************** Кто-нибудь работал с BDM, ColdFire - как впечатления? Какими тулзами кто пользовался? ***************** Примечания *********************** http://www.ucdot.org - много всего интересного, есть список плат под ColdFire и не только.
  2. Вышла FreeRTOS V4.0.5 ... 8.2.3

    http://www.freertos.org/ Changes between V4.0.4 and V4.0.5 released August 13, 2006 http://www.freertos.org/History.txt Доросли до коммерческой версии - FreeRTOS-pro ($650 USD per developer seat) http://www.highintegritysystems.com/freertospro.html Исходники http://www.freertos.org/a00104.html С лицензией все в порядке http://www.freertos.org/a00114.html Лист, форум http://www.freertos.org/a00115.html Дока качественная. В частности, подробно расписана архитектура ОСи и ее имплементация, разжеваны примеры и пр. http://www.freertos.org/implementation/index.html Real Time Application Design Using FreeRTOS in small embedded systems http://www.freertos.org/tutorial/index.html Motorola/Freescale ColdFire RTOS port - очень интересно в свете моих последних изысканий http://www.freertos.org/portcoldfire.html Наиболее интересные фичи * both preemptive and cooperative options. * supports both tasks and co-routines. Вопросы: 1. Интересно, в чем она проигрывает uCOS? 2. Супергибкость ОСи - это хорошо (от PIC до ColdFire и x86). Но не накладывает ли это какие-нибудь ограничения на структуру ОСи? 3. Интересно мнение о FreeRTOS от юзавших ее в реальных проектах.
  3. Этот форум был создан в мае 2006 года по моей просьбе. Я как раз собирался использовать Au1xxx в одном проекте. Но через несколько дней вяснилось, что AMD кидает нас с Au, и я постремался использовать Au. С тех пор этот форум болтался немым укором мне, сильно отравляя мое morality. Кучу данных по MIPS я тогда собрал, толком не систематизировал, так они у меня и валяются. Но чудо! Старя тема ожила с неожиданной стороны! Пост PIC32 http://caxapa.ru/104330.html Некие предвестники появились несколько недель назад. http://caxapa.ru/104205.html Но что выйдет именно так, я был совершенно не готов! Страница Микрочипа http://www.microchip.com/stellent/idcplg?I...amp;nodeId=2591 MIPS32® M4K™ Processor Core Datasheet http://www.mips.com/media/files/MD00247-2B-M4K-DTS-02.00.pdf Беглый взгляд на этот dream device. * 1.5 DMIPS/MHZ - это сильно! При 72 Мгц максимальной тактовой (как-то удивительно Cortex-M3 напоминает, не находите?) это даст 108 DMIPS, что быстрее 90 DMIPS Cortrex-M3. (разница, конечно, скорее маркетинговая, чем техническая, но все же приятно). Конечно, надо разбираться, когда такая скорость достижима. * Честный MAC 16*32+32->32 1 такт. Тут лучше Cortex-M3. Деление. * Технология вроде как 0.25 (питание ядра 2.5В, насколько я понял), что нетривиально! * FLASH 128 битный. Тоже сильное достижение! * Cache 256 байт. * DMA 4 канала. Мало, но хорошо, хоть есть. * CRC Generation Module: - вот это сильно!!! - CRC module can be assigned to any of the available channels (на канал DMA) * Parallel Master Port (PMP) - ИЕС!!! Они услышали мои мольбы!!! * 512 FLASH /32 SRAM - вполне приличный набортный набор. * Errata вполне терпимая. Уже поздно, спать пора, но пока я в ней ничего смертельного не увидел, что бы препятствовало немедленному юзу камней в реальных проектах. * Шинный коммутатор. * Взрослая архитектура MIPS в основе. Это Вам не АРМ недопатченный. Это Архитектура с большой буквы. Вот так судя по доке - сказочный процессор. Хошь сам по себе, хошь CPLD|FPGA|LCD|SRAM какой подрубай к нему по параллельной шине. Жаль, пока нет USB|Ethernet - но, очевидно, это только пока. Очень хорошо подходит для гибридных систем: * Au... на Host процессор под Linux или взрослой RTOS типа eCos, RTEMS. * MIPS32 на периферийный * Связь по SPI (слава богу, у PIC32 есть DMA!). Итак, в плане гибридных двухуровневых систем у нас сформировалось 3 тандема (критерий - одинаковость базовой архитектуры для host и device): * ARM 926E|966E + Cortex-M3 * ColdFire старшие MCF52xx|53xx|54xx + CF со встроенной FLASH памятью * MIPS4KC Host + PIC32 на периферию. С Армами все более менее понятно. Дешевое, популярное, но ограниченное решение. Поскольку PXA270, можно считать, покинул наш embedded мир (он токма в сотикаках нынче тусуется), то ARM доступные самые быстрые есть от FreeScale (i.MX31 не в счет, экзотика, а вот i.MX21 и i.MX27 доступны и вполне интересны, но это только 266 Мгц) CF - моя любовь! Совершенная архитектура. Долго можно рассказывать. Но пока они завязаны на одного производителя - все же стремно. MIPS - возвращение из небытия! Как host процессоры Auxxx намного мощнее и CF, и ARM. Если микрочип не будет сильно дурковать, то может получиться все очень интересно! Жаль, что пока нет единства в тулзах - но, надо полагать, GCC и прочие компилеры быстренько допатчат для MIPS M4K, JTAG в PIC32 есть - так что можно добиться сквозного набора тулзов. В качестве подстраховки, если вдруг AU начнут загибаться, MIPS есть от PMC Sierra, IDT, Toshiba, Infineon (знаменитый ADM5120) и еше дофига кого, ибо популярен в сетевых девайсах (ARM там не прижился). Ну что же, будем разбираться. Книжка очень в тему /pub/DOC/Books/MIPS/see-mips-run-second-edition.9780120884216.28395.pdf Тут тоже по MIPS немало /pub/DOC/Books/CPU/guide-to-risc-processors-for-programmers-and-engineers.9780387210179.26405.pdf
  4. Вот есть процесс в user space Linux. Он в цикле опрашивает порт IO (через медленную функцию доступа к IO из user space). Если там что-то случилось/не случилось, он делает некую работу. Есть другие процессы (и сама система). Они прерывают мой процесс. Процессов таких минимум, они не сильно активны. По сети активности нет. Винчестера нет, только NOR FLASH и SD. Если вести речь о PXA270, на 312 Мгц, то о какой "временной девиации" может идти речь? Т.е. на какое максимальное время система может прервать мой процесс? Можно ли говорить о том, что "дырка" будет не более 10 мс? Аспекты kernel module, RTAI чур пока не трогать. Реь идет о тупом программизме в user space.
  5. http://nuttx.sourceforge.net Выловил в листе uIP.
  6. http://www.amontec.com/chameleon.shtml
  7. Задумался я тут о создании универсальной среды для разработки и отладки embedded систем. Есть классика жанра - Matlab + Simulink - "это просто празник какой-то!". Смотрю я на работы AlexandrY http://aly.projektas.lt/Projects/MATLAB/DT...coderEvanse.htm и зависть профессиональная гнетет меня. Я тоже так хочу! Доступный мне инет пропылесосил, книжек по теме собрал, осталось их прочесть и осознать. Но уже сейчас я понимаю, что хочу большего. Просто пример. Пусть передо мной стоит задача разработки некоего девайса, который будет в себя включать * голосовые диалоги (довольно сложные) * захват видео (одиночные кадры) от аналоговой камеры * сжатие этих фотографий JPEG. Я хочу провести эту разработку "сверху". Т.е. я беру eCos, синтетический порт под Linux, и начинаю писать с _целевых функций_. Надо мне голосовой диалог? Ок! Да день работы. Но вначале я напишу его в режиме диалога через tty, где вместо проигрыша голоса будет проигрыш текстовых файлов, вместо DTMF - ввод с клавиатуры. И в таком виде начну обкатывать вместе с кустомером. Когда логика (а оно там весьма нетривиальная, и точное ТЗ без такой модели никто не напишет) будет готова, перейдем к следующим упражнениям. Заметим, что уже после первого шага у меня будет готовый, отлаженный кусок кода под целевой ОСью (только переписать _внутренности функций типа play_msg() - а внешний интерфейс такой функции у меня будет уже отлажен - ей пофиг, что и куда проигрывать ) Переходим к задаче выбора кодека для голоса. Оценив запас по быстродействию целевой платформы и объем FLASH, я выберу кодек. И начну его писать? ДУДКИ! Я найду его готовую реализацию, и пущу в виртуальном режиме - как C приложение на том же Linux, под MATLAB и пр. Обмен данным - через IP сокеты. Хоть на другой машине. Заметим, что управляться этот кодек будет из моей целевой программы под целевой ОСью. Опять же, если я не буду кретином, то напишу универсальную обертку для любых кодеков. Поэкспериментировав с кодеком, выбрав подходящий с подходящим битрейтом, я опять же проведу тестирование с кустомером, мы все окончательно решим, и можно выделять ресурсы на портирование кодека на целевую платформу (или даже его покупку). Аналогично с фотками. Я не хочу вначале тратить ни одного часа на понимание того, как работает JPEG!!! По описанной выше технологии я прикручу готовый JPEG кодек (коих мульон есть), и будут отлаживать систему _целиком_. Далее можно хоть на асме написать супероптимальный кодек - когда будет точное ТЗ на него, и все будут точно знать, каких параметров надо достичь в конце концов. К чему это я? Надо (IMHO) не RTOS пусть под Matlab, а "сущность" под управлением Matlab сделать ресурсом под управлением моей ОС. Это даст возможность с самого первого шага идти сразу к целевой задаче, по пути уточняя ТЗ (что совсем не маловажно! - в том же примере JPEG кодеки бывают сильно разные - оптимизированные на качество, скорость, объем данных и пр. - сразу далеко не очевидно, какой надо выбрать!), и ни тратя ни одного часа на "левые" вещи. Python (хотя я только начал изучать его) меня убил наповал. Такой красоты и кайфа от программизма я еще не встречал. IMHO, учить программировать надо не с C, С++ и пр, а именно с Python. Короче (не хочу флеймить) Python - это очень хорошая инструментальная платформа для такого рода комплекса. SWIG, судя по собранной информации - вполне рабочая штука, с нею имеет смысл возиться. Интуитивно я чувствую, что с "изобретением" идеи оберток я начал "изобретать" С++. Вообще, вероятно, грамотное (скорее даже концептуальное) использование идей ООП в embedded системах - это просто новая эра (по крайней мере для меня точно). Не знаю, может, у меня эйфория, но я чувствую, что такой подход безграничен, как вселенная. Есть сущность - моя целевая embedded ОСь. Она управляет другими сущностями. Любыми. Через сокеты, например. По мере необходимости эти сущности втаскиваются внутрь ОСи, становясь "локальными" задачами. А потом все это собранное и отлаженное хозяйство ставится при помощи BSP на целевую платформу. Понятно, что все гладко не будет. Те же глюки в BSP могут столько крови попортить, что мало не покажется (был у нас года два назад опыт - программеры месяц "джитагили" борду, пока ошибку в BSP uCOS для AT91RM9200 не нашли). Но при таком подходе за счет объектного подхода вся система легко разбирается на части, связи между ними конечны и понятны - так что глюки легко локализовать. Мне кажется, что системы типа KEIL симулятор, MATLAB и пр. являются только частью такой вселенной, но не могут ее заменить. Кто наведет грамотную критику на мои размышлизмы - тому большой ! А то может у меня уже крыша съехала от долгого размышления...
  8. XMEGA: будущее, которого мы так долго ждали, наступило. Итак, на сайте Atmel появились полноценные доки по семейству. Само семейство пока еще недоступно в виде чипов на складах дистрибуторов, но такая позиция уже есть в прайсах. Совсем скоро можно будет запаивать. Далее все рассматривается на примере ATxmega128A1 Что обращает на себя внимание. 1. ATxmega64A1/128A1/192A1/256A1 Preliminary (75 pages, revision B, updated 5/08) http://www.atmel.com/dyn/resources/prod_do...nts/doc8067.pdf Смотрим секцию errata и видим - ATxmega128A1 rev. G. Т.е. предыдущие версии A-F сгинули в Atmel, так и не выйдя в свет. Вызывает уважение по сравнению с ситуацией на рынке ARM - там erratы к современным чипам просто вызывают депрессию. Сама errata вполне терпимая. Видно, что в предыдущих errata'х народ дожимал цифровые глюки, а теперь осталось некоторое количество аналоговых - нелинейности по напряжению и пр. То, что нет errat в части DMA, арбитража шин и т.д., и то, что это rev. G, дает некоторую надежду на вылеченность системных багов. 2. Накристальная периферия. То, ради чего все затевалось * RC генераторы - аж целых 4 штуки: 32 kHz Int. ULP; 32 kHz Int. Osc.; 2 MHz Int. Osc.; 32 MHz Int. Osc. Просто праздник какой-то. * 8 UART - это уже обсуждали * 16 битный RTC с прескалером (с коэф. от 1(!) до 1024), у которого есть Compare Match регистр - это просто праздник какой-то для всех, кто, например, делает коммуникационные протоколы * Event system - пока еще мною не познанная замолодь, но из описаний следует, что это эффективная шняга для обработки событий. AVR1001: Getting Started With the XMEGA Event System (8 pages, revision A, updated 2/08) http://www.atmel.com/dyn/resources/prod_do...nts/doc8071.pdf * DMA • The DMA Controller allows high-speed transfers with minimal CPU intervention – from one memory area to another – from memory area to peripheral – from peripheral to memory area – from peripheral to another peripheral Заметим, что DMA во всяких там SAM - "жалкое подобие левой руки" DMA XMEGA. И меговское DMA работает на всей SRAM - привет dsPIC. * 12 бит DAC (1 Мгц) и ADC (2 Мгц). Хоть в реальности они и получились 10 битными, все равно очень даже! * AWeX – Advanced Waveform Extension. Внушительный блок для всяких PWM приложений. * External Bus Interface for up to 128M bit SDRAM - токо в описании я что-то ничего про SDRAM не нашел 3. Жручесть. В варианте ULP, RTC,WDT, BOD Enabled обещают не более 2 мка при 3.3В. Типовой CR2016 имеет емкость 90 mAh, CR2032 - 230 mAh. 0,002*24*365*5=87.6 ма*ч энергии на 5 лет. 5 лет от CR2016 - большего на практике нафиг не надо. Т.е. дальнейшее уменьшение тока потребления суть маркетинговый развод, по технике это будет эффективно только для очень специфичных применений. To ensure safe operation it is always recommended to have a brown-out detector (BOD) enabled. This has to be either internal in the microcontroller or an external device. The brown-out detector will ensure that the microcontroller is held in reset if VCC is lower than minimum. The XMEGA BOD has a new and innovative sampling mode. In sampling mode, the BOD is turned on only once per ms to check status of VCC. If everything is OK, the BOD is turned off and remains off until next checkpoint. This gives XMEGA a max power consumption of 2 мкA in Power Save mode with a 32 kHz crystal running, Real Time Counter operating, Watchdog Timer enabled and BOD operative with max 1 ms reaction time. To achieve the same performance, TI MSP430 devices need to enable the System Voltage Supervisor that consumes up to 15 мкA. Тута все подробно расписано. Introducing a New Breed of Microcontrollers for 8/16-bit Applications (White Paper, 15 pages, revision A, updated 02/08) http://www.atmel.com/dyn/resources/prod_do...nts/doc7926.pdf "На ходу" жручесть тоже очень даже хороша: 2 MHz VCC = 1.8V All PRR Set Internal RC 720 мкА. Или в терминах CR2032 (230 mAh) 13 суток непрерывной работы! Для CR123A (1600 mAh) это 92 дня работы. По моему опыту - ATmega на 3.68 Мгц - это прием POCSAG 1200 бит/сек, включая 8 кратный oversampling, DPLL, БЧХ декодер и пр (C код без asm вставок! Но C код продуманный, конечно). Причем это без DMA. Так что 2 Мгц для XMEGA - это весьма немало. При питании 1.8В - до 12 Мгц, 32 Мгц - от 2.7В. Так что процык получился весьма зажигательный. MSP430 нервно курит (понятно, что 32Мгц XMEGA будет быстрее 16 Мгц MSP430, разве только что умножитель 16х16 спасет MSP430). 4. Цены - ABN Universal,Inc., например, дает для ATXMEGA128A1-AU 9,97 $ в розницу - достаточно обнадеживающе. Это на проц с 8К RAM, 4K EEPROM, 128K FLASH, 78 IO пинов. Для примера - MSP430F2618TPNR - FLASH 116K x 8 + 256B, SRAM 8Kx8, A/D 8x12b; D/A 2x12b, 64 IO пинов имеет в розницу цены $13.16 на www.digikey.com Выводы: Atmel таки сделал лучший 8 бит контроллер. И, уверен, будет заслуженно снимать с него сливки ближайшие лет 5. Конечно, будет ламье, которое с криками "32 лучше 16 лучше 8" убежит применять всякое многобитное барахло, но найдутся серьезные юзера, которые смогут выжать все из этого кристалла (а в серии 10к, я уверен, этот кристальчик даст фору по цене очень и очень многим) http://www.atmel.com/dyn/corporate/view_de...EC_NAME=Product Availability and Pricing. The first devices, ATxmega128A1 and ATxmega64A1 are both offered in 100-pin TQFP and BGA packages and are available now. Volume prices for 10k units are US$3.75 and US$3.50, respectively. Other XMEGA devices will be available during 2Q or 3Q of 2008. Что касается перспектив, то тут все просто замечательно! AVR XMEGA 8/16-bit High Performance Low Power Flash Microcontrollers (Flyer, 4 pages, revision B, updated 03/08) http://www.atmel.com/dyn/resources/prod_do...nts/doc7925.pdf ATxmega384A1 384k FLASH, 4k EERPOM, 32k SRAM (!). Основной кайф от XMEGA следующий. В общем, по своим основным параметрам, он умеренно чемпионский - MSP430 уверенно дышит в спину. Кроме одного - соотношение цены и объема памяти. 64К команд (при очень эффективной системе команд, которая хорошо ложится под С) и 8 К ОЗУ - этого вполне достаточно, чтобы использовать вполне взрослую ОСьку типа uCOS. И комфортно писать очень сложные приложения, которые будут годами работать от CR2032. Наличие ОСьки позволяет по полной программе использовать технологию синтетических портов. Т.е., например, при разработе ZigBee девайса, можно взять платку с CPU + RF, один SPI канал, например, выделить на связь с "большим процессором", на втором XMEGA сделать конвертер SPI<->USB (FTDI), и вести разработку в Win32, при этом имея виртуальные драйвера периферии, полностью эквивалентные "боевой" периферии. При такой технологии отпадает необходимость в аццком симуляторе периферии XMEGA (такие симуляторы, как показывает практика, до конца отдебажить невозможно), а разрабатывать под Win32 (или под Linux - если профи, то без разницы), все таки куда приятнее, чем дебажить кристалл при помощи самого продвинутого джЫтага. В приведенной выше схеме за счет DMA в XMEGA можно организовать дуплексный канал связи порядка 1 Мбайт/сек (2 чипа FTDI на раные USB порты, дрова D2XX drivers дают 1 Megabyte / second ) с "большим процессором". В упомянутом выше документе http://www.atmel.com/dyn/resources/prod_do...nts/doc7926.pdf на 7 странице есть чудная табличка о загрузке проца. XMEGA UART communication with and without DMA. При 3500 бит/сек мы имеем 5.17% CPU load (непонятно, на какой тактовой, симплекс или дуплекс). Т.е. при организации 1 Мбайт/сек дуплексного канала можно ожидать загруки проца порядка 25% при тактовой 32 Мгц. Т.е. если внешняя периферия порождает поток данных не более 1 мбайт/сек, то у проца будет возможность "отогнать" его на "большой" процессор, принять обработанные данные, и потратить 75% своего времени на дополнительную обработку данных - приписать к блоку отсчетов ADC время, когда эти отсчеты были взяты, поймать время по таймеру и выплюнуть синхронного блок выходных отсчетов и т.д. В общем, читаем pdf моих старых постов по синтетическим портам и виртуальной разработке, и можно приступать к созданию конкурентов автономных радиоканальных девайсов типа ZigBee
  9. Берется на сайте: регистрируемся и вперед. Вроде как нахяляву. http://www.intel.com/cd/software/products/.../ipp/238656.htm 1. Можно ли ее юзать с GCC, но без линуха? 2. Как-то мутно написано, версия 5.0 поддерживает PXA255 или нет? Понятно, что интел всеми силами толкает на pxa270.
  10. Atmel зажигает!

    http://www.atmel.com/dyn/resources/prod_do...nts/doc6054.pdf AT91SAM7SE256, AT91SAM7SE512 - SAM + внешняя шина + SDRAM контроллер! AT91SAM9260 - ARM926EJ-S ядро (DSP Extension), !!!PQFP208!!!, camera interface Осталось дождаться, когда они это все выпустят, обезглючат - и будет нам счастье .
  11. По идее, это мой 1000-й пост. Я не стремился ни к каким рекордам - "она сама ко мне пришла". Я пришел сюда чуть больше года назад. Пришел в непростой момент своей жизни. Чтобы отвлечься от мрачных мыслей, можно было пуститься во "все тяжкие", но я избрал для себя другое занятие - "knowledge hunting". Спустя год могу сказать - охота удалась! То количество знаний и информации, которое я получил за этот год, трудно описать словами. Дело даже не в местном ftp, и варезе вообще. Варез без знаний - это пустая трата денег на трафик. Просто в первые я нашел для себя ответы (часть ответов) на вопросы, мучившие меня с момента начала профессиональной карьеры. Вопросы по методологии организации процесса разработки, по повторному использованию "интеллектуальных объектов" (имеет отношение не только к ООП), по методикам ограничения "глубины мышления" - чтобы в каждый момент решать одну очень простую задачу, и в то же время не утрачивать общности видения проекта в целом. Я очень признателен всем, кто поделился со мной (и не только со мной) бесценными крупицами этих знаний. Спасибо, друзья! Со своей стороны я тоже старался "не подкачать": эмоционально ставил интересные вопросы (сознательно порождая активные обсуждения - как правило, в процессе таких обсуждений народ очень эффективно делится ценнейшими мыслями), делился добытой информацией, сам отвечал на вопросы. По разным причинам (который сейчас не важны) я пока не внес материального вклада в существование этого ресурса - не платил денег за серверные винчи, не платил за трафик (судя по всему, скоро это будет актуально). В заключение хочу еще раз поблагодарить всех, кто создал этот ресурс, кто поддерживает и развивает его. Я не знаю, что именно подвигло этих людей на этот достойный поступок - но в любом случае СПАСИБО!!!
  12. После постыдного кидалова embedded рынка со стороны AMD (Alchemy) и Intel (PXA2xxx), задался я вопросом - а что использовать в перспективе как top контроллер для больших проектов? После некоторых рызмышлений выбор мой пал на AMCC PPC405-GPr. ============================ Камень ============================ Страница продукта https://www.amcc.com/MyAMCC/jsp/public/prod...uctID=PPC405GPr Апноут насчет DMA - 30+ Мбайт/сек качает! https://www.amcc.com/MyAMCC/retrieveDocumen...ance__v1_01.pdf * есть PPC405-GP - страя версия до 266 Мгц, технология 0.25 и PPC405-GPr - новая версия 400 Мгц, технология 0.18, жрет меньше * 608 Drystone MIPS at 400 MHz * PowerPC® 405 32-bit RISC processor core operating up to 400MHz with 16KB I- and D-caches * Synchronous DRAM (SDRAM) interface operating up to 133MHz - 32-bit interface for non-ECC applications - 40-bit interface serves 32 bits of data plus 8 check bits for ECC applications !!! * 4KB on-chip memory (OCM) * External peripheral bus - Flash ROM/Boot ROM interface - Direct support for 8-, 16-, or 32-bit SRAM and external peripherals - Up to eight devices - External Mastering supported * DMA support for external peripherals, internal UART and memory - Scatter-gather chaining supported - Four channels * PCI Revision 2.2 compliant interface (32-bit, up to 66MHz) - Synchronous or asynchronous PCI Bus interface - Internal or external PCI Bus Arbiter * Ethernet 10/100Mbps (full-duplex) support with media independent interface (MII) * Programmable interrupt controller supports 13 external and 19 internal edge triggered or levelsensitive interrupts * Programmable timers * Two serial ports (16550 compatible UART) * One IIC interface * General purpose I/O (GPIO) available * Supports JTAG for board level testing * Internal processor local Bus (PLB) runs at SDRAM interface frequency * Supports PowerPC processor boot from PCI memory * Unique software-accessible 64-bit chip ID number (ECID). * жрет меньше 1 ватта. * только индустриальные версии чипа. Коммерческих не бывает. Неприятно, что нет SPI - но его всегда в ПЛИСке на шине можно сделать. Было бы хуже, если бы I2C не было. Питание ядра 1.8В, что хорошо согласуется с ARM7 контроллерами (если "сопроцессор" нужно будет поставить) и Lattice MachXO, LatticeXP FPGA со встроенной FLASH - заодно они и проблему защиты от копирования решат. ============================ Цены и доступность ============================ http://www.efind.ru/icsearch/?search=PPC405GPr-3bb PPC405GPR-3BB266 $56,50. Есть на складе в Выборге. Это чип в замечательном BGA свинцовом (!!!) корпусе с шагом 1.27 мм, 5 рядов + остров. Разведется он без проблем на весьма "дубовой" 4-х сйлоке * контактная площадка под BGA пин - 0.5 * зазор/проводник/пояскок вокруг VIA 0.2 * сверло 0.4 Дороговато, конечно, но далее будет понятно, что возможно, такая цена и оправдана. ============================ Литература ============================ Толковых книжек пока не нашел. Попалось только это - но оно умеренно полезно. The Linux® Kernel Primer: A Top-Down Approach for x86 and PowerPC Architectures http://www.chmpdf.com/book/the-linux-kerne...hitectures-893/ Вот тут еще одна книжка упоминается http://www.mactech.com/articles/mactech/Vo...ooks/index.html POWER and PowerPC By Weiss and Smith Morgan Kaufmann Publishers, Inc. 1994. ISBN 1-55860-279-8. 408 pages (hardback). ============================ Платы ============================ ******************* PPCHAMELEON ******************* CPU DDR-SO-DIMM Board (PowerPC 405EP) http://www.dave-tech.it/index.php?page=2&n...ducts&subgroup= Цены довольно демократичные DPC1430 samples 180,00 Eur Но для модуля еще "мамка" неужна - а она наверняка будет "добрых" денег стоить. Зато цены на софт у них безумные All kits for all OS come for 899,00 Eur (за каждую ОСь - eCos, Linux, uClinux надо платить бабло отдельно). ******************* CSB472, 672 ******************* http://www.cogcomp.com/csb_csb472.htm * Core 200Mhz 405GP, 16KI/8KD Cache * SDRAM 32Mbyte 32-Bit Wide SDRAM * FLASH 2Mbyte 16-Bit Wide AMD FLASH * Serial RS232 x1 RS232/RS485 Selectable x 1 * Ethernet Internal 10/100 Interface * Real Time Clock Dallas DS1307 With Battery * GPIO 40-GPIO via XC95144 Xilinx CPLD, programmable by customer * Bus Expansion 32-Bit Data, 26-Bit Address CPU Bus and 32-Bit PCI via 40-Pin Stackable Headers * CPU Expansion 32-Bit Data, 26-Bit Address via 40-Pin Stackable Headers * JTAG 20-Pin Header ( Abatron BDI2000 and Macraigor OCDemon compatible) * LED's 2 User Driven via GPIO * Power 5V Only Connection * Boot Monitor Micromonitor CSB472 Datasheet http://www.cogcomp.com/datasheets/Visio-CSB472_disti.pdf CSB472 Photo http://www.cogcomp.com/photos/csb472.jpg Цена 750$ http://www.cogcomp.com/pdfs/csb_price_list.pdf Планируют новую плату CSB672 - AMCC PowerPC 405EP Coming soon. Call for availability. ******************* MOAB Embedded Single Board Computer. ******************* !! Чемпион обзора Страница платы http://www.tamsinc.com/3011/index.htm Документация http://www.tamsinc.com/3011/support/index.htm Фотка http://www.tamsinc.com/3011/images/3011-66501-Side300.jpg Software Tutorial http://www.tamsinc.com/3011/support/MOAB.tutorial.Rev4.pdf 3011 Installation & Operation http://www.tamsinc.com/3011/support/MOAB.User.Man.Rev5.pdf !!! Цена очень правильная: MOAB Embedded Single Board Computer. Includes serial cable. $399.00 На плате стоит 128 Mbyte TC58DVG02A1FT NAND FLASH и 512 Kbyte AT49LV040 NOR FLASH, 64 мбайт SDRAM. ============================ JTAG ============================ ******************* macraigor ******************* Wiggler в пролете, Raven, usbDemon (благодарности Гудвину за его работу!!!) mpDemon - ОК http://macraigor.com/cpus.htm Взрослый JTAG mpDemon, но цена $1800.00... http://www.macraigor.com/mpDemon.htm ******************* Abatron BDI2000 ******************* Самый взрослый JTAG. http://www.abatron.ch/Files/BDI2000.pdf http://www.abatron.ch/Files/PL-bdiGDB5.pdf Цена тоже "самая"... 33103 BDI2000 with software bdiGDB for PPC4xx targets EUR 2'430 ============================ Компиляторы и прочий toolchain ============================ ******************* Green Hills ******************* Поддерждивает камень http://www.ghs.com/products/PowerPC_development.html http://www.ghs.com/download/datasheets/PPC_4.0_0804.pdf Macraigor поддерживается, так что можно, благодаря Гудвину, из usbDemon можно сделать недорогой отладчик. ******************* Embedded Linux Development Kit (ELDK) ******************* Хороший тулчейн, ориентирован на линух http://www.denx.de/wiki/DULG/ELDK ******************* Microcross GNU-X-Tools ******************* Неплохой тулчейн, но платный - 1k$. http://www.microcross.com/html/gxt-v3.html мануал http://www.microcross.com/GNU-X-Tools-User-Guide-v3.40.pdf Таргеты mips-elf, mips-linux http://www.microcross.com/html/targets.html ******************* powerpc-eabi из дистрибутива eCos ******************* ftp://ecos.sourceware.org/pub/ecos/gnutoo....cygwin.tar.bz2 ftp://ecos.sourceware.org/pub/ecos/gnutoo...86linux.tar.bz2 Древние (2003 г), но, надо полагать, хорошо протестированные тулзы ============================ Мониторы ============================ ******************* MicroMonitor ******************* http://www.microcross.com/html/micromonitor.html Есть свежий релиз, 23 Feb 06. ******************* RedBoot ******************* Входит в комплект eCos ****************** U-Boot ******************* http://www.denx.de/wiki/DULG/ELDK http://u-boot.sourceforge.net/ http://www.denx.de/wiki/publish/DULG/DULG-tqm8xxl.html ============================ OS'и ============================ ******************* Linux ******************* http://www.denx.de/wiki/DULG/ELDK ******************* RTEMS ******************* http://www.rtems.org/targets.html Вроде готовый порт есть только для PPC403, но отличий от PPC405 преодолимые. Вообще RTEMS очень любит PPC. ) ******************* uCOS ******************* http://www.micrium.com/ibm/index.html Порт древний, чуть ли не от версии 2.00. ******************* eCos ******************* Самое интересное!!! Готовый порт на ту самую недорогую плату. MOAB Development Board http://ecos.sourceware.org/ecos/boards/moab.html Порт качественный! * Diagnostic (polled) serial I/O * Interrupt-driven serial I/O * Ethernet * FLASH * PCI * Timekeeping (real-time clock) В том числе полная поддержка 128 Mbyte TC58DVG02A1FT NAND FLASH. С remote GDB по Ethernet как-то не понятно, в доке описано только для последовательного порта. Software Tutorial http://www.tamsinc.com/3011/support/MOAB.tutorial.Rev4.pdf Но при настройке порта eCos можно выбрать скорость обмена по UART 230 кбит/сек, что при правильном порте на пЫсюке даст вполне терпимую скорость, даже если GDB по Ethernet не запустится. ============================ Отладка ============================ Я много в последнее время писал о синтетических портах. Но столь качественный порт eCos дает возможность совсем по другом организовать отладку. FTP клиент входит в шататный дистрибутив eCos, RAM FS - тоже (FLASH FS может сказаться на быстродействии - так что лучше из RAM). Telnet Server нет, но, полагаю, отмапить printf/scanf на IP сокет - это разумной сложности занятие. * ресетим плату * грузим через GDB прогу, запускаем * перед программой ставим служебный кусок, он сихронизирует RAM FS с FTP сервером мы пысюке * основная программа, работает с RAM FS * после проги ставим служебный кусок, он сихронизирует RAM FS с FTP сервером мы пысюке * в любой момент при помощи GDB можем отлаживать по полной: смотреть память и регистры, ставить точки останова и т.д. Понятно, что не сложно написать скрпит для полностью автоматического прогона test units. Ресеттер можно сделать управляемый, прицепив на COM или LPT какую-нибудь простую железяку. ============================ Копирование платы MOAB Development Board ============================ Блок схема есть. PPC405 сильно интегрирован - внешяя периферия примитивна. CPLD вроде нет - NAND прикручена на адреса, и необходимые времянки сигналов делаются хитрыми записями и чтениями по разным адресам - все просто. Если использовать ту же идею с отдельной NOR Boot флешкой - то можно поставить PLCC панельку под AT49LV040, и вообще обойтись без JTAG Так что вроде как копирование платы проблем не вызовет. ============================ Выводы ============================ 1. PPC-405GP® очень даже хорошо подходит для топовых моделей встраиваемых контроллеров. 2. За счет качественного порта eCos можно организовать очень продвинутую автоматизированную систему тестирования софта. При небольших тиражах сложных проектов это с лихвой покроет достаточно высокую стоимость камня - стоимость разработки сложного ПО всегда выше стоимости железа. 3. Не так уж он и страшен, этот PPC. Если, конечно, с нуля ОСь на него портировать - утухнуть можно. А вот при готовой оси потихоньку осваивать камень и писать свою апликуху - не так уж и сложно. ============================ Вопросы ============================ А нет ли у AMCC какого-нибудь паскудного плана в отношении PPC-405GPr?
  13. SGI строит самый большой в мире суперкомпьютер с использованием FPGA http://www.ixbt.com/news/all/index.shtml?09/60/92 Предыдущие посты по теме DSP - "отработанная ступень" развития электроники на текущем этапе. Позже ее перезарядят, и она снова будет готова "к бою". Теорема и доказательство. http://caxapa.ru/96372.html DSP умер! Ссылка на некролог http://caxapa.ru/102816.html
  14. Есть у Winbond очень интересный чип W90N740 http://www.winbond.com.tw/PDF/Sheet/W90N740f.pdf ******** Features * ARM7TDMI * at least 80 MHz * 8 KB I-cache, 2 KB D-cache (both two-way set associative). * Big-Endian internal architecture, Little/Big-Endian memory interface. * JTAG embedded debugging. * two-channel DMA controller with burst mode. * 18 channel advanced interrupt controller. * on-chip programmable PLL for CPU and USB clocks. * powered from 1.8V and 3.3V, about 400 mW power consumption at 80 MHz. ********* On-chip Peripherals * dual 10/100 Mbit Ethernet controllers. * hardware NAT accelerator. * USB 1.1 host controller (OHCI 1.0 compatible). Support 1.5 Mbit and 12 Mbit devices. * one full-function UART * three timers, watchdog. * 21 GPIO pins. Напоминает Samsung S3C4510B/S3C4530A, но есть приятные моменты * тактовая - 80 * отдельный кеш данных 2к * ДВА Ethernet интерфейса, что иногда очень полезно. Под него есть готовая "макетка". http://www.surecom-net.com/pd-broadband-4904sx.htm - маршрутизаторы EP-4904AX 4 Port 10/100M Internet Broadband Router with USB Printer Server (Metal Housing ) EP-4904SX 4 Port 10/100M Internet Broadband Router with USB Printer Server (Plastic Housing) В Москве стоит баксов 40. Достаточно подробное описание "макетки" http://www.bluewaternz.com/corporate/uni/unikit/hardware.php Сайт, на котором лежит полная подборка материалов по установке uClinux на этот маршрутизатор. http://www.bluewaternz.com/corporate/uni/unikit/ eCos, к сожалению не портирован на чип (хотя он так и просится на него), но есть некоторые мысли http://sourceware.org/ml/ecos-discuss/2005-01/msg00108.html как это сделать. Действительно, это здравая идея - сделать порт на этот чип из Samsung S3C4510B. В дистрибутах еCos есть целых два порта на чип ********** \packages\hal\arm\aim711\ Это порт на эту плату AIM 711 - ядро. Интересные доки в конце страницы http://www.visionsystems.de/produkte/325.html Base 711a - "база" http://www.visionsystems.de/produkte/326.html ********** \packages\hal\arm\snds\ порт на эту плату http://topmicrosystems.com/html/help_keb50100.phtml Главное, есть порт ethernet контроллера S3C4510B \packages\devs\eth\arm\ks32c5000\ В общем, если бы кто из секанов прикрутил eCos на W90N740 - был бы чудо чипик для всяких разных контроллеров.
  15. http://mb9x.ginps.com/tools/fte.html Ссылка найдена на Сахаре.
  16. J-Link - RDI - GDB

    Чтобы использовать GDB c J-Link, надо сделать следующее: * Поставить jlinkrdi, применить клизьму, запустить JLinkTCPIPServer.exe * Под Cygwin: GDB, указать, что RDI устройство находится по адресу localhost * Чистый Linux: VmWare (с сетевой картой) - Linux - GDB; указать, что RDI отладчик находится по адресу (IP адрес host машины) Я все правильно понял?
  17. Много раз слышал, что Lattice очень эффективны по соотношению цена - качество. Выбрал время, пропылесосил их сайт (http://www.latticesemi.com), изучил - действительно, рулезные кристаллы! Главное - на стоке в http://www.mouser.com лежат, и цены, цены!!! MachXO - просто песня! CPLD с фичами FPGA (FLASH встроенная), включая PLL и блочную память (которая может быть х36 FIFO логика имеется). Пример цен - камень с 2280 LUT, 3 блока памяти по 9 кбит, распределенной памятью и пр. (здесь и далее http://www.mouser.com): LCMXO2280C-3FTN256C (BGA 256) 1: $30.20 25: $23.23 LCMXO2280C-5FTN256C 1: $39.90 25: $30.69 LCMXO2280C-3FTN324C (BGA 324) 1: $ 34.400 25: $ 26.460 LCMXO2280C-5FTN324C 1: $44.10 25: $33.92 LatticeXP - супер семейство! Встроенная FLASH, пример (10к LUT, 24 блока по 9 кбит, 4 PLL,...) LFXP10C-3FN388C (BGA 388) 1: $43.00 25: $33.08 LFXP10C-5FN388C 1: $56.00 25: $43.08 LFXP10C-3FN256C (BGA 256) 1: $40.50 25: $31.15 LFXP10C-5FN256C 1: $53.50 25: $41.15 Actel нервно курит. Для совсем маленьких и совсем больших кристаллов Lattice не очень эффективен, но для средних - просто песня. Семейство EC / ECP - очень достойный вариант обычной FPGA (без встроенного FLASH). Пример LFEC3E-3TN144C (PQFP 144, 3k LUT, 2 PLL, 6 блоков по 9 кбит (с организацией до х 32)): 1: $13.90 25: $12.51 LFEC3E-3FN256C (BGA 256 - обратите внимание на незначительный рост цены!) 1: $16.00 25: $14.40 LFECP6E-3FN256C (BGA 256, 16 умножителей 18 х 18, 10 блоков памяти) 1: $25.20 25: $22.68 Вопросы: 1. А нет ли в Lattice какой засады? Например, разводятся плохо, задержки всякие возникают - скорость реальных дизайнов не очень, среда мутная и глючная и т.д. Почему они не так популярны??? 2. Софтина ispLEVER полная с клизьмами где берется? http://www.latticesemi.com/products/design...lever/index.cfm За $500 как-то неохота покупать... http://www.latticesemi.com/store/software.cfm (пароль игнорировать) Или чем ее заменить? Чтобы на выходе из сторонней среды был файл прошивки. LFXP10C очень надо... ispLEVER-Starter (который нахаляву) не все поддерживает (они крайне грамотно вырезали наиболее интересные для меня девайсы )... http://www.latticesemi.com/products/design...everstarter.cfm Для прошивки есть свободный прошивальщик. ispVM http://www.latticesemi.com/products/design...ystem/index.cfm 3. ispLeverCORE™ где берется? 4. LPT Кабель для прошивки - нет ли у кого схемы? Он и родной не дорого стоит (~$70), но все же... Стоимость железа http://www.latticesemi.com/store/hardware.cfm (пароль игнорировать) 5. Industrial в дата шитах есть, а как в жизни? 6. Насколько я понимаю, для синтеза годятся: * Synplify * Precision * Active HDL Так? Вообще, кто использовал - как впечатления?
  18. Есть некий типовой контроллер. 512к FLASH,32к RAM. Такое распределение памяти вызвано объективными технологическими особенностями. И, вероятно так будет долго. Скоро станет 4M FLASH и 256 К SRAM, суть не изменится. Есть вариант unix идеологии. Когда в памяти живет куча процессов и потоков, различных дискрипторов и структур, и все это в RAM занимает просто мегабайты места. Для однокристальных систем эта идеология слабо подходит. Пусть есть несколько потков данных. Для каждого из который выделяются некие буфера. Пусть есть совокупность закоченных процедур, достаточно сложных. Такие процедуры принимают на вход указатель на структуру, что-то там делают (длительное время), активно юзают стек и кучу, но после завершения обработку выдают указатель на выходную структуру, стек на том же самом уровне, и кучу в том же самом состоянии, в каком они ее получили. Если идти по пути обычных вытесняющих ОСей, и при отсутствии глабального планирования времени, в зависимости от наступления неких критических событий в буферах (близок к переполнению/опустошению) и в окружающем мире (пришло событие, и нам надо срочно его обрабатывать) мы вынуждены будем переключить задачи. Что даст нам неприятность в виде нескольких кадров под стек задач, и бардак в куче, ибо новая задача может затребовать память, ей выделят ее, потом отработает вытесненная ранее задача, она освободит память, но куча уже будет фрагментирована. Дефрагментация кучи - тоска для малоресурсных систем. Для больших, заметим, это тоже фундаментальная проблема. Если же предположить, что есть некий планировщик, который зная внутреннюю картину системы (сколько чего в буферах, сколько событий ждет обработки), а таже при условии предсказуемости внешнего мира (пример - синхронная система связи, с выделенными кадрами), может более эффективно распределять время. Типа выбираем блок для обработки, запускаем его с пачкой данных, все остальное копится в буферах. Блок отработал - запустили следующий. Более того, при запуске такой своебразной задачи, ей можно выделить максимальный квант времени. Она сама смотрит, сколько у нее времени осталось, и если обработка не завершена, она ставит флаг (который ей потом сохранится, он static), чистит стек за собой, и отдает управление системе. Разумеется, алгоритм должен допускать такую возможность дробной обработки. Также задача может заказать, через сколько ее надо вызвать. Тогда у планировщика работы системы будет дотаточно данных, чтобы найти оптимальное распределение ресурсов. Такой подход к работе софтины потребудет специальных тулзов для логического проектирования, ибо прописывать такое все в лоб ручками - это нереально. А вот если использовать некую систему разметки кода, о которых я тут так давно размышляю, это было бы не так уж и сложно. Комбинация вытесняющего и невытесняющего механизмов была бы, IMHO, очень эффективной. Вопросы: * видел ли кто какие наработки по теме? * какие есть ОСьки, гибко использующие вытесняющий и коопреативный механизмы многозадачности? * критика и дополнение моих идей.
  19. Luminary рулит.

    1. Errata. Вроде как все пристойно на современные чипы. Уж не знаю, нет ли там такого фокуса как с STM - типа работайте с периферией только через нашу либу, в которой все баги и маскируются http://caxapa.ru/123682.html но внешне все смотрится пристойно. 2. Грамотная работа с RTC и таймерами. 32 битный таймер 32768, два регистра совпадения, независимое питание на RTC и 256 байт памяти, 24 битный "таймер ядра" - все очень продумано и удобно. 3. Ethernet -> http://caxapa.ru/123930.html Вообще вне конкуренции 4. Хорошая поддержка для работы с движками - квадратурные декодеры, PWM и пр. 5. Обидно, что IO питание от 3.0В, напрямую при питании от Li-Ion батареи часть емкости оной останется неиспользованной, но жить можно. По большому счету, только DMA и параллельной вншней шины не хватает. Но самое интересное в этом семействе другое. Технология 0.25. Это на заметку всем орущим "вот нету у нас в стране фабрик 0.0001 мкм, посему и нету своей электроники". Народ собрался с мыслями, взял очень "дубовый" и распространенный процесс, и сделал замолодь. За счет меньшей стоимости подготовки выпуск масок в случае бага вполне решаемая задача даже для небольшой фирмы, а грамотное использование фич 0.25 процесса дает своим преимущества - 5В совместимые входы и т.д. (на 0.18 это тоже можно, но ведет к большому расходу дефицитной площади кристалла). За счет полного выделения RTC части в свой домен питания вполне можо гасить питание на все остальное, и работать в покое от CR2032 с током 16 мка, тем более, что поддержка автоматического переключения на батарйку там есть, включая детектор "умирания" батарейки (правда, его не довели, там какие-то баги с этим связанные есть, но, уверен, допатчат). Интересно, как у них финансовые успехи? Что-то их не сильно слышно в последнее время - проблемы, или наоборот, вышли на расчетный уровень и спокойно работают.
  20. Цитата(Dog Pawlowa @ Jul 7 2008, 12:05) Евгений, а что Вы используете для собственно радиоканала, если не секрет? Спасибо, сорри за ОФФ.ADF7021
  21. Цитата(researcher @ Jul 6 2008, 16:48) STM32 – универсальное решение на ARM-ядре (НОВОСТИ ЭЛЕКТРОНИКИ №8, 2008) http://www.compeljournal.ru/enews/2008/8/6 или http://www.compeljournal.ru/images/articles/2008_8_6.pdfСтатейки в журналах - это хорошо. Когда их пишут люди, не имеющие интереса в последствиях влияния изложенного в статье на кошелек пишущего Перечитайте ветку. У Xmega против STM32 есть немало козырей. * потребление при работабщем RTC выского разрешения, когда Вы можете поставить прерывание на любой тик 32768 * внешняя шина * система поддержки events * PWM от быстрой PLL По "лобовой" производительности, конечно, проигрыш (было бы странно, если бы было наоборот), но в реальных проектах не все так однозначно...
  22. Цитата(makc @ Jul 1 2008, 14:36) Продолжение вопроса, поднятого здесь.Конфа MIPS была создана по моей инициативе достаточно давно Потом случилась продажа AMD Алхимии, и я так и не занялся мипсами по серьезному. Тем не менее, считаю, что эту конфу надо сохранить, т.к. MIPS - это отдельная архитектура, стараниями Microchip претендующая на заметное место на микроконтроллерном рынке. Что касается обсуждения PIC32 среди всех остальных PIC'ов, то это вопрос непростой. С одной стороны, периферия та же, а с другой стороны, тонкости программизма на С и ASM под PIC32 заметно другие. Пусть эта конфа живет.
  23. Ура! ATXMEGA128A1-AU в каталоге Mouser появились. Самих чипов на складе нет, когда будут - непонятно, но цены довольно разумные: 100 - $5.63. Для чипа с таким набором фич - просто отлично! www.mouser.com
  24. Проверочный пост

    тест.
  25. Есть контроллер (UART, USB, Ethernet, ...). Можно работать с его регистрами напрямую "в лоб", но структурированность и переносимость такого кода нулевые. Можно написать драйвера, которые виртуализируют этот контроллер. И вместо обращения к регистрам происходит использование макросов и функций таких драйверов. Это хорошо, ибо можно написать симулятор контроллера, и отлаживать целевую программу на нем. Более того, симулятор может принимать команды для контроллера, передавать их по каналу связи на железяку с контроллером, и выполнять их там. Обратно можно передавать ответы реального контроллера и данные. Это небыстро, но, зачастую, на начальном этапе освоения контроллера роль ошибок в документации и ошибок воприятия документаци куда важнее скорости. Лично я ненавижу такую процедуру: записал дрова, откомпилил, прошил, запустил, проверил - не в дугу. Написал чуть по другому, собрал, снова залили и т.д. Но накладных расходов никто не отменял! Если вместо проверки бита готовности в регистре я буду вызывать некую функцию, то где-то это может стать просто фатально. Мощность современых контроллеров растет, но все же не хочется закладывать принципиально избыточные решения. Можно пойти по пути макросов, но это сложно и не сильно универсально (макрос раскрывается либо в вызов симулятора, либо в набор операций с регистрами контроллера). Есть более изящный способ!!!! Берем кодогенератор типа Templarian http://sourceforge.net/projects/templarian В нем прописываем все "методы" объекта контроллера. Для разных вариантов - симулятор, "телепортация", "родное" исполнение кода. В нужных местах проекта вставляем "выход" такого кодогенератора - и вуаля! Автоматическая модификация текста под целевую платформу готова! Преимущества над макросами уже описал. Преимущества над #ifdef очевидны. Если я ничего не путаю, в методиках использования С++ это называется "отделение интерфейса от реализации". Снова я кусок С++ "изобрел" Продолжаем тему совершенствования работы с контроллерами. Самое тупое, что бывает при освоении нового контроллера - это чтение линейной PDF документации на него. Т.е. ты вначале парсишь мозгами 10м файл, затем, осознав, из чего же состоит твой контроллер, уже немного начинаешь ориентироваться в нем. Что касается самго процесса написания документации, то я так и вижу уходяшие к горизонту вереницы tecnical wrighters (надо полагать, прикованных за ногу к батарее), которые правят бесчисленные таблицы в документации какой-нибудь ATxmega. Хоть одна ошибка - и плеть надсмотрщика... Мы пойдем другим путем. Берем XML и строим иерархическую структуру типа: * контроллер * интерфейс контроллера * регистр * битовое поле (офсет и длина) * зачения этого поля Естественно, к каждой сущности приписано ее описание нормальным языком. (я не считаю XML правильным или неправильным, я привел его как пример иерархической организации данных. Реализация идеи может быть сделана любым другим способом.) Из этой структуры автоматически генерим "картинки с текстом" в виде графа сущностей контроллера. Так будет просто на порядки нагляднее линейнго описания. Теперь берем программистский редактор, который воспринимает наше описание как... DTD! Выглядит этот так: * жмем кнопарь - хочу работать с периферией * далее выбираем : контроллер -> интерфейс -> регистр -> битовое поле -> значение На каждом шаге мне автоматически подсовывается список того, из чего я могу выбрать в данный момент. И все это оформляется как "вызов" кодогенератора! Размер исходника будет гораздо больше, но скорость восприятия несопоставимо выше. Мне не надо держать в голове всю информацию о регистрах. Мне нужно примерно помнить, как устроен контроллер, а далее "говорящие названия" все мне скажут. Можно, конечно, наплодить чудо-хидеров, которые отчасти будут использовать ту же идеологию, но: * чудо-хидер повышает время сборки проекта * чудо-хидер не гарантирует, что моя IDE осознает его чудо-структуру и так удобно, как я описал, мне все подскажет * переносимость всего этого чудо-хозяйства между компилерами неочевидна (битовые поля компилеры поддерживают, мягко говоря, по разному). В реальности регистры устройства состоят из многих полей, и, прежде чем проициализировать регистр я должен "синтезировать" все слово, записываемое в регистр. Т.е. в тексте у меня это будет выглядеть как-то такКодОбращение к кодогенератору (Ethernet.Control.Satate_Of_Chip_WR,                 PKT_LEN =1560,                 SPEED=100,                 FLOW_CONTROL=ON) что раскроется в выражение типа Код*((volatile unsigned int*)0xFFFF0000)=((0x618<<24)|(1<<2)|1)); Получается все сбалансированно - описание для кодогенератора совместимо с любым программером (и оно совершенно понятно без тщательного чтения доки на чип), а plain С строка совместима с любым С компилятором. Ну и в качестве вершины такого подхода можно предложить обобщенные методы. Например, у нас есть Ethernet_Init, которому в качестве параметров передается длина пакета, скорость, ну и много чего. А этот метод раскрывается в целый кусок кода: * сборка значений в регистры * запись в нужной поледовательности * проверка готовности * пр. Тогда этот самый Ethernet контроллер для внешнего мира выглядит как компактный набор методов, которые в реальности суть очень эффективный С код. Комбинация двух описанных выше подходов возволяет полностью исключить ручную низкоуровневую модификацию исходников при переходе от навороченного синтетического порта к, например, ATmega88P, которая еще очень долго будет "уделывать" по потреблению все эти супернавороченные ARM'ы при работе от кварца 32768.