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

PIC32MZ новые, с M-Class Core + microkernel - созданы друг для друга? Камень на дижикее PIC32MZ2048EFH144-I/PH - 100 шт - $10.48 * FLASH - 2M + 160kB boot * RAM - 512k * 16к кеш кода и 4к кеш данных * 8 банков регистров общего назначения! * CAN, RNG, no Crypto - специально для нас * MMU! * up to 330 DMIPS... даже если надурили, и в реальности их 200-250 DMIPS, все равно чертовски быстро! DV244005 MPLAB REAL ICE - $499.98 там же. Тоскливо, но один раз пережить можно. Чтение доки на камень просто выдавливает в осадок. "Все, о чем мы мечтали, но боялись попросить". DSP 4 64 битных аккумулятора, аппаратная плавучка до дабловой включительно, 8 банков регистров общего назначения... И цена, цена... Errata какая-то удивительно пушистая. Неужто это монстровое ядро уже оттестировали как следует? Как-то стремно, если честно. MPLAB® Harmony Integrated Software Framework http://www.microch …mplabharmony/home.html Вроде бы совсем недавно мы что-то похожее слышали...Renesas Synergy... http://caxapa.ru/649610.html Теперь возникает вопрос, чем рулить этим монстром. Какая RTOS? Можно взять стандартное - RTEMS, eCOS, NuttX http://caxapa.ru/650955.html Вагон и маленькая тележка коммерческих ОСей. Но! У камня есть 3 очень важных фичи: * полноценный MMU * 8 банков регистров * Множественный DMA Которые, если их использовать, сильно добавят кайфа в embedded приложениях. Но для этого ОСька доджа их поддерживать, чего все приведенные выше ОСьки не умеют. Справедливости ради надо сказать, что NuttX: May be built either as an open, flat embedded RTOS or as a separtely built, secure micro-kernel with a system call interface И поддержку банков регистров можно прикрутить, наверное, Т.е. при использовании стандартных ОСей получается тупая конкуренция с Cortex-M7, Renesas RX 2 поколения. Причем шанса выиграть у микрочипа нет - толпа юзеров Cortex-M7 все равно больше (свежекупленный Atmel поможет Microchip в этом), а Renesas все равно сильнее как фирма. Теперь обратимся к идее микроядерности http://caxapa.ru/652378.html http://caxapa.ru/652392.html За счет MMU, относительно большого объема ОЗУ и относительно быстрого процессора, можно создать базовую "микроядерную" среду, которая, скажем, будет эквивалентна в среднем 200 DMIPS ядру и 400к ОЗУ. Причем 7 процессов (процессы ОСи, прерывания) могут быть высокоприоритетными, которые можно вызывать хоть с частотой 1 МГц - нет затрат на сохранение и восстановление стека! И в этой среде нельзя "шарахнуть" по памяти, зато можно, например, творить чудеса следующего рода. Пусть есть высокоуровневый очень сложный код. Он не очень RT. Сам код живет во FLASH, данные в ОЗУ, и инициализируется он быстро. Отлаживать такой код можно долго и нудно, и отлаживать его придется на данных, которые только в поле можно добыть. Пусть этот код упал - шарахнул по памяти, поделился на нуль и проч. MMU все это отсекла, и запустилась соответствующая часть микроядерной ОСи. Код висит, а его входные данные копятся в буфере в ОЗУ. Код устроен так, что он получает на вход блок данных, обрабатывает его, и что-то выдает в ответ. Микроядерка запускает новый инстанс этого кода с новой рабочей областью данных (слава MMU!). Передает коду накопленные данные, и он работает как надо (пока не упадет снова). Замороженный "снапшот" данных кода ставится в очередь на закачку на NAND флешину, и потом, после возвращения из полей, скармливается разработчику. Можно ловить очень редкие и чудесатые баги! Если программа состоит из одних багов, то ничего никуда не закачается до начала нового бага, и "запасная" память резко кончится, но такой хлам в поле не отправляют. Вообще MMU позволит использовать эти 512к ОЗУ очень и очень экономно. Существенным недостатком камня является малоногость и отсутствие SDRAM контроллера. Могли бы и TQFP 176 по примеру Renesas залудить (хотя Reneas серийно даже TQFP 256 выпускает!). Зато есть много достаточно быстрого ОЗУ. Внешняя шина 50 Мгц 16 бит, чтение в 3 такта уложить можно, запись в 3 или 4 - пока не понял. 50*2/4 - 25 Мбайт/сек. Стандартная страница 4к в одну сторону - 160 мкс, что совсем не страшно. 64 кбайта "отсосать" и "залить" - 2.5 мсек. Дальше все понятно. Берем IS66WV51216EBLL-55TLI PSRAM (Pseudo) SRAM 8MB (512K x 16) 55NS 2.5-3.6V 44TSOP 100 - $2.41 Берем CPLD iCE40 Ultra ICE5LP4K-SG48ITR50 IC FPGA 3520LUTS 1.2V 48-ball QFN Package, 0.5 mm, 7.0 mm x 7.0 mm -40°C ~ 100°C 50 - $5.05 И получаем 1 Мбайт страничной памяти с очень малым расходом IO пинов - нужно использовать только ЩД, сигналы управления и несколько пинов адресов - остальная логика с оптимальными для PSRAM таймингом в CPLD. Можно взять IS66WVE4M16EBLL-55BLI IC SRAM 64MB 55NS 48BGA 100 - $3.94 и получить 8 Мбайт. Если мы выделяем 256 к ОЗУ под Lua (что для eLua очень и очень много, можно запустить весьма сложный скрипт), скажем, то отсосать залить - 10 мс, причем в это время процессор сможет спокойно заниматься делом. Если мы запускаем Lua каждые 50 мс, скажем, то вполне нормально. MMU при наличии хорошего шедулера позволит творить чудеса. Пусть у нас есть быстрые статические задачи и некоторое количество динамических задач. Для статических стек и данные всегда живут в ОЗУ по фиксированным адресам. А динамические запускаем так. Пусть они запускаются с тиком 10 мс. Пока задача работает, в фоне, в другом куске ОЗУ идет загрузка области данных другой задачи. При переключении настроим MMU - и новая задача как ни в чем не бывало работает в своем адресном пространства. Данные от старой задачи в это время сбрасываются во внешнюю память. Еще пример из жизни. UFFS http://caxapa.ru/650201.html На больших современных NAND она будет потреблять десятки килобайт ОЗУ. Которых даже в 512к может не найтись. С другой стороны, часто операции можно прогнозировать вперед. Если я пишу лог - то я могу запросить у допиленной UFFS зарезервировать для меня десяток-другой секторов. Т.е. я "засвапливаю" в память 64к (как пример) данные потока UFFS, он выдает мне список зарезервированных секторов, я его храню в отдельной области межпроцессного взаимодействия, потом я вытесняю UFFS от слова совсем, логгерный поток пишет по подготовленной таблице в сектора, он может даже прочитать для надежности и пометить в таблице, что в такой-то сектор плохо записалось, и этот сектор пропущен, а записали в следующий, и потом снова оживляем UFFS - пусть она со всем этим разбирается и готовит мне очередной десяток секторов. Да, а чтобы все эти фокусы хорошо работали, у нас есть 2 ключевых компонента: 8 банков регистров и отдельные, независимые от встроенные в периферию контроллеров DMA, 8 каналов универсального DMA. Процедура обмена с внешней страничной памятью будет быстрой и малонагрузочной для всего остального. MMU также крайне полезен с точки зрения резидентного монитора. А такой монитор очень и очень полезен в реальной жизни. JTAG, особенно USB, очень неудобен при длительных прогонах аппаратуры, и часто сам является источником багов - потом хрен поймешь, от чего устройство повисло. А иметь резидентный монитор, который всегда доступен по сети (например, UDP для простоты) - это супер! Монитор живет в уголке, защищенный MMU, а сам он защищает контроллер прерываний от перепрограммирования. И убить монитор в такой ситуации почти невозможно. В итоге мы имеем массу потенциально много очень интересных фишек PIC32MZ (версия M-Class Core), для реального использования которых нужна в идеале микроядерная ОСька. Кто-то скажет, что я о-ел окончательно, и сложность описанного мною чуда не позволит его отладить в будущем. Верно, при традиционном подходе такое никогда не взлетит. Но у меня все же в голове потихоньку, от года к году, проясняется идеология разработки и отладки очень сложных систем. Вот там это точно взлетит. Основы: * программист пишет код на некотором специальном языке, и код хранится в виде единой БД, нет никакого разбиения на файлы. * прописана системы иерархий, в которой в равной степени перемешаны реальные и виртуальные сущности. Это что-то типа классов, но гораздо мощнее. * код на этом надС верифицируется в полуавтоматическом режиме как с точки зрения функциональных тестов, так и защита от разных ошибок. Полуавтоматически - анализ кода готовит программа, а решения принимает человек. * С код генерится перед компиляцией, одновременно с автоматической генерацией make файлов и файлов линкера. Никаких бинарных библиотек нет в принципе. * встроенная система визуализации чего угодно - чтобы можно было легко и просто гулять по дереву кода, переключаться от графического отображения control flow к коду и прочее * сквозная БД тегов кода с двусторонними ссылками. Т.е. внутри функции тулза для написания кода видит только то, что разрешено использовать функции, в том числе отдельно описанные глобальные переменные. Потом идем в секцию глобальных переменных и смотрим, что их использует, особенно слева от оператора =. Все необходимые для понимания поста документы вложены.