pvvx
Активный участник сообщества
Дети изготавливают поделки с использованием пластилина и не одну, в день... Обычно после сборки поделка разбирается... Это аналогично использованию ESP. Осуждать их в практичности не имеет смысла, т.к. это процесс обучения и не имеет других целей.
Из имеющихся на рынке решений, поставленных в головном запросе, есть всего одно: “Умные часы” (смарт-часы). ESP там не наблюдается. SDK/DDK к таким часам есть, но они “проприетарные” и “для дома для семьи” не годятся, т.к. @nikolz не создал и ничем не приблизил создание открытой бесплатной среды разработки на них.
Карта устройства описанного в заголовке требует необходимость решения таких тех. задач:
1) Организация связи с внешним миром путем использования стандартных протоколов.
2) Накопление и обработка данных.
3) Время разработки и внедрения.
4) Малое потребление.
В зависимости от типа связи (п.п1) и требований надежности получения данных в общей системе, пп2 распределяется на само устройство и внешние сервисы. Доля накопления поступающих/обрабатываемых и прочих диагностических данных на самом устройстве не может быть нулевым и полностью вынесенным за пределы самого устройства. В итоге, чем больше требуемая надежность системы, тем большая часть данных и диагностики должна буферизироваться на самом устройстве, что требует у малых модулей SoC дополнительных ресурсов RAM и/или применения раздельных накопителей (с большой Flash и т.д).
Организация ESP и многих малых SoC не позволяет использовать для буферизации их Flash, т.к. в таких случаях сильно падает производительность и увеличивается потребление, что сказывается на общее время реакции устройства на все события, вызывая большой лаг для реал-тайм системы. Т.е. такая система уже не может обеспечивать нормальный реал-тайм режим. У первых RTL программа и данные, как и у многих малых Linux систем, работает из RAM, а Flash задействуется исключительно в случаях обращения к файловой системе или организованного в ней FIFO для данных, что запросто распределяется на малые атомарные задачи, исключая системные лаги возникающие при записи/стирании страниц Flash и опустошений программного кеша.
К примеру, реакция корректированной Embedded Linux (специально оптимизированной OpenWRT), на одноядерном MIPS с 300 MHz, дает джиттеры на внутренние пересылки между задачами или на внешние (IP) запросы до 5 мс, а в среднем менее 1 мс. Аппаратные прерывания обрабатываются в микросекунды… При наличии встроенного в такой SoC WiFi устройства без своего MCU о реал-тайм можно забыть, не увеличивая кол-во ядер и их частоты, что ведет к дикому потреблению, лишнему нагреву и удорожанию.
Применение MMC/SD карт усложняет и удорожает устройство более чем в два раза на систему “бесперебойного” экстренного питания на завершение операции с ними, разъемы и температурные диапазоны работы, малое ко-во гарантированных перезаписей... Т.е. нет смысла говорить о какой-либо надежности сохранности данных на них – но возможно использование в пластилиновых поделках (с) @nikolz
Изученных и проверенных факторов ещё много, а создавать их полное описание я пока не намерен. По тому в краце:
На сегодня уже куча дешевых китайских SoC со встроенной RAM более 32 Мб, способных удовлетворительно работать с Embedded Linux, обеспечивая приемлемую реал-тайм систему и небольшое потребление. Так-же куча модулей с раздельными шинами к раздельным типам памяти, которые при ненавязчивой оптимизации позволяют получать требуемый уровень реал-тайм всей системы. И становиться совершенно безразлично, какой встроенный или доп. модуль обеспечивает связь устройства с внешним миром, т.к. ресурсы позволяют незаморачиваясь использовать на них Linux подобные системы, а не ковыряться с пластилином.
