Ну и ассемблера там минимум. И то, только потому, что нет тега, говорящего GCC не трогать push при входе в функцию.

Терминал - это вам к Embox) Тут у нас борьба за каждый байт. Сейчас ОС уже прошла испытания временем (месяц устройство на ней проработало стабильно). Далее есть рад замечаний, что будут влиты по окончании тестов. По текущему раскладу удастся высвободит около 300 байт flash на Os, что не мало.

Но вот не знаю, правда. Тут нет MMU, значит динамику априори не закладывали. У нас на подобном на новой работе автопилот работает. Там куча матана крутится с приличной частотой. Проблем с производительностью нет, но это пока что) А вообще чипы огонь. Но они все же реального времени. Там даже классные секции есть мелкие чтобы мелкие ОС туда класть. Они без задержек в этом случае работают.

Просто надо понять, надо ли это делать. Сейчас есть одноплатники примерно за 500 рублей. И там все из коробки. Стоит ли оно того?

Спрашивал раньше, мне говорили что раньше был запуск с флешки. И если сейчас не работает, то надо просто допилить немного. Далее уже вам к ним) Я чате телеграмма спрашивал.

Так можно сделать во FreeRTOS. Вам нужно для этого собрать ваши задачи с флагом "-pie". При том, под Cortex-M0. Как самый младший обратно совместимый. А далее в начало полученного bin файла нужно положить информацию о том, где функция вызова. После этого можно создавать динамически task и ему скармливать функцию из вашего bin. Если нужны внешние зависимости, то можно в экосистеме сделать статическую секцию с указателями на различные функции. И из всех приложений использовать ее.

Если нет желания все это делать самому, то в EMBOX все это есть уже из коробки. Ради этого она и создавалась)

Почему же? Просто цели такой не стояло перед этой разработкой. Вот и все. А чем не устраивают предложенные варианты? Они вроде как раз содержат все что вам нужно. Динамические библиотеки, консоль... По сути, почти Linux)

Не тему "крупных" ОС много чего интересного есть. Та же ChibiOS. Так что те, кто хотел, уже нашел. Да и если много flash и хочется крупного, то embox хороший выбор. У них поддержка классная и примеры есть. Я как-то игрался, но меня больше привлекают мелкие микроконтроллеры. Так что тут увы.

Не. Это уже Embox. Они и сами с этим неплохо справляются. У меня цель "дешево и сердито". Дать минимально нужный от RTOS функционал, стараясь потреблять памяти по-минимуму.

А про M3 и выше. У них я бы добровольно-принудительно при наличии в чипе MPU бы еще использовал) Тоже дополню, как руки дойдут.

Все зависит от задачи и подхода. Я тут готовлю интересную статью. Там я одну и ту же задачу решаю 5-ю разными способами. Чисто чтобы показать разницу в ресурсах и производительности.

Значит в M0 эксклюзивного доступа к памяти нет.

Просто он простой) И для большинства задач его хватает.

Почему бы вам не использовать М3, М4 или М7.

Со временем и их добавлю. Просто не было проектов пока домашних, где было бы необходимо что-то выше M0. Но в планах есть M7. Благо понадобится добавить совсем немного.

В М0 есть что то особенное?

Просто нравится максимальная простота) Ясное дело, что выбирать надо под задачу. В прошлом проекте вот (по ссылке в начале статьи), чтобы байтики копировать туда-сюда без математики почти - больше и не нужно. А вот будущий проект планируется с кучей математики внутри, там M7 рассматриваю с double аппаратным.

Т.к. речь про Cortex-M0, то да. Иначе надежно не сделать.

Вы, видимо, неправильно мой пример поняли, ну, или я плохо объяснил. Там дело и состояло именно в том, что был выбран неподходящий контроллер, много "велосипедного" кода разработчику пришлось писать самому. Понятно, что "все мы человеки", и даже "изобретая велосипед", пусть и по всем спекам, можно допустить ошибки.

Да, я вас не так понял. Если чип был выбран неверно, то это уже другой диалог. Часто вижу картину, когда вместо специально спроектированного под задачу чипа ставят какой-нибудь stm32f415. Просто потому что на нем все делали. Иногда это прокатывает с небольшими издержками. Иногда все оканчивается плачевно.

Собственно, для чего я сделал тогда свое демо: только для того, чтобы показать, что утверждения разработчика о "глючной Windows" и "некорректной имплементации стека BLE" не имеют под собой оснований. И ему (точнее, компании), "скрепя сердце" пришлось искать и фиксить баги в своем коде. 

Ошибки и глюки вполне могут быть. Все же проекты тяжелые. BLE стек вообще считается самым тяжелым вроде как из существующих. Даже тяжелее WiFi. Но ошибки обычно на твоей стороне) Так что да.

Да, когда мы запросили фичу апдейта фирмвари OTA, они нам дали estimate в $200K и 6 months.

А вот такое надо еще на этапе планирования проекта выяснять. Если есть что-то закрытое внутри от производителя, то все может пойти по п***е. Сталкивались с таким. Было неприятно. Пришлось чип менять. Зато "сэкономили" и "не потратили время" на написание своих драйверов. Зачем? Ведь у производителя есть готовое...

