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

Похоже, Вы подтолкнули меня к более четкой формулировке мысли! Linux имеет смысл использовать: * нужны продвинутье коммуникационные возможности * для решения целевой задачи нужны хорошие IPC (Inter Process Communications) * есть (почти) готовый софт(ы) для решения целевой задачи. Linux имеет четкие минимальные требования: * 2 Мбайт FLASH для загрузки * 8 Мбайт RAM для работы (лучше 16; в 8 самый минимум влезет, либо надо использовать специальные урезанные версии ядра) Эти требования долго были не дешевы, да и сейчас они не тривиальны (если рассматривать очень дешевые тиражные устройства). Собственно, до сих пор нет _однокристального_ девайса, а на котором бы пошел Linux (многокристальные сборки не в счет). Если от Linux нужна не вся крутизна, а, скажем, только POSIX и BSD Sockets, то имеет смысл использовать *nix подобную встраиваемую ОСь. Собственно, по такому пути и пошли создатtли eCos и RTEMS (и многих других осей - эти две наиболее популярны). Для них надо 256к FLASH 64...128...256k RAM. Пример - в LPC2106 eCos с POSIX успешно влазит, но места там остается не много. Если начать навешивать на типовой MCU с ARM7 внешние FLASH и SRAM (например, LPC22xx), то это получается не дешево, и, как много раз считалось, полноценный (Linux | uClinux) будет стоить ненамного дороже - зачем же тогда городить огород? STR91xx претендует на то, чтобы кардинально сломать ситуацию. Лишние 32к ОЗУ (по сравнению с распространенными 64Кбайтными вариантами) дают шанс засунуть довольно нехилое приложение с BSD Sockets, POSIX, и какой-нибудь вполне нормальной embedded OS (eCos | RTEMS | много чего еще) в _один_ кристалл (внешний MII не проблема). Теперь по поводу многослоек. Безусловно, для макетирования 4-х слойка куда удобнее (ну и пусть она на 150$ дороже стоит) - тут и спорить нечего (если, конечно, речь не идет о примитивной плате на LPC21xx, например). Для малых тиражей - тоже, поскольку реальная стоимость 4-х слойки в общей структуре себестоимости _правильно менеджируемого_ проекта не так уж и велика. Теперь представим, что у нас тираж 1000шт/мес. Поскольку Ethernet сеть есть в любом современном офисе (раcсматриваем платежеспособные фирмы) и почти в любом современном приличном доме, то применений у embedded ethernet масса. Рассмотрим два решения * AT91RM9200 -- CPU -- FLASH -- SDRAM -- MII -- разъем с трансформатором -- печатная плата ---- либо компактная 4-х слойка ---- либо довольно большая 2-х слойка * STR91xxx -- CPU -- MII -- разъем с трансформатором -- печатная плата ---- компактная двух-слойка Очевидно, что второе решение будет заметно дешевле. Даже экономия 5$ на таких тиражах - это уже не игрушки (я бы не отказался от такой "прибавки" к своей ЗП)! "Ага, прозрел, сукин сын!" - скажет кто-то из любителей "жесткой оптимизации". А я на это отвечу - как сказано в методологии XP программирования - оптимизировать нужно толко то, что действительно в этом нуждается; не стоит ничего серьезно оптимизировать заранее - не угадаете (кроме общей структуры - ее стоит оптимизировать изначально и постоянно, не скатываясь, разумеется, к постоянное переделке проекта). Если говорить о сетевых приложениях, то есть два пути оптимизации. Лично я не вижу никакого смысла брать и писать IP стек на ASM в надежде впихнуть все в "мелкий" камень - это просто пустая трата времени. Количество глюков такой реализации закроет дорогу к массовым продажам устройства - а без массовых тиражей тут и говорить не о чем (пользователи устройства за 1000р могут не оценить Ваши усердие по еженедельному выпуску новой прошивки). Можно взять uIP http://www.sics.se/~adam/uip/size.html Это более перспективно, но в силу ограниченности ресурсов ограниченость стека все равно скажется - сегментация пакетов, отсутствие PPP и пр. lwIP куда более перспективен http://savannah.no …gnu.org/projects/lwip/ Если же взять готовую и отлаженную ОСь с POSIX Threads (можно ругать (eCos | RTEMS), можно хвалить, то pthreads... () там точно работают!), и тот же lwIP или даже встроенный в ось BSD стек, то в пользовательском приложениие имеет смысл заниматься "жесткой оптимизацией". Ибо системные глюки ОСь + стек маловероятны, а Ваши глюки Вы, в принципе, можете и дожать. Тут и вдумчивое изучение асмового листинга своей программы поможет, и переписывание отдельных кусов на asm руками, и пр. "все тяжкие". Такое устройство вполне можно продавать 1000+ тиражами, и суппорт не "умрет" от "багодарных клиентов". Судя по мейл листу lwIP он не идеален, но его юзают в тысячах проектов - так что основные баги там точно пофиксили. В общем, STR91xx открывает дорогу к принципиально новым проектам, которые удастся впихнуть в "однокристальное" решение путем "разумной" оптимизации, а не путем написания 256к кода на асме. А это новый рынок :) По старым постам. MAC - я имел в виду кончено же Multiply and Accumulate. Я догадываюсь, что компилер может и не уметь его юзать - придется ручками на асме критические места алгоритма переписывать (их обычно не так уж и много). Интересно, а RVDS может юзать MAC от 926 ядра и других с этой "фишкой"? Может, глупость скажу, но вроде как есть понятие "intrinsic fucntions" - это тут нельзя использовать?