Comments 16
Почему-то все кто проектирует драйвера GPIO, рассматривают каждый пин как отдельную сущность, которой можно и возможно управлять только независимо. Это справедливо во многих случаях, когда мы говорим о небольшом наборе отдельных физических сигналов управления. Ну там сброс подать на внешнюю микросхему. Не нередка и другая ситуация: набор проводов, торчащий из контроллера GPIO - это единый набор параметров, который нужно обновлять одновременно, а не по отдельным разрядам. То есть драйвер ОС должен позволять поменять одновременно состояние всех GPIO, находящихся в одном регистре контроллера.
В начале статьи же сказано.
усложнению поддержки и невозможности систематизировать накопленный опыт.
То есть это делается исключительно для удобства самих разработчиков ЗОСРВ «Нейтрино».
А если им будет неудобно, то, вероятно, не будет и развития самой ЗОСРВ «Нейтрино». Так что это неизбежность, с которой надо смириться.
Но опытный разработчик, переходя на новую ОС, в первую очередь должен поинтересоваться, насколько легко в ней снести или игнорировать подобные драйвера.
Теперь поддержку может обеспечивать ИИ.
И да, абсурдность ситуации в том, что в SoC появляется всё больше уникальных функций на GPIO для разгрузки процессора, а разработчики драйверов либо старательно «убивают» их своим архаичным и якобы универсальным API, либо сами запутываются, не имея практического опыта применения всех новых возможностей железа.
Нет, абсурдность ситуации в том, что некоторые разработчики любят использовать костыли, а потом спотыкаться о них. В статье практически ничего про драйвера не сказано, сказано про ПОДСИСТЕМУ, которая обеспечивает работу с GPIO драйверами в системе Нейтрино. Писать драйвер очевидно вы можете как хотите.
Теперь поддержку может обеспечивать ИИ.
А этот "ИИ" с нами в одной комнате и доку на железо прочитает, и с разработчиками кастомного железа свяжется, чтобы разрулить подводные камни, и поддержку потом осуществлять будет?
Да, самая жесть - это когда разработчики делают подсистему. Т.е. когда она встроена в иерхию драйверов и без нее не работает ни один драйвер сверху как : I2C, SPI, USB, SDIO и проч. Тогда беда. Приходится искать другую ось.
Вот если просто API, как например в Azure RTOS, или HAL от ST с легким налетом подсистемы, то можно легко вырезать оттуда с помощью ИИ архитектурные рудименты и жить спокойно.
И да, ИИ читает доку на железо (подозреваю что прочитал уже всю эту доку) и отлично по ней пишет драйвера, странно что вы об этом не знаете.
Постановка вопроса не верна. Если контроллеру, например, Ethernet, требуется управлять физикой через GPIO, то, как ни крути, драйверу этого Ethernet придется дергать пины. От этого вся сетевая подсистема не начинает жестко зависеть от подсистемы работы с GPIO, лишь конкретный драйвер и совершенно безальтернативно (т.е. буквально: нет доступа к GPIO - нет сети).
Колхозить что-то прямо в сетевом драйвере или поюзать штатный драйвер GPIO с задокументированным интерфейсом (aka подсистему) - это решение исключительно разработчика конкретного сетевого драйвера. Жить такой драйвер, вероятно, будет в одном определенном BSP и с этим всё.
То есть, HAL - это нормально, а наличие подсистемы со своим API для упрощения жизни разработчику - нет? И где та грань между "налётом подсистемы" и собственно подсистемой? У вас же никто не забирает возможность обращаться напрямую к контроллеру (через смапированную память) и писать свои костыли. Собственно, автор статьи, как я понимаю, предлагает доп. возможность. Вы написали уже 2 сообщения, но до сих пор не дали никакой конкретики, кроме необоснованного хейта.
И да, ИИ читает доку на железо (подозреваю что прочитал уже всю эту доку) и отлично по ней пишет драйвера, странно что вы об этом не знаете.
Знаем. А ещё знаем, что это работает приемлемо далеко не во всех случаях.
HAL представляет собой набор несвязанных функций, созданных разработчиками HAL, прежде всего, для собственного удобства поддержки большого семейства похожих микроконтроллеров. Интересы конечного пользователя при этом не учитываются.
Максимальную пользу мне, как пользователю, принесли бы чистые исходники и документация, полностью избавленная от упоминаний отсутствующих в моём чипе функций и различных макросов условной компиляции. Поскольку мне и так приходится детально изучать микроконтроллер, я могу либо полностью отказаться от HAL, либо просто игнорировать его.
Однако, когда разработчики RTOS для собственного удобства создают унифицированную подсистему работы с GPIO, это становится гораздо серьёзнее. Унификация сама по себе лишает чипы их конкурентных преимуществ. Конечно, такую подсистему тоже можно попытаться игнорировать.
Проблема в том, что эта практика идёт дальше. В современных микроконтроллерах есть глобальные флаги, блокирующие доступ к регистрам портов, разделение доменов на secure и non-secure, а также недокументированные серые зоны в ROM, связанные с работой периферии. Такая «подсистема» уже не позволяет просто её игнорировать. Мне приходится проверять, нет ли в ней глобальных состояний портов, которые могут конфликтовать с моим кодом, не заблокирован ли доступ к портам в неподходящий момент, и не переключены ли домены между secure и non-secure. И всё это ради чего?
Получается я трачу время за чужой интерес. Просто потому что кто-то недостаточно гибок.
Получается я трачу время за чужой интерес
должен поинтересоваться, насколько легко в ней снести или игнорировать подобные драйвера
Не до конца понимаю о чем у Вас, коллеги, спор, но сдается мне, что он уже далек от основного содержания статьи. Наша ОС не предназначена для работы на микроконтроллерах, а уровнями выше герои, страждущие выкинуть системный драйверный код и сделать всё под себя, исчезают как класс.
По ходу вы сами не в курсе для чего делаете свою операционку:
Либо у вас там куча клонов.
Всё предельно просто. Всё, где нет MMU для нас - микроконтроллер. У кого есть MMU - микропроцессор.
На at91sam9260 запускались вот приблизительно в этих годах (юбилей, однако выходит =)):
С MMU у него всё отлично. Конкретно про SAM7 уже не вспомню как дела обстоят (полагаю, что не хуже SAM9) и кто/зачем его в этот список засунул.
Моя практика показывает что самый востребованный HAL тот, который универсальный и недорогой, под которым можно строить всю бинарную логику под железо на бинарной логике, при этом все вычисления идут от программного ядра (контроллера), в идеале с внешним GPIO При этом локальный центр работает исключительно через его стандартные ПК интерфейсы, к примеру тот же USB, исключение модбас, с которым все индивидуально....
А в чем собственно проблема? Если штатный драйвер не оптимально решает некоторую задачу, всегда можно взять его исходник и включить в код своего проекта с той или иной модификацией, благо обычно такие драйвера у нас идут в сорцах в составе BSP. Микроядерность ОС этому всячески способствует.
Мы же решали задачу наведения порядка и предоставления универсального дизайна типовых драйверов данного класса, который можно и нужно развивать по фидбэкам реальных потребителей. То, что оно не обязано быть оптимальным в каждом частном случае - это действительно так. Т.к. конечных систем мы не производим, то вопрос кастомизации время от времени встает и перед нами и перед потребителями.
Если обязательно одновременно устанавливать разные пины, то это на 99% косяк проектирования железа. Да, видел и реализовывал в HAL вариант изменения пинов по маске в одном регистре, но ни разу не применял. Меня больше удивил набор функций, имхо логичней:
enable(open) - задание/смена режима пина
disable(close) - отключение и перевод в состояние по умолчанию
set, clear, get(read) - понятно и без комментов
Вопрос, а сколько это дает накладных расходов относительно прямого управления?
Сопоставимо с переходом от прямой работы с памятью к передаче сообщений. Но, поскольку, о необходимости прокачки больших объемов данных тут речь не идет, то эти накладные расходы в расчет не берутся.
В противном случае рекомендации по кастомизации под конечное устройство соответствуют тому, что сказано выше. Но у нас самих таких задач не просматривается вне участия в каких-то совместных работах на конкретных конфигурациях.
В качестве синхронизации для многопоточных приложений используется мьютекс.
Можете рассказать подробнее, какие проблемы решаете при помощи мутекса на примере следующего кода?
pthread_mutex_lock( &gpio_mutex );
error = devctl( fd, DCMD_GPIO_WRITE, &cfg, sizeof(gpio_write_t), NULL );
pthread_mutex_unlock( &gpio_mutex );
Подсистема управления GPIO для ЗОСРВ «Нейтрино»