Я бы даже сказал не землю делать, а кучу пар земля-сигнал для такой конфигурации щупа
Иначе можно ловить все что угодно, но только не то что нужно.
И даже не JTAG, а SWD. Тут опять проблемы разделения на электронщиков и программистов. Если программисты вообще не хотят что-то слышать об интерфейсах, то электронщики ничего не хотят знать об отладочной периферии. У ST в чипах один из лучших отладочных модулей - ARM CoreSight Segger чипы STM32 использует как эталон для своих трассировщиков. А тут UART какой-то, светодиоды ... И еще этот ужасный, бестолковый и неуклюжий PogoPins , это наверно чтоб SWD только в крайнем случае подключали. Между тем даже на самых дешевых отладках сейчас ставят инструментальные чипы для работы через SWD.
Ну вот и стоило было им заниматься. Конечно протокол проприетарный. И там адресация и маршрутизация, и механизмы масштабирования, и механизмы изоляции сбойных узлов и т.д. и т.п. Эт не BLE ломать. Свою платку сделать и уже хакать по полной гирлянду, не волнуясь какие там софтовые заплатки сделает производитель.
Одно дело защитить от хаков какого-то производителя , он и так деньги хорошие делает. И другое дело дать народу проверенную технологию двухпроводного полевого протокола.
Вместо того чтобы ковырять этот несчастный ESP лучше бы расковыряли протокол обмена с лампочками , вот это было бы интересно. Там же их тысячи, а работают удивительно синхронно.
EVT (Engineering Validation Test) — ранний этап разработки аппаратного изделия Т.е. схема по сути невалидная. Никаккого смысла ее разбирать нет. Это еще не упоминая, что такие схемы без трассировки мало что значат.
Возраст здесь ни при чём. Я видел пенсионеров, которые ради фана подсаживаются на архаичные практики — и это нормально. Но не надо выдавать это за ноу-хау, чтобы получить признание.
Я вам так скажу. Если вы работаете с 8–16-ногими микроконтроллерами, используйте чипы с no-code-фреймворком вроде MSP Zero Code Studio и оставьте свои скрипты в прошлом. Если чипы более мощные, то RTT, SWD, USB — обязательно. И чтобы ОЗУ хватало для развёртывания веб-сервера. Тогда вы получите и скорость, и мощность отладки.
Чем быстрее отладочный вывод получает Claude, тем больше итераций в час он успевает сделать.
CMake на ура теперь конвертируются в IAR XML с помощью Claude. Вообще никакой проблемы. И линкерные файлы с тем же успехом конвертирует. Сейчас про скрипты писать - высасывать тему из пальца. Я за час превел весь хостовый стек с CMake Espresiff на IAR. И еще кучу хлама от туда выкинул. Дебажу теперь его c C-Spy в хвост и в гриву. Юзаю всю мощ таймлайнов, ITM ивентов, live view , RTT monitor, tracing. Потому что Espresiff со своим GNU создал неимоверный шлак. CLI - просто жалкий лепет зеленого джуниора, которого только что от ардуины оторвали.
Да знаете ли, паровоз не ждёт пассажиров. Не успели сделать IoT в своих девайсиках — сделают без вас. И облака теперь тоже горячая тема.
Особенно убедительно, когда приплетают холодильники и всякое такое в духе представлений прошлого века. Надеюсь, облака для пылесосов и счётчиков уже не шокируют?
Ось в современном embedded абсолютно необходима. Ее осутствие говорит о том что система недоработана в плане масштабируемости, унифицированности и универсальности. Поэтому некая "каноническая форма" никак не может быть без RTOS. Без RTOS ни стек TСP/IP, ни Bluetooth, ни файловую систему ни что-то другое серьезное невозможно нормально интегрировать. Все они так или иначе будут уворовывать ресурсы времени, которые без RTOS у них отобрать и поделить не получится. Остальные пункты - вкусовщина. Claude Opus за минуты может сделать инфраструктуру для компиляции хоть GNU хоть LLVM И сорсы переделает под них. Но реально на сегодня лучшие инструменты отладки имеют коммерческие тулсы типа IAR или Keil. Поэтому многие SDK от производителей чипов имеют варианты для IAR. И даже Zephyr уже имеет порт для IAR. Сейчас писк моды - делать отладку через WEB интерфейс. Поэтому "каноническая форма" должна обязательно иметь WEB сервер и хранилище WEB страниц. Потому что Claude Opus идеально генерит WEB интерфейс. С графиками, таблицами, формами, редакторами - всем чем хочешь.
Нет у Arduino никакой спецификации железа. Есть спецификация на SDK, которое совмстимо с IDE или CLI. А дальше хоть на улитках делайте. Хотя да забыл , есть некая спецификация посадочного места модулей Arduino. Но это не то.
Как ни странно, но именно для подъемников и простейших лифтов Arduino вполне годится. Там как раз времени на реакцию есть с запасом. Реакция самая примитивная - включить/выключить. А безопасность в лифтах заключается лишь в том чтобы остановиться при любой проблеме и стоять. Умрете ли вы там от голода ожидая техников или получите инфаркт пока откроются двери в наставлении по безопасности не прописано. Поэтому безопасность там делается элементарно на обходе последовательной цепью всех концевиков и заходом на контакторы расцепления питания тормозов и мотора. Все! И Arduino никакого отношения к этому не имеет. Максимум лампочку может зажечь красную.
Да не для чего он не хорош кроме самых примитивных функций. Включить-выключить что-то по времени и вывести в порт - все! Ну может быть еще измерить и только после этого включить-выключить. Достаточно посмотреть на API Arduino Какие принтеры? Какие умные дома? Там в помине нет таких функций. Там даже крутить BLDC моторчик нет функций. Уже не говорю про чтобы крутить по траектории. Другое дело что это API Arduino может лежать поверх mbed А вот там уже все серьезней. Но зачем нужен API Arduino если освоен mbed понять трудно.
С другой стороны SDK под IDE Arduino с базовым Arduino API теперь Claude Sonnet или Opus может слепить за день для любой платы. Но опять вопрос. Если есть Claude Sonnet, то зачем ограничивать себя Arduino API? Сам можеш разработать себе API по вкусу.
По данным официального сайта Arduino, с момента запуска платформы было продано более 50 миллионов плат и клонов. А сообщество насчитывает десятки миллионов активных пользователей по всему миру.
Что-то очень мало. Микроконтроллеров делают разных по 35 миллиардов в год. Я бы задумался об обратном как раз. Почему Arduino занимает так мало места в embedded. Почему так и не вышла за рамки DIY. Почему такая слабая инфраструктура отладки. Почему embedded до сих пор такая сложная область разработки. А видел любителей аrduino, которые при огромном желании так и не поднялись до разработки промышленных решений. А не являетя ли Arduino ловушкой? Обещанием быстрого успеха. Как курсы по IT. Они же эти обещания так легко продаются. А потом фрустрация и выгорание.
Думаю это потому что во взрослом embedded уже никто не заинтересован, чтобы у вас быстро включалась лампочка и закрутился моторчик. Чем больше потратите сил на освоение, тем больше заработают на вас. И в консолидации технологий ни у кого нет интереса. Может ИИ порвет эту порочную схему.
вообще дремучая древность, разработанная в середине 90-х Эт же можно было бы немного так подразобраться в технологиях, а не тупо копипастить из призентаций?
Единственный намек на реальную схемотехнику в cтатье - это отсылка к AMC1306x Но AMC1306x является delta-sigma модулятором. Он не пригоден для взятия моментальных отсчетов. У него даже нет входа синхронизации. Т.е. для всех тех супер пупер плат что там на картинках в начале он не годится.
А так статья ради статьи, никаких практических знаний не несет. Не понятно до каких мощностей преобразования энергии расплескалась фантазия автора. Первая диаграмма как-будто о мегаватных преобразователях. А потом библиотеки перечисляет для DIY-ских проектов. Какая-то несогласованность изложения.
Не в тему , но просто сегодня свалилась еще одна радость от PC-шных программистов. Портировал драйвер Wi-Fi модуля , который пришел из PC-шного линукса. Так там просто в наглую использовали malloc по любому поводу. Куча копирований пакетов между задачами, а как апофеоз - рекурсия в парсинге пакетов , причем куски пакетов на каждом заходе рекурсии выделялитсь в стеке.
Нет , программирование микроконтроллеров не стало легче никак. Он стало труднее, потому что задачи для микроконтроллеров стали труднее и хотят от них больше.
Мануал что ли открываем? Или что открываем? Или панель в отладчике с месивом непонятных битов? Я говорю от прерываниях в проекте, происходящих сейчас и кажду микросекунду. А есть микрокнтроллеры где нет жесткой привязки векторов к периферии в NVIC. Там и мануал не поможет.
Про callback я не понял как вы умудляетесь обойтись дефолтными и разрулить все в RTOS. У вас их пару штук всего ? Как вы передаете ивенты в задачи?
Как минимум, коллбеки сами обрабатывают флаги большинства периферии (за исключением коллбеков ошибок, там да, надо ручками почитать стейты и обработать их).
Callback сами ничего не обрабатывают. Это забота программиста их реализовать. Просто эти реализации должны находиться внутри спец функций объявленных, но не реализованных в API. Пишу так подробно для PC программистов, которые и не подозревают о таких артефактах, приносящих дополнительные страдания. Самый треш в том, что для этих сallback никогда нет четкой спецификации - из каких именно мест они вызываются, из ISR или из обычного потока. И сколько там в нашем распоряжении будет стека и т.п. Хорошо если HAL открыт в исходниках, хотя там встретит стена из макросов и косвенных вызовов. А если это закрытая либа какого-нибудь управления моторами от ST? И при этом она должна работать в жестком риалтайме. Это что? Это боль!
Как смотреть тайминги ISR и их последоавательности, проблем нет. Для этого в C-Spy есть Timeline, где все они видны с точностью до долей микросекунд. Ничего дополнительно в код вставлять не надо. Если надо еще точнее, то есть трасировка в Ozone. Проблема в огромном количестве номенклатуры прерываний. Эт все равно что PC-шника заставить помнить все прерывания на PCI шине или хотя бы думать о них или хотя бы знать о такой шине.
Но конечно, есть embedded-ы, которые ни с чем в своей жизни кроме UART, I2C и SPI не работали. У них может быть свое представление о реальности. Тут не поспоришь. Вселенных есть много.
API то оно предлагает, только реализацию не предлагает. И не может предложить, поскольку это глубоко железо-зависимая вещь. Даже когда у STM32 есть CubeMX и в нем пожно включить RTOS, то все равно HAL не будет использовать сервисы RTOS. И в ISR не будут использоваться семафоры или флаги, а будет туча callback, реализовать которые надо самому программисту. Разве это не слёзы ?!
А ведь могли бы за столько лет уже сделать HAL связанный с RTOS. Этакий фреймворк. Что то похожее лепит Arduino. Но сразу теряет свою аудиторию из-за сложности концепции многозадачности. О синхронизации и тактах то все равно юзеру надо думать. О тактах в embedded не думают только от того что это реально трудно и действуют на авось. Во многих случаях прокатывает. Но в нормальной системе разработчик наизусть должен знать сколько времени у него обрабатываются прерывания от каждой периферии и сколько у него мертвого времени, когда прерывания запрещены и какой джитер прерываний он может получить.
Про MPU тоже я еще не упоминал. А говорил о Trust Zone. А MPU не может дать существенного удобства поскольку ограничено количеством зон. это еще один головняк, и потеря ресурсов на переключение.
Ну да, у меня на столе многоядерный микроконтроллер с тактовой частотой 1 ГГц и отдельным AI-ядром. А я всё равно начинаю писать прикладной софт с конфигурирования таблицы векторов прерываний. Потом перехожу к драйверам, тщательно расписываю приоритеты этих прерываний и оптимизирую обработчики по тактам.
Конфигураторы по-прежнему остаются рекламной заманухой. Да, они сделают стартовую рабочую конфигурацию. Но как только дело доходит до использования всех возможностей периферии — таймерных модулей, цепочечных пересылок по DMA от одной периферии к другой по триггерам от третьих, — весь код конфигураторов летит в топку. ОСРВ тоже, по сути, голые. HAL от производителей никак не коррелирует с ОСРВ, тупо работает на программных задержках и требует тотальной переделки.
Да, у них теперь есть разделение памяти на защищённую и пользовательскую. Мне от этого ни холодно ни жарко — ещё один повод где-то накосячить. Ни одна доступная RTOS эту фичу толком не использует. Да, у них теперь хороший отладочный движок с трассировкой. Но это не отменяет проход по шагам и скрупулёзный подсчёт тактов. Программа сама себя не оптимизирует.
Я бы даже сказал не землю делать, а кучу пар земля-сигнал для такой конфигурации щупа
Иначе можно ловить все что угодно, но только не то что нужно.
И даже не JTAG, а SWD.
Тут опять проблемы разделения на электронщиков и программистов.
Если программисты вообще не хотят что-то слышать об интерфейсах, то электронщики ничего не хотят знать об отладочной периферии.
У ST в чипах один из лучших отладочных модулей - ARM CoreSight
Segger чипы STM32 использует как эталон для своих трассировщиков.
А тут UART какой-то, светодиоды ...
И еще этот ужасный, бестолковый и неуклюжий PogoPins , это наверно чтоб SWD только в крайнем случае подключали.
Между тем даже на самых дешевых отладках сейчас ставят инструментальные чипы для работы через SWD.
Ну вот и стоило было им заниматься.
Конечно протокол проприетарный.
И там адресация и маршрутизация, и механизмы масштабирования, и механизмы изоляции сбойных узлов и т.д. и т.п.
Эт не BLE ломать.
Свою платку сделать и уже хакать по полной гирлянду, не волнуясь какие там софтовые заплатки сделает производитель.
Одно дело защитить от хаков какого-то производителя , он и так деньги хорошие делает.
И другое дело дать народу проверенную технологию двухпроводного полевого протокола.
Ну, ну. Расскажите мне про 1-wire.
Если бы там была 1-Wire, они бы секундами из одного состояния в другое переходили.
Вместо того чтобы ковырять этот несчастный ESP лучше бы расковыряли протокол обмена с лампочками , вот это было бы интересно. Там же их тысячи, а работают удивительно синхронно.
EVT (Engineering Validation Test) — ранний этап разработки аппаратного изделия
Т.е. схема по сути невалидная. Никаккого смысла ее разбирать нет. Это еще не упоминая, что такие схемы без трассировки мало что значат.
Возраст здесь ни при чём.
Я видел пенсионеров, которые ради фана подсаживаются на архаичные практики — и это нормально.
Но не надо выдавать это за ноу-хау, чтобы получить признание.
Я вам так скажу.
Если вы работаете с 8–16-ногими микроконтроллерами, используйте чипы с no-code-фреймворком вроде MSP Zero Code Studio и оставьте свои скрипты в прошлом.
Если чипы более мощные, то RTT, SWD, USB — обязательно. И чтобы ОЗУ хватало для развёртывания веб-сервера. Тогда вы получите и скорость, и мощность отладки.
Чем быстрее отладочный вывод получает Claude, тем больше итераций в час он успевает сделать.
CMake на ура теперь конвертируются в IAR XML с помощью Claude.
Вообще никакой проблемы. И линкерные файлы с тем же успехом конвертирует.
Сейчас про скрипты писать - высасывать тему из пальца.
Я за час превел весь хостовый стек с CMake Espresiff на IAR.
И еще кучу хлама от туда выкинул.
Дебажу теперь его c C-Spy в хвост и в гриву. Юзаю всю мощ таймлайнов, ITM ивентов, live view , RTT monitor, tracing. Потому что Espresiff со своим GNU создал неимоверный шлак.
CLI - просто жалкий лепет зеленого джуниора, которого только что от ардуины оторвали.
Да знаете ли, паровоз не ждёт пассажиров.
Не успели сделать IoT в своих девайсиках — сделают без вас.
И облака теперь тоже горячая тема.
Особенно убедительно, когда приплетают холодильники и всякое такое в духе представлений прошлого века. Надеюсь, облака для пылесосов и счётчиков уже не шокируют?
А так вообще-то речь шла об отладке.
Ось в современном embedded абсолютно необходима.
Ее осутствие говорит о том что система недоработана в плане масштабируемости, унифицированности и универсальности.
Поэтому некая "каноническая форма" никак не может быть без RTOS.
Без RTOS ни стек TСP/IP, ни Bluetooth, ни файловую систему ни что-то другое серьезное невозможно нормально интегрировать.
Все они так или иначе будут уворовывать ресурсы времени, которые без RTOS у них отобрать и поделить не получится.
Остальные пункты - вкусовщина.
Claude Opus за минуты может сделать инфраструктуру для компиляции хоть GNU хоть LLVM
И сорсы переделает под них.
Но реально на сегодня лучшие инструменты отладки имеют коммерческие тулсы типа IAR или Keil. Поэтому многие SDK от производителей чипов имеют варианты для IAR. И даже Zephyr уже имеет порт для IAR.
Сейчас писк моды - делать отладку через WEB интерфейс.
Поэтому "каноническая форма" должна обязательно иметь WEB сервер и хранилище WEB страниц. Потому что Claude Opus идеально генерит WEB интерфейс. С графиками, таблицами, формами, редакторами - всем чем хочешь.
Нет у Arduino никакой спецификации железа. Есть спецификация на SDK, которое совмстимо с IDE или CLI. А дальше хоть на улитках делайте.
Хотя да забыл , есть некая спецификация посадочного места модулей Arduino. Но это не то.
Как ни странно, но именно для подъемников и простейших лифтов Arduino вполне годится.
Там как раз времени на реакцию есть с запасом. Реакция самая примитивная - включить/выключить.
А безопасность в лифтах заключается лишь в том чтобы остановиться при любой проблеме и стоять. Умрете ли вы там от голода ожидая техников или получите инфаркт пока откроются двери в наставлении по безопасности не прописано. Поэтому безопасность там делается элементарно на обходе последовательной цепью всех концевиков и заходом на контакторы расцепления питания тормозов и мотора. Все! И Arduino никакого отношения к этому не имеет. Максимум лампочку может зажечь красную.
Да не для чего он не хорош кроме самых примитивных функций.
Включить-выключить что-то по времени и вывести в порт - все!
Ну может быть еще измерить и только после этого включить-выключить.
Достаточно посмотреть на API Arduino
Какие принтеры? Какие умные дома?
Там в помине нет таких функций. Там даже крутить BLDC моторчик нет функций. Уже не говорю про чтобы крутить по траектории.
Другое дело что это API Arduino может лежать поверх mbed
А вот там уже все серьезней.
Но зачем нужен API Arduino если освоен mbed понять трудно.
С другой стороны SDK под IDE Arduino с базовым Arduino API теперь Claude Sonnet или Opus может слепить за день для любой платы.
Но опять вопрос. Если есть Claude Sonnet, то зачем ограничивать себя Arduino API?
Сам можеш разработать себе API по вкусу.
Что-то очень мало.
Микроконтроллеров делают разных по 35 миллиардов в год.
Я бы задумался об обратном как раз. Почему Arduino занимает так мало места в embedded.
Почему так и не вышла за рамки DIY. Почему такая слабая инфраструктура отладки.
Почему embedded до сих пор такая сложная область разработки.
А видел любителей аrduino, которые при огромном желании так и не поднялись до разработки промышленных решений.
А не являетя ли Arduino ловушкой? Обещанием быстрого успеха. Как курсы по IT. Они же эти обещания так легко продаются. А потом фрустрация и выгорание.
Думаю это потому что во взрослом embedded уже никто не заинтересован, чтобы у вас быстро включалась лампочка и закрутился моторчик. Чем больше потратите сил на освоение, тем больше заработают на вас. И в консолидации технологий ни у кого нет интереса.
Может ИИ порвет эту порочную схему.
Ок, в АЦП для частотников вы не сильны.
Но вот там в статье на рисунке
https://habrastorage.org/r/w1560/getpro/habr/upload_files/a4a/adc/f87/a4aadcf878710d15e871788081ae84a5.png
вообще дремучая древность, разработанная в середине 90-х
Эт же можно было бы немного так подразобраться в технологиях, а не тупо копипастить из призентаций?
Единственный намек на реальную схемотехнику в cтатье - это отсылка к AMC1306x
Но AMC1306x является delta-sigma модулятором. Он не пригоден для взятия моментальных отсчетов. У него даже нет входа синхронизации.
Т.е. для всех тех супер пупер плат что там на картинках в начале он не годится.
А так статья ради статьи, никаких практических знаний не несет.
Не понятно до каких мощностей преобразования энергии расплескалась фантазия автора. Первая диаграмма как-будто о мегаватных преобразователях. А потом библиотеки перечисляет для DIY-ских проектов. Какая-то несогласованность изложения.
GPT не в настроении что ли писал?
Не в тему , но просто сегодня свалилась еще одна радость от PC-шных программистов.
Портировал драйвер Wi-Fi модуля , который пришел из PC-шного линукса.
Так там просто в наглую использовали malloc по любому поводу.
Куча копирований пакетов между задачами, а как апофеоз - рекурсия в парсинге пакетов , причем куски пакетов на каждом заходе рекурсии выделялитсь в стеке.
Нет , программирование микроконтроллеров не стало легче никак.
Он стало труднее, потому что задачи для микроконтроллеров стали труднее и хотят от них больше.
Что значит
Мануал что ли открываем? Или что открываем? Или панель в отладчике с месивом непонятных битов?
Я говорю от прерываниях в проекте, происходящих сейчас и кажду микросекунду.
А есть микрокнтроллеры где нет жесткой привязки векторов к периферии в NVIC. Там и мануал не поможет.
Про callback я не понял как вы умудляетесь обойтись дефолтными и разрулить все в RTOS. У вас их пару штук всего ? Как вы передаете ивенты в задачи?
Callback сами ничего не обрабатывают.
Это забота программиста их реализовать.
Просто эти реализации должны находиться внутри спец функций объявленных, но не реализованных в API.
Пишу так подробно для PC программистов, которые и не подозревают о таких артефактах, приносящих дополнительные страдания.
Самый треш в том, что для этих сallback никогда нет четкой спецификации - из каких именно мест они вызываются, из ISR или из обычного потока. И сколько там в нашем распоряжении будет стека и т.п.
Хорошо если HAL открыт в исходниках, хотя там встретит стена из макросов и косвенных вызовов. А если это закрытая либа какого-нибудь управления моторами от ST? И при этом она должна работать в жестком риалтайме.
Это что? Это боль!
Как смотреть тайминги ISR и их последоавательности, проблем нет. Для этого в C-Spy есть Timeline, где все они видны с точностью до долей микросекунд. Ничего дополнительно в код вставлять не надо. Если надо еще точнее, то есть трасировка в Ozone.
Проблема в огромном количестве номенклатуры прерываний.
Эт все равно что PC-шника заставить помнить все прерывания на PCI шине или хотя бы думать о них или хотя бы знать о такой шине.
Но конечно, есть embedded-ы, которые ни с чем в своей жизни кроме UART, I2C и SPI не работали. У них может быть свое представление о реальности. Тут не поспоришь. Вселенных есть много.
API то оно предлагает, только реализацию не предлагает. И не может предложить, поскольку это глубоко железо-зависимая вещь.
Даже когда у STM32 есть CubeMX и в нем пожно включить RTOS, то все равно HAL не будет использовать сервисы RTOS. И в ISR не будут использоваться семафоры или флаги, а будет туча callback, реализовать которые надо самому программисту.
Разве это не слёзы ?!
А ведь могли бы за столько лет уже сделать HAL связанный с RTOS. Этакий фреймворк.
Что то похожее лепит Arduino. Но сразу теряет свою аудиторию из-за сложности концепции многозадачности. О синхронизации и тактах то все равно юзеру надо думать.
О тактах в embedded не думают только от того что это реально трудно и действуют на авось. Во многих случаях прокатывает. Но в нормальной системе разработчик наизусть должен знать сколько времени у него обрабатываются прерывания от каждой периферии и сколько у него мертвого времени, когда прерывания запрещены и какой джитер прерываний он может получить.
Про MPU тоже я еще не упоминал. А говорил о Trust Zone. А MPU не может дать существенного удобства поскольку ограничено количеством зон. это еще один головняк, и потеря ресурсов на переключение.
Ну да, у меня на столе многоядерный микроконтроллер с тактовой частотой 1 ГГц и отдельным AI-ядром.
А я всё равно начинаю писать прикладной софт с конфигурирования таблицы векторов прерываний. Потом перехожу к драйверам, тщательно расписываю приоритеты этих прерываний и оптимизирую обработчики по тактам.
Конфигураторы по-прежнему остаются рекламной заманухой. Да, они сделают стартовую рабочую конфигурацию. Но как только дело доходит до использования всех возможностей периферии — таймерных модулей, цепочечных пересылок по DMA от одной периферии к другой по триггерам от третьих, — весь код конфигураторов летит в топку. ОСРВ тоже, по сути, голые. HAL от производителей никак не коррелирует с ОСРВ, тупо работает на программных задержках и требует тотальной переделки.
Да, у них теперь есть разделение памяти на защищённую и пользовательскую. Мне от этого ни холодно ни жарко — ещё один повод где-то накосячить. Ни одна доступная RTOS эту фичу толком не использует.
Да, у них теперь хороший отладочный движок с трассировкой. Но это не отменяет проход по шагам и скрупулёзный подсчёт тактов. Программа сама себя не оптимизирует.
Словом, кругом пот и нервы.