HAL представляет собой набор несвязанных функций, созданных разработчиками HAL, прежде всего, для собственного удобства поддержки большого семейства похожих микроконтроллеров. Интересы конечного пользователя при этом не учитываются.
Максимальную пользу мне, как пользователю, принесли бы чистые исходники и документация, полностью избавленная от упоминаний отсутствующих в моём чипе функций и различных макросов условной компиляции. Поскольку мне и так приходится детально изучать микроконтроллер, я могу либо полностью отказаться от HAL, либо просто игнорировать его.
Однако, когда разработчики RTOS для собственного удобства создают унифицированную подсистему работы с GPIO, это становится гораздо серьёзнее. Унификация сама по себе лишает чипы их конкурентных преимуществ. Конечно, такую подсистему тоже можно попытаться игнорировать.
Проблема в том, что эта практика идёт дальше. В современных микроконтроллерах есть глобальные флаги, блокирующие доступ к регистрам портов, разделение доменов на secure и non-secure, а также недокументированные серые зоны в ROM, связанные с работой периферии. Такая «подсистема» уже не позволяет просто её игнорировать. Мне приходится проверять, нет ли в ней глобальных состояний портов, которые могут конфликтовать с моим кодом, не заблокирован ли доступ к портам в неподходящий момент, и не переключены ли домены между secure и non-secure. И всё это ради чего?
Получается я трачу время за чужой интерес. Просто потому что кто-то недостаточно гибок.
Да, самая жесть - это когда разработчики делают подсистему. Т.е. когда она встроена в иерхию драйверов и без нее не работает ни один драйвер сверху как : I2C, SPI, USB, SDIO и проч. Тогда беда. Приходится искать другую ось. Вот если просто API, как например в Azure RTOS, или HAL от ST с легким налетом подсистемы, то можно легко вырезать оттуда с помощью ИИ архитектурные рудименты и жить спокойно.
И да, ИИ читает доку на железо (подозреваю что прочитал уже всю эту доку) и отлично по ней пишет драйвера, странно что вы об этом не знаете.
усложнению поддержки и невозможности систематизировать накопленный опыт.
То есть это делается исключительно для удобства самих разработчиков ЗОСРВ «Нейтрино». А если им будет неудобно, то, вероятно, не будет и развития самой ЗОСРВ «Нейтрино». Так что это неизбежность, с которой надо смириться.
Но опытный разработчик, переходя на новую ОС, в первую очередь должен поинтересоваться, насколько легко в ней снести или игнорировать подобные драйвера. Теперь поддержку может обеспечивать ИИ.
И да, абсурдность ситуации в том, что в SoC появляется всё больше уникальных функций на GPIO для разгрузки процессора, а разработчики драйверов либо старательно «убивают» их своим архаичным и якобы универсальным API, либо сами запутываются, не имея практического опыта применения всех новых возможностей железа.
Исходники zephyr / freertos / nuttx им уже скормили и они неплохо уже применяют API известных RTOS. И кучу middleware уже знают. Но если middleware тюнингированный, а оси с кастомного конфигурацией, то беда. Они не помещаются в контекст.
Пока все печально. В проекте для простенького приложения на микроконтроллере с RTOS в котором 1 331 225 строк кода находится 16 606 168 токенов. Это в 16 раз больше чем могут теперяшние боты. Ждем наращивания мощностей на порядок. Это еще пару лет видимо.
Кстати перплексити не стоит использовать для поиска. Ищет хуже всех. Совет искать на куче ботов одновременно - вредный. Совет писать по английски - нелогичный. Они прекрано переводят с русского. Так зачем им писать ненативно по английски. Так будет только хуже.
В отличие от «качалки» эти тренажеры не только помогают укрепить мышечный каркас, но и расслабить, растянуть связки, восстановить подвижность суставов и гибкость тела.
В «качалках» веса хотя бы можно регулировать, а тут болтами прикручено непонятно что. И да, на «качалках» очень ясно нарисовано какую группу мышц они качают, а в этом симулякре качается непойми что.
Таких "чудо станков" постоянно периодически появляется. Вот у нас тут раскручивают Performer
«Делают одно и то же» — нет, в текущем виде функция и макрос делают не одно и то же.
Вариант с функцией принимает структуру по значению, и изменение будет потеряно после выхода из функции.
Вариант с макросом изменяет исходную структуру напрямую, т.к. подставляется непосредственно в место вызова. Использование конструкции do {...} while(0) позволяет корректно использовать этот макрос внутри сложных конструкций (if, for и т.п.).
«Второй вариант абсолютно бесплатный» — это справедливо, так как макрос не требует вызова функции, не требует размещения параметров на стеке и т.п.
«Даже inline-функции не бесплатные» — верно. Inline-функции хоть и встраиваются компилятором напрямую в код, но формально не обязаны это делать всегда. Они могут порождать вызовы, в то время как макрос гарантированно встраивается препроцессором.
Берёте VS Code. Ставите в него GitHub Copilot c GitHub Copilot Chat и забываете о всех проблемах стиля и синтаксиса и языка.
Я уже пару месяцев перешел со всех коммерческих редакторов на VS Code с Copilot на базе ChatGPT o1 и Claude 3.7 Sonnet .
Он мне код инициализации регистров того же CAN пишет прямо со скриншота описания этих регистров в pdf даташите ! Причем в формате, который я ему говорю и с такими коментариями, которые я бы сам так четко не написал. А как он пишит коменты к шапкам функций! Прямо читает мысли. Просто фантастика!
Сейчас Claude 3.7 Sonnet итеративно мне нагенерил функций с автоматами состояний для работы по SPI с цепочкой внешних расширителей IO за полчаса. С учетом таймаутов, логами, мьютексами и прочей мишурой. Сам бы такое кодил и отлаживал пару дней. Масса нагенеренных функций на более чем 500 строк не имела ни одной ошибки!
Хочешь он тебе перечисления сделает, хочешь дефайнами все выполнит. Выкинет все идиотские коменты, вставит правильные.Там это вообще плёвое дело переделать исходники под любой формат и стиль. Тот же .clang-format - это детский лепет по сравнению с GitHub Copilot.
Словом не стоит чинить деревянную телегу, когда все уже на электромобилях.
Есть еще проблема при электролитическом травлении меди. Если коробление требует баланса меди между слоями, то электролитическое травление требует равномерности меди в пространстве слоя, чтобы выдержать одинаковые допуски по всей площади.
Да уж, люди то есть, только ответственности у них нет.
Тоже как-то ставили посудомойку. Поставили, воткнул в розетку и ушли. А хозяев било током от неё два года! Ну просто установщики не проверили заземление. А пользователи терпели, потому что научились ходить в правильных тапочках. Но иногда их било не по детски.
А в историю тут рассказанную я не верю. Выдумана на ходу. Все эти препятствия можно было оценить сразу, и решить по другому. Чтобы пять раз ездить в магазин это надо быть совсем больным.
Никак SD карта не может создавать тормоза для WEB интерфейса. Самая слабая нынче даст не менее 12 мбайт в сек на чтение. А вот TCP стек может быть очень тормозным. Это зависит от размеров окна, таймеров повторов , парсера, вычислителя CRC и прочего. Но поскольку во всех таких платформах используют LwIP, то разницы между разными аппаратными платформами с одинаковыми частотами почти не будет. Даже чипы на 120 МГц могут дать под 60-80 мегабит.
Другое дело если нужен будет TLS. Тут программная реализация может кардинально затормозить раз в 10.
Да пишут что сделали уже миллиард. Но не миллиарды. В принципе молодцы. Им не хватает нормальных инструментов. У тех же NXP, ST, Renesas есть удобные графические тулсы для конфигурации пинов, периферии и кодогенерации. А у ESP до сих пор этого нет и вместо SWD архаичный JTAG. Да цена многое определяет. Сейчас поставил этот ESP как вспомогательный модуль для связи на плату. Большего от него не жду. Слишком дорогая отладка на ESP получается.
Если говорить про Teensy 4, то согласен, что это слабое подражание ESP. Это чисто игра в маркетинг. Экосистема Arduino рассчитана на неквалифицированных разработчиков. Куда им столько пинов использовать. Да ещё с многозадачностью. Да ещё там даже SWD не выведен. Тут видимо игра на криптозащищенный , залоченый бутлодер. Чтобы ардуинщики могли скрывать свои наивные секреты. Да, знаю, есть такая категория разработчиков, которые любые свои проблески идей норовят засекретить. Гримассы рынка, что поделать.
Тут надо смотреть шире и дальше. Так узко как вы видите проблему я перестал видеть уже много лет назад. Думать надо не о том что вы делаете сейчас, а о том что будете делать ещё 10 лет. Уверяю - это гораздо выгодней.
Серию RT в свое время я рассматривал для своих модулей. Но они скатились на FreeRTOS и стало не интересно. А так они легко могут управлять четырьмя! BLDC движками в коптерах. Если тоже самое пытаться сделать на ESP то будет гораздо дороже. Придётся ставить отдельные драйверы на процессорах на каждый мотор.
Вообщем ESP имеет преимущество в очень узкой и очень примитивной нише. Нигде их миллиардами не применяют. Вот ARM, да применяют миллиардами. Те-же ST можно видеть в духовках, пылесоса, стиралках... И именно поэтому пока появляется один новый ESP, за это же время появляется десяток новых ST.
Якобы произвольная конфигурация пинов на ESP сильно переоценена. Там при такой конфигурации драматически теряется скорость переключения сигналов. О чем и пишут в мануале. Скажем управлять RGB светодиодами на 4 МГц через такое мультиплексирование уже не прокатит. Поэтому ESP никому и не нужен. Никто в мире не пытается сделать клоны ESP или делать что-то аналогичное. Странно, да? Это при такой бешеной якобы популярности. На самом деле ESP морально устарел как только был изготовлен. Они даже 5ГГц не могут сделать. За развитием Bluetooth им не угнаться. Это при том что нормальные SoC - и типа nRF91 уже могут LTE-M/NB-IoT Скажем честно, что ESP - это от хронической технологической отсталости.
У ARM ар поводу этого есть отдельная errata. Этот баг исправляют не так.
Вообще странно читать от разработчика под ARM-ы столько перечислений багов и ничего про баги связанные с шинами и кэшировнаием. Видимо потому что эти баги так и остались нерешенными.
Кстати было бы интереснее прочитать про баги которые так и остались в коде и их заткнули заплатками. Самые жуткие нерешаемые баги обычно связаны с дефицитом RAM в микронтроолерах из-за чего приходится химичить с опенсорсами, которые писали под линукс, но портировали на микроконтроллеры. Например, ничего нельзя поделать с фрагментацией кучи.
А вот про железо тема тут как-то превратно трактуется. Вот те что вошли в рейтинг "немало крутых статей на эту тему" на мой взгляд к железу имеют мало отношения. Это все околоPC-ишное или винтажное. Где тут спрашивается про хардкорное актуальное встраиваемое железо? Должна быть номинация "современное встраиваемое железо". А то одно разочарование.
По ходу вы сами не в курсе для чего делаете свою операционку:
Либо у вас там куча клонов.
HAL представляет собой набор несвязанных функций, созданных разработчиками HAL, прежде всего, для собственного удобства поддержки большого семейства похожих микроконтроллеров. Интересы конечного пользователя при этом не учитываются.
Максимальную пользу мне, как пользователю, принесли бы чистые исходники и документация, полностью избавленная от упоминаний отсутствующих в моём чипе функций и различных макросов условной компиляции. Поскольку мне и так приходится детально изучать микроконтроллер, я могу либо полностью отказаться от HAL, либо просто игнорировать его.
Однако, когда разработчики RTOS для собственного удобства создают унифицированную подсистему работы с GPIO, это становится гораздо серьёзнее. Унификация сама по себе лишает чипы их конкурентных преимуществ. Конечно, такую подсистему тоже можно попытаться игнорировать.
Проблема в том, что эта практика идёт дальше. В современных микроконтроллерах есть глобальные флаги, блокирующие доступ к регистрам портов, разделение доменов на secure и non-secure, а также недокументированные серые зоны в ROM, связанные с работой периферии. Такая «подсистема» уже не позволяет просто её игнорировать. Мне приходится проверять, нет ли в ней глобальных состояний портов, которые могут конфликтовать с моим кодом, не заблокирован ли доступ к портам в неподходящий момент, и не переключены ли домены между secure и non-secure. И всё это ради чего?
Получается я трачу время за чужой интерес. Просто потому что кто-то недостаточно гибок.
Да, самая жесть - это когда разработчики делают подсистему. Т.е. когда она встроена в иерхию драйверов и без нее не работает ни один драйвер сверху как : I2C, SPI, USB, SDIO и проч. Тогда беда. Приходится искать другую ось.
Вот если просто API, как например в Azure RTOS, или HAL от ST с легким налетом подсистемы, то можно легко вырезать оттуда с помощью ИИ архитектурные рудименты и жить спокойно.
И да, ИИ читает доку на железо (подозреваю что прочитал уже всю эту доку) и отлично по ней пишет драйвера, странно что вы об этом не знаете.
В начале статьи же сказано.
То есть это делается исключительно для удобства самих разработчиков ЗОСРВ «Нейтрино».
А если им будет неудобно, то, вероятно, не будет и развития самой ЗОСРВ «Нейтрино». Так что это неизбежность, с которой надо смириться.
Но опытный разработчик, переходя на новую ОС, в первую очередь должен поинтересоваться, насколько легко в ней снести или игнорировать подобные драйвера.
Теперь поддержку может обеспечивать ИИ.
И да, абсурдность ситуации в том, что в SoC появляется всё больше уникальных функций на GPIO для разгрузки процессора, а разработчики драйверов либо старательно «убивают» их своим архаичным и якобы универсальным API, либо сами запутываются, не имея практического опыта применения всех новых возможностей железа.
Исходники zephyr / freertos / nuttx им уже скормили и они неплохо уже применяют API известных RTOS. И кучу middleware уже знают. Но если middleware тюнингированный, а оси с кастомного конфигурацией, то беда. Они не помещаются в контекст.
Пока все печально.
В проекте для простенького приложения на микроконтроллере с RTOS в котором 1 331 225 строк кода находится 16 606 168 токенов. Это в 16 раз больше чем могут теперяшние боты.
Ждем наращивания мощностей на порядок. Это еще пару лет видимо.
Кстати перплексити не стоит использовать для поиска. Ищет хуже всех.
Совет искать на куче ботов одновременно - вредный.
Совет писать по английски - нелогичный. Они прекрано переводят с русского. Так зачем им писать ненативно по английски. Так будет только хуже.
А между тем ChatGPT научился рисовать слова почти без ошибок:
Не думаю что империалисты когда нибудь объединяться чобы победить единым AI.
Они и так в своих программных статьях рассматривают его как оружие.
Читаем эти перлы - https://situational-awareness.ai/wp-content/uploads/2024/06/situationalawareness.pdf
Скорее всего они разбомбят друг друга прежде чем AGI успеет сказать первые слова.
В «качалках» веса хотя бы можно регулировать, а тут болтами прикручено непонятно что.
И да, на «качалках» очень ясно нарисовано какую группу мышц они качают, а в этом симулякре качается непойми что.
Таких "чудо станков" постоянно периодически появляется. Вот у нас тут раскручивают Performer
А потягайтесь-ка с GPT!
Правильность утверждений:
«Делают одно и то же» — нет, в текущем виде функция и макрос делают не одно и то же.
Вариант с функцией принимает структуру по значению, и изменение будет потеряно после выхода из функции.
Вариант с макросом изменяет исходную структуру напрямую, т.к. подставляется непосредственно в место вызова. Использование конструкции do {...} while(0) позволяет корректно использовать этот макрос внутри сложных конструкций (if, for и т.п.).
«Второй вариант абсолютно бесплатный» — это справедливо, так как макрос не требует вызова функции, не требует размещения параметров на стеке и т.п.
«Даже inline-функции не бесплатные» — верно. Inline-функции хоть и встраиваются компилятором напрямую в код, но формально не обязаны это делать всегда. Они могут порождать вызовы, в то время как макрос гарантированно встраивается препроцессором.
Всё это уже потеряло смысл.
Берёте VS Code. Ставите в него GitHub Copilot c GitHub Copilot Chat и забываете о всех проблемах стиля и синтаксиса и языка.
Я уже пару месяцев перешел со всех коммерческих редакторов на VS Code с Copilot на базе ChatGPT o1 и Claude 3.7 Sonnet .
Он мне код инициализации регистров того же CAN пишет прямо со скриншота описания этих регистров в pdf даташите ! Причем в формате, который я ему говорю и с такими коментариями, которые я бы сам так четко не написал.
А как он пишит коменты к шапкам функций! Прямо читает мысли. Просто фантастика!
Сейчас Claude 3.7 Sonnet итеративно мне нагенерил функций с автоматами состояний для работы по SPI с цепочкой внешних расширителей IO за полчаса. С учетом таймаутов, логами, мьютексами и прочей мишурой. Сам бы такое кодил и отлаживал пару дней. Масса нагенеренных функций на более чем 500 строк не имела ни одной ошибки!
Хочешь он тебе перечисления сделает, хочешь дефайнами все выполнит. Выкинет все идиотские коменты, вставит правильные.Там это вообще плёвое дело переделать исходники под любой формат и стиль. Тот же .clang-format - это детский лепет по сравнению с GitHub Copilot.
Словом не стоит чинить деревянную телегу, когда все уже на электромобилях.
Есть еще проблема при электролитическом травлении меди.
Если коробление требует баланса меди между слоями, то электролитическое травление требует равномерности меди в пространстве слоя, чтобы выдержать одинаковые допуски по всей площади.
Да уж, люди то есть, только ответственности у них нет.
Тоже как-то ставили посудомойку. Поставили, воткнул в розетку и ушли. А хозяев било током от неё два года! Ну просто установщики не проверили заземление. А пользователи терпели, потому что научились ходить в правильных тапочках. Но иногда их било не по детски.
А в историю тут рассказанную я не верю. Выдумана на ходу. Все эти препятствия можно было оценить сразу, и решить по другому. Чтобы пять раз ездить в магазин это надо быть совсем больным.
Никак SD карта не может создавать тормоза для WEB интерфейса. Самая слабая нынче даст не менее 12 мбайт в сек на чтение. А вот TCP стек может быть очень тормозным. Это зависит от размеров окна, таймеров повторов , парсера, вычислителя CRC и прочего. Но поскольку во всех таких платформах используют LwIP, то разницы между разными аппаратными платформами с одинаковыми частотами почти не будет. Даже чипы на 120 МГц могут дать под 60-80 мегабит.
Другое дело если нужен будет TLS. Тут программная реализация может кардинально затормозить раз в 10.
Да пишут что сделали уже миллиард. Но не миллиарды. В принципе молодцы. Им не хватает нормальных инструментов. У тех же NXP, ST, Renesas есть удобные графические тулсы для конфигурации пинов, периферии и кодогенерации. А у ESP до сих пор этого нет и вместо SWD архаичный JTAG. Да цена многое определяет. Сейчас поставил этот ESP как вспомогательный модуль для связи на плату. Большего от него не жду. Слишком дорогая отладка на ESP получается.
Если говорить про Teensy 4, то согласен, что это слабое подражание ESP. Это чисто игра в маркетинг. Экосистема Arduino рассчитана на неквалифицированных разработчиков. Куда им столько пинов использовать. Да ещё с многозадачностью. Да ещё там даже SWD не выведен. Тут видимо игра на криптозащищенный , залоченый бутлодер. Чтобы ардуинщики могли скрывать свои наивные секреты. Да, знаю, есть такая категория разработчиков, которые любые свои проблески идей норовят засекретить. Гримассы рынка, что поделать.
Тут надо смотреть шире и дальше. Так узко как вы видите проблему я перестал видеть уже много лет назад. Думать надо не о том что вы делаете сейчас, а о том что будете делать ещё 10 лет. Уверяю - это гораздо выгодней.
Серию RT в свое время я рассматривал для своих модулей. Но они скатились на FreeRTOS и стало не интересно. А так они легко могут управлять четырьмя! BLDC движками в коптерах. Если тоже самое пытаться сделать на ESP то будет гораздо дороже. Придётся ставить отдельные драйверы на процессорах на каждый мотор.
Вообщем ESP имеет преимущество в очень узкой и очень примитивной нише. Нигде их миллиардами не применяют. Вот ARM, да применяют миллиардами. Те-же ST можно видеть в духовках, пылесоса, стиралках... И именно поэтому пока появляется один новый ESP, за это же время появляется десяток новых ST.
Якобы произвольная конфигурация пинов на ESP сильно переоценена. Там при такой конфигурации драматически теряется скорость переключения сигналов. О чем и пишут в мануале. Скажем управлять RGB светодиодами на 4 МГц через такое мультиплексирование уже не прокатит.
Поэтому ESP никому и не нужен. Никто в мире не пытается сделать клоны ESP или делать что-то аналогичное. Странно, да? Это при такой бешеной якобы популярности.
На самом деле ESP морально устарел как только был изготовлен. Они даже 5ГГц не могут сделать. За развитием Bluetooth им не угнаться.
Это при том что нормальные SoC - и типа nRF91 уже могут LTE-M/NB-IoT
Скажем честно, что ESP - это от хронической технологической отсталости.
Баг с номером 11 явно не решен.
У ARM ар поводу этого есть отдельная errata. Этот баг исправляют не так.
Вообще странно читать от разработчика под ARM-ы столько перечислений багов и ничего про баги связанные с шинами и кэшировнаием.
Видимо потому что эти баги так и остались нерешенными.
Кстати было бы интереснее прочитать про баги которые так и остались в коде и их заткнули заплатками.
Самые жуткие нерешаемые баги обычно связаны с дефицитом RAM в микронтроолерах из-за чего приходится химичить с опенсорсами, которые писали под линукс, но портировали на микроконтроллеры. Например, ничего нельзя поделать с фрагментацией кучи.
А вот про железо тема тут как-то превратно трактуется.
Вот те что вошли в рейтинг "немало крутых статей на эту тему" на мой взгляд к железу имеют мало отношения. Это все околоPC-ишное или винтажное.
Где тут спрашивается про хардкорное актуальное встраиваемое железо?
Должна быть номинация "современное встраиваемое железо". А то одно разочарование.