Таймера организуются в демо приложении. Я не смотрел сколько точно их там. Это не мое приложение и оно специально не оптимизировано, его цель только демонстрация работы сервисов. К тому же включен профайлинг и сбор статистики которые тоже потребляют сотни тактов. И наконец 8 мкс это худшее время, и оно появляется только когда истекает какой либо из таймеров. А так прерывание тика длится все так же в районе 0.6 мкс. Кстати таймера требуются и сервисам с таймаутами. Так что там хватает таймеров.
Потому что так выбрана опция RTOS. Все пользовательские таймеры отрабатываются в этом прерывании. Если выставить опцию обработки таймеров в отдельной задаче, то прерывание тика длиться 0.52 мкс.
Немного не так. Читатели этой статьи только лишь ограничены в “Distribution and Production Use” rights на изделия с этой RTOS на этом чипе. Я же не ограничен портировать и писать статьи про это. Но я не произвожу и не продаю. Это исследовательский проект.
Я вот только сомневаюсь что речь в статье идет о 150 ECU. ECU как было несколько штук так и осталось.
Из книги Electric and Hybrid Vehicles: Design Fundamentals
Речь вероятно идет о 150 микроконтроллерах. Но тогда я думаю это число даже занижено. Поскольку микроконтроллеры могут стоять где угодно: в каждом соленоиде, по нескольку в моторчиках стеклоочистителей, в каждой шине, в каждой кнопке, на каждой лампочке по нескольку, даж в простых акселерометрах есть микроконтроллеры, в ECU их наверно десяток с учетом резервирования.
Я только замечу что навороченные фичи безопасности сами могут приводить к увеличению рисков. Например чтение дорожных знаков не всегда срабатывает и может вводить в заблуждение. Пересечение полосы и препятствия в слепой зоне пикают в самый неподходящий момент отвлекая внимание. Дерганья руля при следовании в полосе тож не очень комфортно может быть, и не интуитивно. Автоматические притормаживания при следовании за впереди идущим автомобилем также некомфортно. Словом есть еще к чему придраться.
Единственно что реально может быть полезно так это экстренное торможение при ударе сзади чтоб не наехать на впереди стоящего. Но эти же никто каждый день не пользуется.
Ну так можно же учиться про себя тихо и не пиариться. А раз пиариться, то добро пожаловать в мир конкуренции. Для себя ли или не для себя, но когда почувствуете холодок бесполезности своего труда, то будет некомфортно. Тут конкуренция в плюс, поскольку может вовремя дать сигнал остановиться.
Еще один минус самописаной оси - самобытная терминология. Эт тож сильный барьер в приобщения к лучшим практикам. К примеру что это - "текущая задача"? Есть термин "активная задача", но она может быть вовсе не текущей в смысле исполняемой в данный момент.
Да и речь не идет о том что автору выбрать, а о том как автору эффективней учиться. И всего лишь.
Своя ось может быть чревата серьезными последствиями. Если вы как разработчик поступательно будете осваивать все более сложные и перспективные платформы, то от своей оси придется отказаться. Но отказаться будет трудно, жалко же потраченных сил. Это приведет к фрустрации и конфликтам с заказчиками.
Какая ни была бы ось она требует поддержки. Например при ее модификациях нужно всегда думать об обратной совместимости, нужно делать порты, нужно также создавать и апгрейдить документацию, нужно делать переходные слои для чужого API сервисов реального времени и т.д. и т.п.
В сети масса исходников заточенных под mbed, uCOS-II , Azure RTOS, Zephyr RTOS, MQX ... Своя ось исключает их из вашего круга интересов. Вернее вы будете их рассматривать только для того чтобы объяснить себе почему они вам не подходят. Это психологическая ловушка.
На самом деле любая из перечисленных может быть запущена на Cortex-M0. Любая из них справиться с тем же что и собственная. У них разница только в глубине и охвате поддержки.
Вот эту глубину и охват и следует изучать. В каких-то из них гораздо подробнее описано как на самом деле работают RTOS и переключатели контекста, в каких-то гораздо больше примеров применения, в каких-то гораздо точнее приведены тайминги и реальный цифры быстродействия, какие-то снабжены уникальными функциями трассировки системных вызовов и контролем переполнения стека и т.д. И вот вместо изучения всего этого богатства вы пилите свою ось.
Access + Excel еще круче.
Прикольно, но я тоже работал на АОН в свое время.
На Access написал приложение и базу данных для страхового брокера, а все отчеты Access переносил автоматически в Excel. Потом Access подключал вместо нативных таблиц к таблицам MS SQL.
Потом еще и Word пришлось подключить для генерации коммерческих предложений.
Словом я бы речь вел за MS Office, а не за один только Excel.
Главное чтоб EURIBOR не поднялся.
А он стабильно в минусе с 2015 года и продолжает падать. Даже COVID его в плюс не вытащил.
Никакой подозрительной динамики вроде не показывает.
Я пытался акцентировать в статье на том что понятие приемлемого брака довольно субъективно.
Для меня даже если в одной из десяти плат возникает подобное замыкание или утечка уже неприемлемо. Очень уж изнурительно искать такие проблемы.
Про термобарьеры полностью с вами согласен, я это и хотел донести в тексте.
Наверно непонятно получилось.
Насчет преимущества общего слоя земли, то тут я бы поспорил.
Когда появляется общий полигон, то теряется управление локализацией токов.
Токи сильноточных и слоботочных цепей начинают взаимодействовать.
Плэйны не такие идеальные как кажется, а скин-эффект делает их еще менее идеальными.
Слаботочные и чувствительные цепи страдают от наводок.
Честно скажу что это 3-я итерация платы, и только после того как более тщательно были отделены земли, я смог нормально измерять токи и напряжения, а DC/DC перестал гореть.
Все наши производители плат поддерживают ширину мостика в 0.075 мм
Если я не могу делать мостик паяльной маски между падами, то я предпочту не использовать такой корпус.
Обычно я использую вот этот тулc — saturnpcb.com/saturn-pcb-toolkit
Правда этот тулс не учитывает категории загрязнения. Тогда зазоры увеличиваются.
Какие загрязнения ожидать нам указывают люди из сертифицирующих компаний и присылают свои таблицы.
Тогда опишите этот случай. Я его не вижу.
Восемь задач. И восемь прерываний от каждой в каждом тике в худшем случае.
Я считаю всегда худшие случаи.
Таймера организуются в демо приложении. Я не смотрел сколько точно их там.
Это не мое приложение и оно специально не оптимизировано, его цель только демонстрация работы сервисов.
К тому же включен профайлинг и сбор статистики которые тоже потребляют сотни тактов.
И наконец 8 мкс это худшее время, и оно появляется только когда истекает какой либо из таймеров. А так прерывание тика длится все так же в районе 0.6 мкс.
Кстати таймера требуются и сервисам с таймаутами. Так что там хватает таймеров.
Сложил длительность всех прерываний ядра за один тик. Не совсем точно, но дает представление о масштабах.
Потому что так выбрана опция RTOS.
Все пользовательские таймеры отрабатываются в этом прерывании.
Если выставить опцию обработки таймеров в отдельной задаче, то прерывание тика длиться 0.52 мкс.
Definition of 'Distribution'
Тут лучше посмотреть в проекте. Словами трудно описать.
https://github.com/Indemsys/Backup-controller_v2.0/tree/main/PCB
evaluation purposes
Немного не так.
Читатели этой статьи только лишь ограничены в “Distribution and Production Use” rights на изделия с этой RTOS на этом чипе.
Я же не ограничен портировать и писать статьи про это.
Но я не произвожу и не продаю. Это исследовательский проект.
Я вот только сомневаюсь что речь в статье идет о 150 ECU.
ECU как было несколько штук так и осталось.
Речь вероятно идет о 150 микроконтроллерах.
Но тогда я думаю это число даже занижено.
Поскольку микроконтроллеры могут стоять где угодно: в каждом соленоиде, по нескольку в моторчиках стеклоочистителей, в каждой шине, в каждой кнопке, на каждой лампочке по нескольку, даж в простых акселерометрах есть микроконтроллеры, в ECU их наверно десяток с учетом резервирования.
Я только замечу что навороченные фичи безопасности сами могут приводить к увеличению рисков.
Например чтение дорожных знаков не всегда срабатывает и может вводить в заблуждение. Пересечение полосы и препятствия в слепой зоне пикают в самый неподходящий момент отвлекая внимание.
Дерганья руля при следовании в полосе тож не очень комфортно может быть, и не интуитивно. Автоматические притормаживания при следовании за впереди идущим автомобилем также некомфортно. Словом есть еще к чему придраться.
Единственно что реально может быть полезно так это экстренное торможение при ударе сзади чтоб не наехать на впереди стоящего. Но эти же никто каждый день не пользуется.
Как правильный и быстрый путь для начинающих я бы советовал переписать или отрефакторить уже готовую ось и лучше не одну.
Ну так можно же учиться про себя тихо и не пиариться.
А раз пиариться, то добро пожаловать в мир конкуренции.
Для себя ли или не для себя, но когда почувствуете холодок бесполезности своего труда, то будет некомфортно. Тут конкуренция в плюс, поскольку может вовремя дать сигнал остановиться.
Еще один минус самописаной оси - самобытная терминология.
Эт тож сильный барьер в приобщения к лучшим практикам.
К примеру что это - "текущая задача"? Есть термин "активная задача", но она может быть вовсе не текущей в смысле исполняемой в данный момент.
Да и речь не идет о том что автору выбрать, а о том как автору эффективней учиться.
И всего лишь.
Своя ось может быть чревата серьезными последствиями.
Если вы как разработчик поступательно будете осваивать все более сложные и перспективные платформы, то от своей оси придется отказаться.
Но отказаться будет трудно, жалко же потраченных сил.
Это приведет к фрустрации и конфликтам с заказчиками.
Какая ни была бы ось она требует поддержки. Например при ее модификациях нужно всегда думать об обратной совместимости, нужно делать порты, нужно также создавать и апгрейдить документацию, нужно делать переходные слои для чужого API сервисов реального времени и т.д. и т.п.
В сети масса исходников заточенных под mbed, uCOS-II , Azure RTOS, Zephyr RTOS, MQX ...
Своя ось исключает их из вашего круга интересов. Вернее вы будете их рассматривать только для того чтобы объяснить себе почему они вам не подходят. Это психологическая ловушка.
На самом деле любая из перечисленных может быть запущена на Cortex-M0. Любая из них справиться с тем же что и собственная. У них разница только в глубине и охвате поддержки.
Вот эту глубину и охват и следует изучать. В каких-то из них гораздо подробнее описано как на самом деле работают RTOS и переключатели контекста, в каких-то гораздо больше примеров применения, в каких-то гораздо точнее приведены тайминги и реальный цифры быстродействия, какие-то снабжены уникальными функциями трассировки системных вызовов и контролем переполнения стека и т.д.
И вот вместо изучения всего этого богатства вы пилите свою ось.
Прикольно, но я тоже работал на АОН в свое время.
На Access написал приложение и базу данных для страхового брокера, а все отчеты Access переносил автоматически в Excel. Потом Access подключал вместо нативных таблиц к таблицам MS SQL.
Потом еще и Word пришлось подключить для генерации коммерческих предложений.
Словом я бы речь вел за MS Office, а не за один только Excel.
А он стабильно в минусе с 2015 года и продолжает падать. Даже COVID его в плюс не вытащил.
Никакой подозрительной динамики вроде не показывает.
Для меня даже если в одной из десяти плат возникает подобное замыкание или утечка уже неприемлемо. Очень уж изнурительно искать такие проблемы.
Наверно непонятно получилось.
Насчет преимущества общего слоя земли, то тут я бы поспорил.
Когда появляется общий полигон, то теряется управление локализацией токов.
Токи сильноточных и слоботочных цепей начинают взаимодействовать.
Плэйны не такие идеальные как кажется, а скин-эффект делает их еще менее идеальными.
Слаботочные и чувствительные цепи страдают от наводок.
Честно скажу что это 3-я итерация платы, и только после того как более тщательно были отделены земли, я смог нормально измерять токи и напряжения, а DC/DC перестал гореть.
Если я не могу делать мостик паяльной маски между падами, то я предпочту не использовать такой корпус.
Правда этот тулс не учитывает категории загрязнения. Тогда зазоры увеличиваются.
Какие загрязнения ожидать нам указывают люди из сертифицирующих компаний и присылают свои таблицы.