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

Размышлизма "выходного дня". Новый класс микроконтроллеров? Рассмотрим следующий класс задач, решаемых в одном устройстве: * GSM GPRS, EDGE * ГЛОНАСС/GPS * простой PLC (на уровне охранных функций, несколько входов и выходов) * сжатие фото 1 fps SIF (352x288), запомининие 16 fps сколько памяти хватит * работа с аудио - 1 канал SPEEX малой скорости, сиплекс * работа в качестве маршрутизатора из локальной ethernet сети, скорости сотни кбит/сек макс * встроенный командный язык с малой скоростью, буквально 1к "операторов" в секунду или даже меньше. Рассмотрим крайности. Первое, что приходит на ум при рассмотрении последних 2-х пунктов - Linux. Типа там "усе есть". Но для решения всех остальных задач этот лялих удовищно избыточен по всем аспектам - от требований к мозгам программиста до набортных ресурсов. Однокристальный линух - дело настолько далекого будущего, что его попросту не видно. То, что он будет когда-нибудь однокристальным - тоже не факт. Некоторым подтверждением этих мыслей может быть ветка http://caxapa.ru/154881.html "Даешь DSP" - другая крайность, ибо 50 fps JPEG, MPEG4 AVC и пр. не нужно, а для во всем остальном DSP ядро будет "курить бамбук". Более внимательно рассмотрение задачи приводит к парадоксальным выводам. Если мы откинем * nix фанатизм и возьмем RTOS класса RTEMS, eCos, то вот так навскидку реализация всего описанного выше - это ~1Мбайт кода для современных процов. Это реалистично, ибо есть немало процов с 1Майт флеша на кристалле или даже больше. С ОЗУ вот какая штука. Его, конечно, тоже надо иметь порядка 1Мбайта, но оно может быть разной скорости. Как мы знаем, для UDP заголовок 8 байт, для TCP 20. Если у нас максимальная длина пакета 1536 байт, то, используя fixed memory pool с 64 байтным блоком, нам нужно 24 таких блока. Пусть у нас блок адресуются полным 32 битным адресом первого байта, тогда нам нужно 24 ячейки по 4 байта - 48 байт на дескриптор блока данных IP пакета. Тогда у нас суммарный объем служебных данных IP пакета 20+48=68 байт данных. Пусть будет 128 байт на декскриптор пакета. Если нам надо хранить в памяти 128 пакетов, то у нас будет задействовано 16к памяти под декскрипторы и 196к под данные (максимум). И поскольку скорость обработки данных у нас мала (сотни кбит/сек), то 16к хорошо бы хранить где-то рядом с процом (для быстрого доступа), а вот данные можно и во внешнем более медленном ОЗУ (при наличии DMA память-память и искусстве программирования это почти не скажется на скорости обработки). Идем далее. Его величество POSIX. Если не страдать фанатизмом, и не писать прерывания под POSIX, то большую часть ОЗУ для POSIX вполне можно оттащить во внешнюю память. Т.е. дескрипторы потоков и системные данные нужно хранить в быстрой памяти, а вот стеки, медленные мейлбоксы и streams вполне могут жить во внешней. Что касается приведенной выше мультимедиа, то она примитивна. Запомнинание потока кадров при хорошем DMA будет идти напрямую на SD карточку (если есть аппаратный контроллер SD) с минимальной загрузкой проца. Сжатие JPEG потребудет хорошей скорости от проца, но объем кода там невелик, и при наличии DMA, подтаскавающего/оттаскивающего блоки данных, код и рабочие буфера можно засунуть в ОЗУ 32 кбайт и выполнять с максимальной скоростью. SPEEX тоже довольно экономичен, особенно, если у кристалла есть плавучка. Итак, для решения поставленных задач нам надо: * 32 битный проц 50МГц + * 1Мбайт FLASH на кристалле (можно от 512К) * 64к быстрой SRAM на кристалле * DMA обязательно, в том числе поддерживающее работу с внешней памятью * шинный коммутатор, куча шин, многопортовая SRAM сильно помогут решению задачи * внешняя шина для SRAM/SDRAM, можно 16 бит и не очень быстро. * USB обязательно, Ethernet желательно Это и есть main stream типового host контроллера на ближайшие годы. В этот класс попадают: * LPC24xx NXP (но у него DMA вроде как по внешней памяти лазить не умеет) * LPC29xx NXP (до 120Кбайт ОЗУ и 768 FLASH, внешняя шина, хороший DMA) * LPC28xx NXP, но там засады с корпусом, и очень плохим кешем (который нужно сбрасывать в память вручную при переключении задач) * MCF522x FreeScale (http://caxapa.ru/150036.html http://caxapa.ru/155901.html) * V850 NEC (V850ES/JJ3-E Ethernet, USB, 512 FLASH, 124k SRAM, другие контроллеры семейства http://caxapa.ru/155493.html) * R32C/116 Renesas, тут хорошо, что есть плавучка и 64 битная арифметика * SH7262 / SH7264 Renesas http://caxapa.ru/156162.html * AVR32 AT32UC3A3 Atmel - там пока флеша 256к (хотя в дата шите и 512 упоминается), но у них вроде код очень компактный * STR912 - но увы, это уже в прошлом. ST так и недовела до ума этот крайне перспективный камень, один баг с только 16 битным доступом к внешней PSRAM памяти чего стоит... Заметим еще одну важную деталь. Для успеха проекта типа описанного выше просто компилера и IDE категорически недостаточно. Нужно иметь удобный "редактор ресурсов" - некую базу данных по всем статическим сущностям в ОЗУ. Их нужно в ручную распределять по памяти, вручную настраивать баланс производительность/фрагментация за счет подбора размера fixed memory pool и пр. Может и не вручную, может при помощи программы, написанной на Python. При этом эта программа отношения к коду, исполняемому на контроллере, отношения не имеет. При этом всякие там #pragma и скрипты для линкера должны генерироваться автоматически. Да и сами обращения к таким структарам лучше генерировать кодогенараторами типа: * Templarian http://caxapa.ru/101747.html * cog http://nedbatcheld …code/cog/index_ru.html Я все больше и больше склоняюсь к мысли, над которой я думаю уже много лет, что следующий большой шаг в развитии средств разработки будет в переходе к написанию кода на некоем прото-языке, оптимизированым под работу с IDE, который перед компиляцией будет генериться в С. Ибо в рамках такого подходя парсинг исходников, группировка всяких сущностей а рамках проекта, настройка конфиграции будет куда удобнее, чем при нынешнем подходе.