ARM, RISC-V контроллеры

Еще раз перечитал доку и понял, что я зря наезжал на отсуствие SDRAM и DMA. Философия камня просто замечательная, я ее не сразу понял. 1. Камень влазит в TQFP с внешним габаритам по выводам 16х 16 мм. Это здорово, т.е. если место очень критично, то самое то. Даже 144 пина занимают уже приличную площадь на плате, не говоря уже про 208. В тоже время камень может стать основой достаточной монстровой системы с внешним SRAM и пр. Приятный диапазон масштабирования. 2. Очень хорошо продумано мультиплексирование периферии. Это не случайность, народ долго рисечил что и как "замешать". IMHO. Не часто такое встретишь. 3. Несмотря на монструозность по памяти, камень стремились сделать очень простым. DMA нормального там нет, чтобы: * не наплодить ощибок в усложенненом шинном коммутаторе * не возиться с многобанковым/многопортовым ОЗУ, а без этого кайф от DMA сильно снижается 3. Количество пинов земли и питания минимизировано донельзя, что большой +. 4. Очень изящная схема бекапа, без отдельного пина. Да, сейчас ее позорно забажили в части того, что ADC в бекап режиме хавает 1 ма, но его, наверное, можно выключить перед засыпанием, да там говорится об испольовании режима сна, при котором питания на ядро и прочее есть, а клоков нет. Надеюсь, пофиксят. 5. Хорошие таймера RTC 32 Кгц. Можно просыпатья по тику 32кгц/3. Выход их режима сна за 10 мкс вроде как гарантирован. 6. Токов потребления нет, но, сдается мне, они будут очень даже приличными. Питяние ядра 1.2В = чип 90 нм. В итоге получился очень сбалансированный чип, который не расчитан на рекорды по скрости, но сможет стать рабочей лошадкой для многих приложений. Но!!! Чтобы выжать все из камня, нужен программизм совершенно другого уровня. 1. В большой RTOS типа eCOS или RTEMS, которая влезет на этот камень в достаточно навороченной конфигурации, нужно иметь конфигурирование параметров выделяемо памяти. Нужно иметь две системы менеджмента памяти - накистальную и внешнюю, и иметь очень гибкие структуры. Т.е. чтобы дескриптор от некоего буфера был на кристалле, а сами данные жили в внешней памяти. Если дескриптор и блок памяти были описаны как структура - то песец, не поканает. 2. Нужно качественное прописывание всего хозяйства вокруг переходя в спящие режимы. По сути, нужные специльные способы описания разных потоков. Типа вот это поток !батарейный, а вот этот - батарейный. Тогда мы перед засыпанием даем команду !батарейным потокам выгрузиться, освободить все ресурсы, в дескрипторе потка пометить, что не надо сейчас к нему обращаться. При возобновлении питания нужно заново иницилизировать _часть_ потоков. 3. Относительно большой объем FLASH позволяет делать нормальное разбиение на уровни. HAL и пр. Не нужно панически бояться немного дополнительного кода, если это сильно повысит качество структуры ПО. Нормальная модель драйверов. Примеров распространенных ОС такого типа я не знаю :) Ждем нового поколения RTOS для таких чипов. Без них они бесполезны.