Правда, могу откровенно доложить, все это было, в конечно итоге... до "оппы" - на самом деле, никому не было до этого никакого особо дела (поскольку бабки и время тратились не их, а огромной транснациональной корпорации). Вот так обстоят дела в "развитом капитализме" :D

Это тема отдельной дискуссии...

И разработчик, и производитель - вполне себе надежные и авторитетные компании (если вас не смущает по какой-то причине тот факт, что они из Китая).

Для меня порог 10 лет. После прохождения 10 лет я начинаю закладывать в устройства прошедшей порог фирмы микроконтроллеры. То, что она в Китае, не страшно. Опять же при условии, что есть надежные поставщики. То есть, тот же Элитан должен их поставлять.

Думаю, что вы в этом пункте ошибаетесь; с другой стороны, популярность чипа и активно ведущаяся открытая разработка - хорошая гарантия отсутствия критических ошибок.

Вы, неверное (могу ошибаться) не разрабатывали оборудование, которое требует сертификации или используется там, где может быть причинен вред здоровью или жизни человека. В таких проектах обязательным условием ставится наличие полного перечня документации на всю внутреннюю подноготную. В особо тяжелых случаях требуется даже проверять внутреннюю структуру чипов на соответствие заявленного. Именно тут появляется Миландр и остальные российские микроконтроллеры (которые обязуются гарантировать то, что продают и заявляют в документации).

Тут я точно сказать не могу, но можно связаться с представителями https://www.espressif.com/ и выяснить, как обстоит вопрос.

Тут обычно решается вопрос через поставщика. Дается "приватные" контакты и через них уже идут все уточнения. Не только в российских компаниях.

Мне кажется, "за вас" говорит обычная для профессиональных "микроконтроллерных" разработчиков неприязнь к "ардуинщикам" ;)

Буду откровенен. Неприязнь есть. НО. Рациональность важнее. Если проект выглядит идеально с Arduino внутри, то я ее поставлю. Пример: есть мелкосерийная партия ДВС-ов для мелких аппаратов. Внутри контроллер ДВС на открытом Arduino проекте. Оно не плохо так продается. То есть процесс интеграции выглядил просто как разводка платы под нужные габариты, смена пара ножек в коде, а далее уже все ок. Хотя у Arduino есть весомый плюс над ESP32. Он на AVR. А на AVR чипы есть исчерпывающая документация. Так что даже если что-то в библиотеке или проекте бы пошло не так, то можно залезть и посмотреть, почему. А в случае с ESP, если есть ошибка в модуле, на который нет исходников (например, на дергается нужный бит. Или флаг прерывания не сбрасывается при каких-то условиях), то ты единственное что можешь сделать, так это написать разработчикам с просьбой разобраться в произошедшем.

Теперь про то, что вы реализовали функционал намного быстрее, чем программиста, который писался сам. Тут есть один нюанс. Тот программист, который писал все это сам, если написал все правильно, то оно будет надёжнее, и поддерживать это будет проще. Такой подход я одобряю. Да, он дольше по времени. Да, он выходит дороже. Однако. Такое устройство можно будет поддерживать, на протяжении всей жизни проекта. Или пока не закончится поддержка чипа, на который был построен проект.

Опять же, напомню. Что данный чип, который вы так любите, неплохой. У него просто своя область применения. Он прекрасно себя зарекомендовал как средство для прототипирования. Также, как Arduino. Он прекрасно подходит для того, чтобы собрать хоть какой-то более-менее работающий прототип в короткие сроки. С этой задачей он справляется прекрасно. Но использовать его вместе с его экосистемой в реальных устройствах нельзя.

Однако, если нужно выпустить устройство, поддержка которого ограничена выпуском начальной прошивки, а дальнейшая судьба проекта не важна, или поддержка будет производиться очень на коротком сроке, при этом устройство не представляет опасности для жизни человека, тогда применения данного чипа, будет весьма оправдано.

В своих проектах стараюсь пройти все круги ада. Потому что потом на работе мне становится намного легче работать.

Этот чип я выбрал просто для ознакомления. Цели просто решить задачи не было.

В свое свободное время я стараюсь изучать как можно больше разных мало кому известных архитектур и решений в целом. Вдруг среди них найдётся наиболее подходящее решение под проект, который мы будем делать в следующий раз.

А теперь про esp32. У нее закрытый ble и wifi стек. Не очень хорошая документация на периферию в уровне регистров и специфичные средства разработки. Использовать данный SoC в продакшен я не позволю. Почему? Часть причин описал выше. Но есть еще.

1. Сроки поставки и надежность производителя не ясны.

2. Нет возможности в случае ошибки в библиотеках оперативно починить.

3. Не определено время гарантированной поддержки.

Крупные разработчики обычно гарантируют 5/7/10/15 лет поддержки своих микроконтроллеров. Некоторые уже реально более 20 лет поддерживают. А этот чип пока что остается на «поиграться».

А вы выводы после инициализации модифицировали? Там в errata есть как раз проблема с 700 мс ping-ом. Решается доработкой инициализации выводов.

По комментарию выше уже нашел. Но пусть здесь будет для полноты картины.