NN-PID - это в некотором смысле чёрный ящик. Сомнительно, чтобы для него была актуальна ручная экономия тактов.
Повторюсь, либо у нас NN-PID (на оптимизированном под это железе), которому мы верим. И тогда "руками ничего не трогать!". Или мы не верим NN-PID (ну или STM32N в контексте нашего проекта слишком дорог). Тогда мы выносим его за скобки дискуссии.
RPU, конечно, не умеет в AI. Только сама парадигма AI не подразумевает использования тех приёмов, про которые говорится в статье.
Тут либо мы доверяем AI рулить реалтаймом - и тогда что RTOS, что RPU, что ПЛИС остаются не у дел в контексте задач реалтайма. Либо мы не доверяем AI и тогда STM32N остаётся не у дел - именно в нашем реалтайме.
Не исключаю, что весь драматургический конфликт в статье и обсуждении - это потасовка в отцепленном вагоне истории. Но тем не менее, этот вагон един и для RTOS, крутящихся на одном ядре, и для Ситары и для какого-нибудь MAX-10.
Допускаю, конечно. Но пока что-то никто аргументы привести не смог.
Тогда как вы смотрите на такой вариант: я подсоберу аргументов на что-то среднее между заметкой и статьёй, потегаю вас и мы продолжим более обстоятельно в ней?
попытка написать программу с кучей ветвлений <...> FPGA будет очень больно...
...для человека ничего не писавшего на FPGA. В реальности программа, написанная, например в парадигме автоматного программирования будет что на процессорной архитектуре, что на FPGA даже по синтаксису очень похожей.
с какой-нибудь математикой
Приведите, пожалуйста конкретный пример, чтобы я вам наглядно продемонстрировал, что FPGA за ту же цену, что и MCU насчитает всё гораздо быстрее.
То, что вы изложили - набор матёрых мифов. Единственное ключевое преимущество процессорных архитектур перед FPGA - армия людей, умеющих писать на Си и не умеющих на Верилоге.
А ещё в темы про ассемблер для Cortex-M, ведение микроконтроллера на ARM в каждый такт, устройство внутренних шин и гарантии реакции на то или иное событие, по опыту прибегает 10⁶ типов, рассказывающих в лучших традициях:
"Не, а зачем вам? Вы расскажите конкретно какая у вас задача? Сейчас так не делают, сейчас не считают такты, сейчас у микроконтроллеров есть прерывания, таймеры и фигаймеры, всем всего всегда хватает".
Визитной карточкой таких спецов это сравнение жигулей с мерседесом - видимо люди душой ещё в 90х :)
Я думал, эта специфика и эти метафоры - отличительная черта профессиональных сообществ из СНГ, но нет! :) На electronics.stackexchange в теме про подсчёт тактов на Cortex-M мне тип начал говорить, что это всё равно, что после Кадилака 1950-х годов спрашивать как завести с крюка Фольксваген Гольф.
Он очень был доволен собой ровно до момента, пока я не кинул ссылку на Sitara AM437x, у которого есть центральное высокопроизводительное ядро на ARM с частотой за ГГц и два дополнительных ядра с частотами по 200МГц и гарантией, что каждая ассемблерная инструкция на них выполняется ровно за 1 такт. Причём сам TI и говорит, что эти два ядра нужны для Ensuring real‑time predictability.
В своё время в профильных сообществах интересовался, почему живы RTOS, если для задач, специфичных для них гораздо лучше походят ПЛИС? Не являются ли RTOS и аналогичные сущности попыткой "искать не там где потерял, а там, где светло"?
"Вы шшшштооо! Как вы можете?! Это настолько оскорбительно, что мы даже обсуждать это не будем!" был наиболее частый ответ :))))
Сейчас собираются вопросы, штук 10 уже собрано. Как наберётся 15-20, разошлю список вопросов. Дальше зависит от того, как у кого со временем. Потом - публикация отчёта.
Судя по общей активности - отчёт будет где то через 1,5 месяца.
NN-PID - это в некотором смысле чёрный ящик. Сомнительно, чтобы для него была актуальна ручная экономия тактов.
Повторюсь, либо у нас NN-PID (на оптимизированном под это железе), которому мы верим. И тогда "руками ничего не трогать!".
Или мы не верим NN-PID (ну или STM32N в контексте нашего проекта слишком дорог). Тогда мы выносим его за скобки дискуссии.
На каком микроконтроллере (ну плюс-минус, чтоб NDA не раскрывать) вы реализуете управление двигателем?
RPU, конечно, не умеет в AI. Только сама парадигма AI не подразумевает использования тех приёмов, про которые говорится в статье.
Тут либо мы доверяем AI рулить реалтаймом - и тогда что RTOS, что RPU, что ПЛИС остаются не у дел в контексте задач реалтайма. Либо мы не доверяем AI и тогда STM32N остаётся не у дел - именно в нашем реалтайме.
Не исключаю, что весь драматургический конфликт в статье и обсуждении - это потасовка в отцепленном вагоне истории. Но тем не менее, этот вагон един и для RTOS, крутящихся на одном ядре, и для Ситары и для какого-нибудь MAX-10.
Тогда как вы смотрите на такой вариант: я подсоберу аргументов на что-то среднее между заметкой и статьёй, потегаю вас и мы продолжим более обстоятельно в ней?
Вы допускаете, что этот концепт не понимаете вы?
В ваш мозг у меня лаза нет и что вы понимаете под "подрыгать моторчиком" без вашего уточнение - вопрос интерпретации.
Если речь про "штуку, которая закрывает шторы", то с этим и что-нибудь на NE555 и 74 логике справится. Кстати, любопытный вызов.
И какую же RTOS вы на нём развернёте?
Пока единственное, что реально - это бросание заезженым лозунгом.
FPGA for motor control
...для человека ничего не писавшего на FPGA. В реальности программа, написанная, например в парадигме автоматного программирования будет что на процессорной архитектуре, что на FPGA даже по синтаксису очень похожей.
Приведите, пожалуйста конкретный пример, чтобы я вам наглядно продемонстрировал, что FPGA за ту же цену, что и MCU насчитает всё гораздо быстрее.
То, что вы изложили - набор матёрых мифов. Единственное ключевое преимущество процессорных архитектур перед FPGA - армия людей, умеющих писать на Си и не умеющих на Верилоге.
А ещё в темы про ассемблер для Cortex-M, ведение микроконтроллера на ARM в каждый такт, устройство внутренних шин и гарантии реакции на то или иное событие, по опыту прибегает 10⁶ типов, рассказывающих в лучших традициях:
"Не, а зачем вам? Вы расскажите конкретно какая у вас задача? Сейчас так не делают, сейчас не считают такты, сейчас у микроконтроллеров есть прерывания, таймеры и фигаймеры, всем всего всегда хватает".
Визитной карточкой таких спецов это сравнение жигулей с мерседесом - видимо люди душой ещё в 90х :)
Я думал, эта специфика и эти метафоры - отличительная черта профессиональных сообществ из СНГ, но нет! :) На electronics.stackexchange в теме про подсчёт тактов на Cortex-M мне тип начал говорить, что это всё равно, что после Кадилака 1950-х годов спрашивать как завести с крюка Фольксваген Гольф.
Он очень был доволен собой ровно до момента, пока я не кинул ссылку на Sitara AM437x, у которого есть центральное высокопроизводительное ядро на ARM с частотой за ГГц и два дополнительных ядра с частотами по 200МГц и гарантией, что каждая ассемблерная инструкция на них выполняется ровно за 1 такт. Причём сам TI и говорит, что эти два ядра нужны для Ensuring real‑time predictability.
...зато легко вставлять не по месту комментарии про "сравнение тёплого с мягким" :)))
В своё время в профильных сообществах интересовался, почему живы RTOS, если для задач, специфичных для них гораздо лучше походят ПЛИС? Не являются ли RTOS и аналогичные сущности попыткой "искать не там где потерял, а там, где светло"?
"Вы шшшштооо! Как вы можете?! Это настолько оскорбительно, что мы даже обсуждать это не будем!" был наиболее частый ответ :))))
Сейчас собираются вопросы, штук 10 уже собрано. Как наберётся 15-20, разошлю список вопросов. Дальше зависит от того, как у кого со временем. Потом - публикация отчёта.
Судя по общей активности - отчёт будет где то через 1,5 месяца.
Статистически он будет стоять на месте. А дрейфовать под воздействием поля, я полагаю, он будет как раз с постоянной скоростью.
Я что-то передумал насчёт своего ответа на этот вопрос :) Может сюда заглянет физик, который даст обоснованное объяснение.
Тогда с вас 1 электротехнический вопрос :) (как водится, в личные сообщения, либо в тг, либо на почту)
Потому, что я скрыл его в черновики, предварительно рекомендовав скопировать все мои технические статьи локально.
Зато в предыдущий раз вы задали один из лучших вопросов, на мой вкус.
Вам спасибо - за участие!
Рад,что вам понравилось! Будем готовится к следующему электроквизу? :)
Это не баг, а фича. Что если автор вопроса в своём ответе сморозил чепуху, а другой участник дал куда более правильный ответ? :)
Именно :) Про его-то отпайку ничего не говорилось :)
А почему не наоборот: камеру и микрофон залить эпоксидкой, а порт/разъём - отпаять? :)))
Ну или всё залить эпоксидкой, либо всё отпаять? :)