А embededder бы не стал тратить время медленные софтварные решения, а взял бы готовый ARM с DSP сопроцессором типа такого. И имел бы не только вычисления тригонометрии за десяток тактов, но и фильтры и матрици и все отстальное
В статье приведен лишь фрагмент кода. А какой код весь здесь и идет дискуссия. Во-первых что там с RTOS, во-вторых что там с быстродействием (вдруг он в петле PID-а, а сам не детерминирован и тормозной), в-третьих что за архитектура чипа. И от этого всего зависит плох или хорош код.
В целом если бы шла речь о ARM Cortex-M85 я бы такой код без сомнения применил бы. Никакие целочисленные оптимизации в случае M85 существенно код бы не ускорили.
Я пишу про ARM 7...9, ARM Cortex M3..7..85. Т.е. те с которыми работает автор статьи. Про x86 я ничего сказать не могу. Там даже система команд в последних процессорах не вся раскрыта. Так что мало кто квалифицировано может сказать про сопроцессоры x86.
Простейшие Arduino не используют RTOS и сопроцессоров нет и там, конечно, проблемы с float point нет в принципе.
Сбои возникают когда в ходе вычислений одна задача использующая сопроцессор вытесняет другую задачу тоже использующую сопроцессор. Сопроцесор, кстати, может использоваться даже при простом копировании памяти, где в помине нет floatpoint. Так делают супеоптимизирующие компиляторы. А все благодаря тому что ядра процессоров научились автоматически определять факт использования сопроцессора. А скоро пойдут сопроцессоры для ИИ, и будет еще больше нюансов.
Я думал, что у Вас конкретный пример есть. Например, такой.
Забавно то что на протяжении всей статьи автор нигде не назвал тип сопроцессора и процессора. Как будьто программисты на PC работают на неких абстрактных, универсальных и одинаковых машинах.
Программист же микроконтроллеров знает мат. сопроцессор своего микроконтроллера как свои пять пальцев. Каждая операция с floatpoint проверяется на генерируемый ассемблерный код и использование регистров. Если нужны тригонометрические функции, то преверяются все возможные варианты библиотечных функций на скорость и точность.
В старых архитектурах процессоров в ядре OS не поддерживалось сохранение регистров сопроцесора. Либо это сохранение надо было задавать явно. Т.е. либо змедлялось переключение контекста и вся ось змедлялась, либо были сбои вычислений из-за применения сопроцесора floatpoint в ядре без корректного сохранения контекста. Сегодня архитектуры автоматически включают сохранение контекста сопроцессора для отдельных задач, да сопроцессоров стало больше, так что применять даже double в ядре - это нормально. Кому double медленно есть укороченый float, со скростью int. Кому нужен CORDIC, есть у STM микронтроллеры с сопроцессором CORDIC.
Забавно что ML легко адаптируют для определения вибраций мотора, но как то туго идёт внедрение ML для управления мотором чтобы не было вибраций. Разработчики частотников про ML помалкивают и в свои векторные алгоритмы пока не внедряют.
Самая интересность возникает когда ML работает быстро. С ESP здесь уже не угнаться за трендами. Это не их ниша.
Код утилиты закрыт потому что сделан на закрытых компонентах. По другому не получилось.
Сущности типа Release я в своей практике не применяю. Release как некий флаг так же как CI/CD - артефакты командной работы. А здесь DIY проект, даже исследовательский. Все делается единолично и необходимости в процессах нет.
Вот интересно, если на шине цепочкой висит сотня таких девайсов, и все они работают по сути как повторители (сигнал ходит не напрямую от края до края шины), то при скорости среды в 10 Мбит/с, какова будет реальная скорость обмена между первым и последним узлом.
Ну тут уж сами считайте.
А я бы так оценил. Сигнал проходит за 5 мкс по витой паре 1 км . Ещё 6.4 мкс добавляет каждый узел из-за латентности.
Итого на 100 узлов и 100 км получаем 1.2 миллисекунды задержки. Не так уж и плохо. Делаем такт системы в 10 мс и нормально так разруливаем в реальном времени 100 килобайт данных за такт. Т.е. аккурат по килобайту с устройства за 10 мс. А это оцифровка 100 Кгц 8-битного сигнала с каждого сенсора. Очень мощно получается.
Тут надо помнить, что в системах с жёстким риалтаймом применяют time-triggered протоколы. Т.е. никаких коллизий быть не может. Тот же TT CAN или EtherCAT.
Про сложность T1 не знаю что вы имеете в виду. Ну да там есть диагностика повреждений с вычислением дистанции до повреждения. Но я за такую сложность обеими руками бы голосовал. Сложность - это когда проприетарный протокол и без исходников.
Да, и адресация нужна всегда. Если вам кажется что её нет, значит её кто сделал вместо вас.
Я понимаю ваши переживания, но вы чуток передёргиваете
Вот схема из даташита:
А ещё есть топология типа Ring
Чем это физически отличается от CAN? CAN тоже имеет разъёмы, тоже соединяется по цепочке. Прям на провод соплями ничего не вешают. Там также адреса надо выставлять. У вас там датчики не свои? Ну так сделайте свои. У вас же серьёзная задача. Вы ж тут готовы год ждать до появления чипов с CAN XL. А так уже есть решение производительней чем будущий CAN XL.
Я вам скажу что с CAN-ом огребал такие сказочные проблемы, особенно по соседству с частотными преобразователями, что больше никаких иллюзий по поводу его помехоустойчивости не питаю. Всё решают программные стеки.
Если делаете систему с нуля, то не должно быть никакого значения через микросхему проходят сигналы на плате или напрямую от разъёма к разъёму. Поскольку какую-то микросхему все равно ставить придётся.
Однако с CAN XL я чипов не нашёл. А 10Base-T1 уже есть доступные и недорогие. И поверх 10Base-T1 есть масса решений, включая прямой выход в глобальную сеть с огромным количеством опенсорсных проектов.
Я имел виду не расшифровку трафика, а по виду и адресам пакетов определить обращается или нет дивайс к центру авторизации. Если не обращается, значит система замкнута только на один сервер и её легче взломать через этот единственный сервер. Что проверяется в сертификатах, а что нет в библиотеках ESP32 вопрос открытый. Бывает что TLS в микроконтроллере есть, но только доля того чтобы подключиться. Настоящая жёсткая аутентификация по всем полям сертификата не производится. Открыты ли все исходники TLS у ESP32 я не знаю. Может подскажете? С ESP32 не работаю.
Далее, поскольку у ESP32 нет технологии подобной TrustZone в ARM-ах, то на них можно атаковать по способу Interrupt-oriented Bugdoor Programming через сетевое подключение.
Значит я неправильно понимал термин CA. Думал что речь идёт просто о корневом сертификате, а не об отдельном сервере. Тогда да, всё становится на свои места. Словом ваш метод аутентификации в брокере MQTT интересен. Решил тоже его включить в конфиге TLS стека на Azure RTOS.
А embededder бы не стал тратить время медленные софтварные решения, а взял бы готовый ARM с DSP сопроцессором типа такого. И имел бы не только вычисления тригонометрии за десяток тактов, но и фильтры и матрици и все отстальное
В статье приведен лишь фрагмент кода. А какой код весь здесь и идет дискуссия.
Во-первых что там с RTOS, во-вторых что там с быстродействием (вдруг он в петле PID-а, а сам не детерминирован и тормозной), в-третьих что за архитектура чипа. И от этого всего зависит плох или хорош код.
В целом если бы шла речь о ARM Cortex-M85 я бы такой код без сомнения применил бы. Никакие целочисленные оптимизации в случае M85 существенно код бы не ускорили.
Видимо не имеете дело с RTOS, потому и не знаете. Тут просто надо глубже знать контекст.
Я пишу про ARM 7...9, ARM Cortex M3..7..85. Т.е. те с которыми работает автор статьи.
Про x86 я ничего сказать не могу. Там даже система команд в последних процессорах не вся раскрыта. Так что мало кто квалифицировано может сказать про сопроцессоры x86.
Простейшие Arduino не используют RTOS и сопроцессоров нет и там, конечно, проблемы с float point нет в принципе.
Сбои возникают когда в ходе вычислений одна задача использующая сопроцессор вытесняет другую задачу тоже использующую сопроцессор. Сопроцесор, кстати, может использоваться даже при простом копировании памяти, где в помине нет floatpoint. Так делают супеоптимизирующие компиляторы. А все благодаря тому что ядра процессоров научились автоматически определять факт использования сопроцессора.
А скоро пойдут сопроцессоры для ИИ, и будет еще больше нюансов.
Забавно то что на протяжении всей статьи автор нигде не назвал тип сопроцессора и процессора. Как будьто программисты на PC работают на неких абстрактных, универсальных и одинаковых машинах.
Программист же микроконтроллеров знает мат. сопроцессор своего микроконтроллера как свои пять пальцев. Каждая операция с floatpoint проверяется на генерируемый ассемблерный код и использование регистров.
Если нужны тригонометрические функции, то преверяются все возможные варианты библиотечных функций на скорость и точность.
В старых архитектурах процессоров в ядре OS не поддерживалось сохранение регистров сопроцесора. Либо это сохранение надо было задавать явно. Т.е. либо змедлялось переключение контекста и вся ось змедлялась, либо были сбои вычислений из-за применения сопроцесора floatpoint в ядре без корректного сохранения контекста. Сегодня архитектуры автоматически включают сохранение контекста сопроцессора для отдельных задач, да сопроцессоров стало больше, так что применять даже double в ядре - это нормально. Кому double медленно есть укороченый float, со скростью int. Кому нужен CORDIC, есть у STM микронтроллеры с сопроцессором CORDIC.
Забавно что ML легко адаптируют для определения вибраций мотора, но как то туго идёт внедрение ML для управления мотором чтобы не было вибраций.
Разработчики частотников про ML помалкивают и в свои векторные алгоритмы пока не внедряют.
Самая интересность возникает когда ML работает быстро. С ESP здесь уже не угнаться за трендами. Это не их ниша.
Код утилиты закрыт потому что сделан на закрытых компонентах. По другому не получилось.
Сущности типа Release я в своей практике не применяю. Release как некий флаг так же как CI/CD - артефакты командной работы. А здесь DIY проект, даже исследовательский. Все делается единолично и необходимости в процессах нет.
Ну тут уж сами считайте.
А я бы так оценил. Сигнал проходит за 5 мкс по витой паре 1 км . Ещё 6.4 мкс добавляет каждый узел из-за латентности.
Итого на 100 узлов и 100 км получаем 1.2 миллисекунды задержки. Не так уж и плохо. Делаем такт системы в 10 мс и нормально так разруливаем в реальном времени 100 килобайт данных за такт. Т.е. аккурат по килобайту с устройства за 10 мс. А это оцифровка 100 Кгц 8-битного сигнала с каждого сенсора. Очень мощно получается.
Тут надо помнить, что в системах с жёстким риалтаймом применяют time-triggered протоколы. Т.е. никаких коллизий быть не может. Тот же TT CAN или EtherCAT.
Про сложность T1 не знаю что вы имеете в виду. Ну да там есть диагностика повреждений с вычислением дистанции до повреждения. Но я за такую сложность обеими руками бы голосовал. Сложность - это когда проприетарный протокол и без исходников.
Да, и адресация нужна всегда. Если вам кажется что её нет, значит её кто сделал вместо вас.
Я понимаю ваши переживания, но вы чуток передёргиваете
Вот схема из даташита:
А ещё есть топология типа Ring
Чем это физически отличается от CAN?
CAN тоже имеет разъёмы, тоже соединяется по цепочке. Прям на провод соплями ничего не вешают. Там также адреса надо выставлять.
У вас там датчики не свои? Ну так сделайте свои. У вас же серьёзная задача.
Вы ж тут готовы год ждать до появления чипов с CAN XL. А так уже есть решение производительней чем будущий CAN XL.
Я вам скажу что с CAN-ом огребал такие сказочные проблемы, особенно по соседству с частотными преобразователями, что больше никаких иллюзий по поводу его помехоустойчивости не питаю. Всё решают программные стеки.
Если делаете систему с нуля, то не должно быть никакого значения через микросхему проходят сигналы на плате или напрямую от разъёма к разъёму. Поскольку какую-то микросхему все равно ставить придётся.
Во, находятся за 60 сек:
Tini 10 Mbps over 1.6km
Low Complexity, 2-Port Ethernet Switch with Integrated 10BASE-T1L ( Cable reach up to 1700 m )
А говорите всё смотрели.
Вообще на CAN XL я смотрю как на костыли, нужные где-то там в корпоративном секторе автомобилестроения, по их узкоспециальным интересам.
В Ethernet есть куча способов маршрутизации, проекты открыты. Поэтому ограничения на количество узлов на одной физической подсети мало волнует.
Так уже сравнили
CAN XL and 10BASE-T1S – Dataline Performance of Two New Actors in the Networking Arena
CAN XL and 10BASE-T1S – Gateway Performance of Two New Actors in the Networking Arena
Однако с CAN XL я чипов не нашёл. А 10Base-T1 уже есть доступные и недорогие.
И поверх 10Base-T1 есть масса решений, включая прямой выход в глобальную сеть с огромным количеством опенсорсных проектов.
А разве инженеры не разработчики? Чем они тогда занимаются как не разработкой?
Или поменялась семантика слова "разработчик"?
Чем он лучше 10Base-T1 ?
В нерядовых я бы добавил I3C, MII/RMII/RGMII, SSIE, CEU, HDMI-CEC , MIPI SCI, EtherCAT, PCIe ...
Открываю даташит на рядовой STM32 и вижу великолепие разных "протоколов": SMBus ,PMBus , USART , OSPI, LIN , ISO7816 , IrDA , SAI, SPDIFRX, MDIO, USB , TT-CAN, CANFD ...
Редкий специалист знает их все. Идет бесконтрольный рост "протоколов" .
Так что автора понять можно. Легче забыть об этом.
Я имел виду не расшифровку трафика, а по виду и адресам пакетов определить обращается или нет дивайс к центру авторизации. Если не обращается, значит система замкнута только на один сервер и её легче взломать через этот единственный сервер.
Что проверяется в сертификатах, а что нет в библиотеках ESP32 вопрос открытый. Бывает что TLS в микроконтроллере есть, но только доля того чтобы подключиться. Настоящая жёсткая аутентификация по всем полям сертификата не производится. Открыты ли все исходники TLS у ESP32 я не знаю. Может подскажете? С ESP32 не работаю.
Далее, поскольку у ESP32 нет технологии подобной TrustZone в ARM-ах, то на них можно атаковать по способу Interrupt-oriented Bugdoor Programming через сетевое подключение.
Значит я неправильно понимал термин CA. Думал что речь идёт просто о корневом сертификате, а не об отдельном сервере. Тогда да, всё становится на свои места.
Словом ваш метод аутентификации в брокере MQTT интересен.
Решил тоже его включить в конфиге TLS стека на Azure RTOS.