Есть VESC - известный опенсорсный контроллер BLDC: http://vedder.se/2015/01/vesc-open-source-esc/ Моё устройство планируется на Rockchip 3399: http://www.orangepi.org/Orange%20Pi%20RK3399/ (не обязательно на этой плате, но они все похожи). Есть ли шанс малой кровью портировать этот VESC, написанный на C, c STM32 + ChibiOS на ARM53/72 + Linux? Двигателей будет от 2 до 6. Вроде мощи у RK3399 достаточно, интерфейсов тоже. Внешние чипы (DRV8302) ес-сно сохраняются.

Ни малейшего. Ибо Linux - это не ОСРВ совсем.

В этом опенсорсном проекте используется куча таймеров и специальная периферия для генерации PWM и синхронной с ним рабты ADC.
А в RK3399 нет ни подходящего 6-и канального генератора PWM, ни синхронизируемого с ним ADC.
Т.е. на RK3399 невозможно сделать нормальное управление даже одним BLDC мотором.

Я бы рекомендовал посмотреть на i.MX RT1050. На них легко сделать 4-е полнофункциональных контроллера BLDC моторов.
Если надо больше моторов, то потребуется сделать еще один модуль на i.MX RT1050.

А я бы порекомендовал посмотреть на KV58.

Я бы порекомендовал, TLE9879QXA40

Большое спасибо за ответы. Вопрос снимается, буду использовать VESC как есть, по крайней мере для прототипа. Тем более, что софт, говорят, практически непортабелен: https://vesc-project.com/node/323 Насчёт Линукса и ОС РВ в целом соглашусь. Но RK3399 настолько мощнее и многоядернее STM32, что проблем быть не должно. На крайняк одно ядро можно освободить под это путём cgroups/isolcpus. Специализированные контроллеры брать не интересно - цель была упростить систему, повесив всю программируемую логику на центральный проц. Если не судьба, можно жить и с STM32.

Никакая мыслимая многоядерность не заменит отсутствующей периферии - ногодрыгом не сделать 6-ногий ШИМ с dead-time-ми и тем более не сделать многоканальный АЦП. Придётся ещё плисину навесить, чтоб работало.

Даже на ядре 1ГГц ногодрыгом GPIO не сделать нужный ШИМ? Если нет, можно ли какую-то микруху на GPIO или на другой интерфейс навесить для этих целей? Проблема в том, что VESC - это немало весьма специфического кода на C, который придётся поддерживать и развивать отдельно от основного. Хочется, чтобы весь код был в Линуксе, в одной архитектуре.

А какая связь между частотой ядра и частотой GPIO? На какой частоте у Вас GPIO работает? Оно может вообще на 10МГц работать.
И не только в частоте GPIO дело: чтобы сделать качественное управление, нужно точно выдерживать временные интервалы сигналов и временные зависимости сигналов между собой.
Выдерживать их нужно с точностью до нескольких единиц нс (типичное время переключения современных силовых транзисторов - пару сотен нс).
Без этого ничего путнего не получите.
А сделать это можно только аппаратно, запрограммировав периферию на нужные действия. В STM32 такая периферия есть, есть она в Вашем МК?
Опять-же - как измерять фазные токи? В схеме в этом проекте измеряются они на шунтах, шунты включены в нижние ключи ШИМ, а значит - нужно точно успевать запустить и закончить АЦ-преобразование за время гарантированного пассивного вектора по всем фазам. А длительность его стараются сделать как можно меньше, для увеличения эффективности работы инвертора.
И ещё куча моментов. Всё это делать нужно одновременно с жёсткими временными зависимостями. Чего никак не достичь программно ногодрыгом, да ещё на многоядерной системе, где могут быть непредсказуемые задержки доступа разных ядер к общей шине, а ещё тем более - из под линуха.


Эту "микруху" автор исходников уже навесил - STM32F405, и видимо предусмотрел возможности управления её от внешнего МК - вот и используйте.
Тем более, как видно по Вашим фразам, Вы вообще не разбираетесь в теме. Сильно сомневаюсь, что сможете что-то "портировать" не смотря ни на какие ГГц. Для этого надо сперва изучить теорию и аппаратные средства.

Не сделать: ногодрыг на 1ГГц Cortex-A зачастую медленнее и непредсказуемее, чем на 100MHz Cortex-M.
Просто на первом никто не ставит такой задачи, и тот же GPIO может быть подключен через кучу мостов
на медленной шине.


А смысл иметь этот код в Линуксе? Оставьте тот же STM32 в качестве "микрухи" - это дешево и не создаст
лишней головной боли.

Судя по всему, чувак решил очень нетривиальную задачу, само решение - результат большого исследования.
Насколько я понимаю, там все совсем не просто, и попытка заменить мотор может стоить второго такого же исследования.

Судя по всему главное в этом проекте - это понимание теории, реализованной в задаче, а вовсе не то, каким образом будет осуществляться ногодрыг. Поэтому для начала я бы попытался все просто повторить, и запустить на желаемом приводе.

А потом возможно и задачи и хотелки радикально изменятся)))

Так проект же экспериментальный, там нет никаких железно отлаженных алгоритмов.
Например обсервер скорости вращения ротора мужик взял из сомнительного исследования - http://cas.ensmp.fr/~praly/Telechargement/...aly-Astolfi.pdf,
о чем прямо в тексте и сообщает.
В его PID алгоритме реализован anti wind-up примитивным ограничением диапазона.
А основной алгоритм базируется на безсенсорной коммутации BLDC с измерением напряжения обратной ЭДС.
Эти алгоритмы очень хорошо описаны в апнотах всех основных производителей.
Обычные НЧ фильтры имеют длину в 128 коэффициентов! Причем профайлинга нигде не видно. Пробовл ли он вообще это юзать?

Заслуга разработчика - это создание приложения BLDC Tool и видеологера с врезками телеметрии из BLDC Tool.
Но протокол не документирован, и жестко зашит в программе.
Протокол может работать только через один из интерфейсов: CAN, USB, UART и еще какой-то там левый модуль.

Сам BLDC Tool прошивает для своей работы некие левые бинарники вместо штатного фирмваре. Т.е. похоже автор кое-что скрывает.
В свой проект фирмваре он засунул историю всех версий железа, причем версии железа не описаны. Это тоже будет сильной привязкой к услугам автора.

Хотя ссылка в целом интересная.
Но проект явно не предназначен даже для интеграции с другой аппаратной платформой. Он заточен исключительно под BLDC Tool.
Автор постарался это сделать тщательно избегая комментирования своих сорсов. Ну это наверняка ему самому аукнется.

Там обычный FOC. Теория которого много где описана. Просто реализовал её. И не очень оптимально даже.
Даже названия переменных и функций соответствуют названиям из теории.


А вот здесь - прямо в точку!


У меня тоже сразу этот вопрос возник - насколько использованы ресурсы CPU по быстродействию?
У автора в описании указано "Since there are plenty of CPU-resources left..." - только как это понимать, "plenty" - это загрузка CPU 20% или все 80%? "Сколько вешать в граммах?"

Не факт, что FOC он нормально запустил.
FIR фильтры он формирует не обращая внимание на фазовые задержки.
Какой режим управления : сенсорную коммутацию, безсенсорную коммутацию или FOC задается командами с внешнего интерфейса.
Поэтому чисто на юзере проблемы с быстродействием если они возникнут.

Тут ещё многое зависит от того какую задачу требуется решать с применением электродвигателей. На мой взгляд задачу превильне решать с применением плис или современного SoC. В плис делаете аппаратный модуль генерации ШИМ + + канал токового АЦП + энкодерный канал если нужно.
Так же с модуля генерации ШИМ сигнала выходит сигнал прерывания по фазовому циклу. По этому сигналу вы синхронизируете момент записи нового значения ШИМ и опрос АЦП токов в разные моменты времени. Обработка энкодера если нужна тоже аппаратная. В ПЛИС делаете регистры откуда забирать данные о состоянии мотора и регистры куда записывать задание. А уж какой процессор вы выберете для обсчёта регуляторов это дело вкуса. Ваш на частоте 1ГГц справится с обсчётом кучи моторов. Главное что генерация ШИМ, обработка АЦП и энкодеров идут в реальном времени и не нагружают процессор. Он по прерыванию фазового цикла например 10кГц обсчитывает регулятор мотора и выдаёт новое задание в ПЛИС.
Правда при этом подходе про портирование опенсорс проекта не приходится говорить, но сейчас всякие FOC и прочее не проблема.

ПРиложил Вам документ где объясняется как шим генерить и почему обычный процессор там не вариант.

Если не хочется заморачиваться с ПЛИс у TI есть отличные мощные процессоры для управления моторами. Например http://www.ti.com/lit/ds/symlink/tms320f28377d.pdf У него аппаратный ШИМ. аппаратный модуль энкодеров и отдельные сопроцессоры реального времени для задач мотор контрола и аппаратная поддержка обсчёта тригонометрических функций. Я бы на вашем месте куда нибудь в эти стороны смотрел.

Это конечно на порядок сложнее решения, но уж зато точно во всём разберётесь, да и моторы сможете любые крутить

Да ещё ситара от TI кроме всего имеет на борту всё необходимое для управления 3-я моторами точно

А что будет если линух не отдал вовремя время задаче, считающей и кладущей в эти регистры. И линух, как тут уже упомянули, это вправе сделать - он не реалтайм ОС. А заранее посчитать и положить данные сразу для многих периодов ШИМ - не получится, так как расчёт должен быть выполнен по последним как можно более свежим данным о токах и положении ротора. Надо именно на каждый период ШИМ запускать новый цикл расчёта.
Так что если ПЛИС - то и все расчёты в ней должны быть.

Так и я и AlexandrY и Василий об этом и толкуем - сильно правильнее и проще взять "моторозаточенный" контроллер от TI/NXP/Infineon и делать на нем, чем заниматься дендрофекальным конструированием на GPIO.

Если говорить в принципе, то линух дал бы случайные задержки не более пары мкс на таком SoC-е как у TC
Тут будут промахи кэша, задержки на шинах, сохранение огромных контекстов и т.д.
Это не критично для управления обычным коптерным BLDC у которого 10000 об.мин с 4-я полюсами, т.е. 2000 коммутаций в сек.
Такое автор бы сделал легко на GPIO и даже без DMA.
Но у него нет синхронного быстрого многоканального ADC чтобы между коммутациями отловить переходы через 0.
Поэтому безсенсорная комутация под вопросом. На RK3399 же нет документации.
С другой стороны можно приладить внешний SPI ADC.
Автор должен будет делать большие запасы на угол коммутации из-за чего получит пониженный КПД.
Короче при большом желании и упертости и сниженных требованиях к качеству регулирования можно сделать и на одном RK3399, но отладка будет адской.

Это может если оформить как драйвер. Или ещё как.
На прошлой работе коллеги, ваявшие девайс на линухе, очень долго бодались с одной проблемой: им надо было писать поток данных (осциллографирование) во внешнюю флешь. И всё вроде нормально работало и писало, но иногда, неведомо по какой причине, происходила задержка - в течение нескольких сотен мсек (около 200мс), не отдавалось время их задаче. Хотя кроме их задачи в системе вроде и не запущено было ничего. В результате - пропуск, потеря данных. Приостановить поток они не могли - их устройство должно было принимать его как SPI-slave.
Грешили на работу какого-то драйвера в используемой сборке линуха.
Точно уже не помню - удалось им забодать проблему или она их забодала.

и сколько интересно будет стоить такая разработка, и такое серийное изделие ?)

скажем по другому: во сколько десятков раз это будет дороже исходного варианта ?)))

Ещё раз всем спасибо, очень продуктивная дискуссия. Добавлю несколько уточнений. По специальности я программист, но не embedded, и тем более не профи в электронике. В данном проекте я выступаю как автор идеи и инвестор. Если я решу отказаться от VESC, делать замену будут нанятые люди с соответствующим опытом. Моя задача - понять, что это даст и во что выльется.

Речь идёт тяговых двигателях мобильной робототехнической платформы. Это могут быть и мотор-колёса, и традиционные, с внутренним ротором. Обороты низкие (до 300 об/мин, если без редуктора). Стартовый момент высокий (100 кг/см и выше). На прототипе, вероятно, будут стоять мотор-колёса от гироскутера, вот они под управлением VESC: https://www.youtube.com/watch?v=xPtFhArhz-8 Датчики холла там есть, и будет добавлен энкодер. Высокооборотных, шаговых и др. моторов не будет.

RK3399 тут некоторые недооценивают. У него есть таймеры и другие фичи, характерные для контроллеров: http://opensource.rock-chips.com/wiki_RK3399 (внизу ссылка на даташит) Там 6 ядер, разделённых на три кластера: два ядра A72 2HGz, четыре A53 1.5GHz + два ядра M0 (фактически встроенный 32-битный контроллер с "deterministic, high-performance interrupt handling for time-critical applications"). Cовременный Линукс позволяет выделить процессу ядро практически в эксклюзивное пользование, без переключения контекстов, прерываний (даже системного таймера, т.н. tickless режим). К тому же у кластеров ядер отдельные кэши.

Портировать VESC я уже раздумал. Но в том, что RK3399 + низкоуровневый обвес (АЦП, ШИМ) не подходит под задачу - пока не убедили. Специализированные BLDC-микрухи брать не очень хочется, т.к. желательна возможность модификации алгоритмов и нежелательна жёсткая завязка на вероятных партнёров. ПЛИС - пожалуй, лучший вариант на перспективу, но для прототипа дороговато, да и ясности по требованиям достаточной нет.

Интересно чьи вы инвестируете: свои или чужие ?) Помнится Баффет говорил, что секрет успешных инвестиций в хорошем знании инвестиционной темы.

Соль этого проекта в механике, электронике и физике.

Инвестирую свои. Мобильная платформа - не главная составляющая, ничего особенного от неё не требуется.

на форуме где-то недавно пробегал мужик, который хочет автоматизированные тележки для складов. Лавры amazon ему покоя не дают, видите ли)

Так вот он там всем сломал все мозги за простое управляемое поворотное колесо... Попробуйте найти ту тему. На складе абсолютно идеальные из всех возможных условий условия. Оказалось, задача построения самоуправляемого складского шасси - совсем не тривиальная. Ведь если колесо поворотное, то силу и управление на привод нужно подавать через токосъемник. Кроме того, у колеса есть проскальзывание.

В другой теме обсуждается система лоцирования объектов на складе (в цеху), космические проблемы на пути, и разработчики в драку пытаются решить кто возьмет за это больше миллиардов $, а кто уже взял...

Еще хуже, если у вас не склад. Тогда просто попробуйте себе представить шасси автомобиля. У Вас случайно не Маск и не Прохоров фамилия ?

У вас уже готовая мобильная платформа и все эти вопросы уже решены ?
Значит, соль всей системы в интеграции платформы с какой-то фишкой - зачем вам тогда свои сервы - ведь они глубоко интегрированы в платформу и являются одной из малых ее частей ?

Или вы уже прошли весь процесс до самого верху, построили большую систему, а теперь начинаете декомпозицию ?
Почему-то мне кажется, если бы это было так, вы бы задавали другие вопросы...

Вопросы вы задаете про ключевой элемент (по вашему мнению) телеги, и про интеграцию (Allwinner pcie x86). А это значит что вы в начале пути, а не в конце...

Тогда все сложнее. Вам нужно векторное управление.
Просто используя BLDC коммутацию на таких низких оборотах вы получите неприятные акустические шумы, вибрации, нестабильную скорость и соотвественно траекторию и позиционирование.
А векторное управление - это очень много диагностической информации, ну вы сами видели как BLDC tool выглядит.
И там есть еще далеко не все что нужно для отладки.
А в RK3399 один Cortex-M0 занят подсистемой питания, другой на подхвате у периферийных драйверов.
Сомнительно что вы перепишете или хотябы проанализируете все драйвера на предмет зависимостей от этих Cortex-M0
Т.е. о них я бы забыл в этой задаче.
Кэш то свой имеют ядра, но шина AHB на всех одна. На GPIO и на таймеры, как выясняется, DMA в RK3399 не работает.
Нет, слишком много граблей.
ИМХО. Миссия невыполнима.

Так мы не оцениваем его, мы отвечаем на ваши вопросы. Вы ничего не говорили ни про его таймеры ни про прочую необходимую периферию. А только про ядра да ногодрыг. Вам и сказали, что так задачу не решить.


Если под "специализированными BLDC-микрухами" Вы имеете в виду МК с нужной периферией, то какая разница - писать прошивку для него или прошивку для ПЛИС?


Так ли нужно именно "ЧЕРЕЗ ТОКОСЪЕМНИК"? Например на асинхронник с короткозамкнутыми обмотками, ток в обмотки ротора подаётся без всяких токосъёмников. И там уже течёт ток. Проскальзывание да - при этом необходимо.

не очень вас понял. Представьте себе, что вот это колесо моторизованное.
Как без токосъемника будете туда управление и мощу передавать ? Навесняком, чтобы все болталось на соплях ?

Передать куда? У любого колеса есть подвижная и неподвижная части. Неподвижная - прикреплена к корпусу транспортного средства. Вот в неё и подавать мощу.

если неподвижная - поворотная (те по отношению к корпусу получается подвижная все-таки).
Я этот вариант имел в виду)

В амазоновской телеге если не ошибаюсь все 4 колеса такие.

Если поворотная - значит подвижная.
Тот чел вроде хочет что-то новое изобрести? Вот пусть изобретёт сферические колёса. Или какой-то их аналог. Само то будет для складской телеги.
Вот пусть будут как обычные - один статор и один ротор, но в виде сферы. И теорию управления ими изобретёт.
А энергию туда (в сферический ротор) наверняка можно придумать как передать. Придумали же как её передать в ротор в асинхронном двигателе. Причём давно придумали.

такие ? https://www.youtube.com/watch?v=CjcyHicm3NA

по отзывам они %овно полное - ресурс ни к черту, а стоит это колесо как матиз немного бу

Ну это - первая версия. Первые каменные колёса тоже поди стоили много трудодней
А вот если-б он действительно сферическое колесо изобрёл! Вот это был бы прорыв!

Это продукт 2006 года, и он по прежнему нигде. В этом колесе по кругу стоят десятки колес. Они катятся под углом к своей оси вращения - при этом испытывают трение по касательной.
Там также десятки осей вращения и подшипников, которые при вращении поочередно принимают на себя полный вес нагрузки. Понимаете - тоненькая миниатюрная ось, и на нее падает масса грузовой телеги весом в несколько тонн. И нагрузка идет по касательной !

Вопщем такое колесо никогда не будет грузоподъемным, дешевым, надежным, и с нормальным кпд.


вас эта картинка чтоли так вдохновляет ?
http://www.chopper-bike.ru/view_bikezone.php?id=156


меня, если честно, больше возбуждают летательные средства...

ОК, почти сдаюсь Но качестве последней попытки попробую поменять вводную. Пусть в нашем эксклюзивном распоряжении на RK3399 два ядра A72 на 2 ГГц с выделенным кэшем 1МБ. Про шину (из даташита):
Bus Architecture
===
128bit/64-bit/32-bit multi-layer AXI/AHB/APB composite bus architecture
CCI500 embedded to support two clusters cache coherency
5 embedded AXI interconnect
PERI low performance interconnect with one 128-bits AXI master, seven 64-bits
AXI masters, one 32-bits AXI master, two 64-bits AXI slaves, five 32-bits AHB
masters and lots of 32-bits AHB/APB slaves
PERI high performance interconnect with one 128-bits AXI master, one 128-bits
AXI slave, four 32-bits AHB masters and lots of 32-bits AHB/APB slaves
DISPLAY interconnect with two 128-bits AXI masters, two 64-bits AXI masters,
one 32-bits AXI master and lots of 32-bits AHB/APB slaves
GPU interconnect with one 128-bits AXI master and 32-bits APB slave
VIDEO interconnect with two 128-bits AXI masters, two 64-bits AXI masters
and four 32-bits AHB slaves
Flexible different QoS solution to improve the utility of bus bandwidth
=======

Разрешается использовать внешние микрухи, при условии что они непрограммируемы и имеют российский или китайский аналог. Это не делает миссию выполнимой?
Полный мануал на RK3399: http://opensource.rock-chips.com/images/e/...t1-20170408.pdf

Господин Baritono знает разницу между inrunner и outrunner?

В ПЛИС можно засунуть ещё много полезного, получив в итоге что-то гораздо более подходящее под задачу, чем RK3399 + МК. ПЛИС набирают популярность, они предлагаются уж в облачных сервисах и в комплекте с обычными процами. Опыт работы с ними точно пригодится. ПЛИС-решение можно развивать, а МК может через несколько лет устареть, пропасть, попасть под санкции, и на колу мочало начинай сначала.



Интересно было бы это "легко" разбить на основные составляющие. Допустим, есть отладочная плата от NXP, есть RK3399, есть мотор-колесо от гироскутера. Нужно, чтобы линуксовая софтина с RK3399 могла задать или считать параметры: скорость, момент, потребляемый ток. Какие этапы и ориентировочные трудозатраты предстоят?



А по поводу этого что скажете: https://odriverobotics.com/#features ? Тоже опенсорс, на той же аппаратной базе, но относительно новая разработка.

Ну-ну... Никогда не стоит говорить, что чего-то не может быть никогда, если сейчас это невозможно.
Ещё каких-то 50 лет если бы Вы нарисовали гироскутер, Вам бы сказали, что он не может быть устойчивым и на нём невозможно удержаться обычному человеку. Сейчас же вас он не удивляет?
Сейчас это кажется невозможным, а через некоторое время возникнут новые технологии, материалы, идеи, и станет вполне себе обыденным.


Не эта. Эта хуже чем то, что Вы называете "%овно полное". Никакого полёта мысли нету.
Мыслите шире, менее зашорено
Вот эта например меня вдохновляет: https://itc.ua/articles/poezda-na-magnitnoy...iy-izmenit-mir/
Тогда думаю эта ссылка должна Вас возбудить.


Так засуньте туда ядро CPU + всю используемую периферию из того проекта VESC и все дела. И портировать ничего не придётся.


Может устареть, а может не устареть. Как и ПЛИС - может устареть, а может не устареть. Устареет этот, появится другой. И с начала начинать ничего не надо - каждый кто занимается МК более-менее серьёзное время, за свою жизнь изучил и сменил и прошёл не одно семейство МК - это нормальный процесс, такова наша специальность. Здесь ничего нельзя изучить на всю жизнь, чтоб потом просто сесть сложить ручки и почить на лаврах.
Завтра Ваше решение на ПЛИС точно так же устареет.

Да и причём тут это всё? Вы же вроде хотели решить конкретную задачу? В данных конкретных условиях? Или всё-таки опять - изобретать сферического коня в вакууме?
а реальная задача решается реальными инструментами, наиболее оптимальными в данное время. Оптимальное решение Вам тут уже озвучили. И не раз.

Не похоже на новую разработку.
Парень просто клонировал проект VESC и перенес с ChibiOS на FreeRTOS. Но это ему было не сложно потому как обе используют один и тот же HAL.
Поубирал все экспериментальные фичи и тюнингировал под два мотора.
Тулсов для тюнинга своих не создал. Код как всегда скверно документирован.
Но что-то на питоне с протоколом сварганил. Такой питон под линуксом наверно пойдет.
Может это и есть то что вам нужно.

Кста, там парень и на FPGA сделал. Но внутри то все равно стоит процессорное ядро NIOS и его надо программировать и отлаживать.
Так что в этой теме FPGA не дает никакой пользы, NIOS будет работать медленней нативного микроконтроллера.
Если вы конечно не знаете какого нибудь секретного алгоритма FOC пользующего всю мощь аппаратных фильтров.
Но чет с этим тут никто не светился на моей памяти.

Для прототипа подойдёт VESC, или другой готовый контроллер. На следующем этапе, конечно, такой вариант будет рассматриваться. Возможно, как основной.



Может, Вы и правы, и зря я так опасаюсь микроконтроллеров. Посмотрю подробнее те, что мне тут посоветовали.



Я нахожусь в пути от сферического коня в вакууме к конктретной задаче. Общение в этой ветке дало очень хороший толчок.

Вы так отчаянно пытаетесь сохранить RK3399 (полагаю, в связи с его способностями к видео и, возможно, беспроводными интерфейсами), что решение очевидно: нужно просто соединить VESC и RK3399. Каждый будет спокойно делать свое дело и будет вам щастье.

какой вы однако злой)))



Эта ссылка должна возбудить только того, кто легко направляет в любую сторону по своему желанию бюджет желательно большого государства - например Элона Маска и его фаната Сему.

Вы понимаете, что многотонный поезд висит в воздухе на магнитном поле (это значит под ним зарыто в землю полметра магнитов на ширину полотна), и с какой скоростью он двигается, и какая при этом нагрузка на опоры, и как мала допустимая деформация опоры ? Я где-то читал (думаю китайское же вранье, но в этом явно есть соль), что под своими скоростными поездами китайцы бетонируют полотно на 200 м вглубь.

Для этого Вам надо на линухе развернуть подсистему реального времени по типу https://xenomai.org/ . А уже потом заниматься остальной обработкой. Просьба не надо только писать что это всё херня и тп - лучше сразу писать я так не смогу - ибо не умею, а на кодеров денег не хватит.
Именно на основе этой подсистемы реального времени довольно известная железяка может управлять кучей двигателей и продаётся по всему миру. Никаких пропусков чтений из регистров - тут уж извините вопрос правильно заточенных рук, приложенных к разработке



Ну явно не как опенсорс проект в свободном доступе из интернета. Он будет дороже - но гораздо правильнее и проработаннее, заточенный под задачу. Но это уже не нам решать, а топикстартеру. Он инвестор и ему мыслить куда и как свои деньги вкладывать. Я только дал один из путей развития проекта, более правильный с точки зрения производства законченного продукта.
Разработку прошивки плис с периферией можно сделать за 100-200 тысяч рублей ( Не в Москве, естественно не в Москве - там за еду не работают).


ТОПИКСТАРТЕРУ если Вам нужно только дёшевое на опенсорсное сделать и стартапнуть то можете не читать все что дальше.



Мы его не недооцениваем. Попытаюсь донести ещё раз. У него много фич характерных для контроллеров - да. У него нет фич характерных для приложений УПРАВЛЕНИЯ ЭЛЕКТРО ДВИГАТЕЛЯМИ. У этого камня 4 канала ШИМ - и всё приплыли как Вы к нему 4 мотора то будете приделывать? Как Вам выше написали у него нет синхронных АЦП он не под это заточен.

Но тем не менее Вы на этом чипе можете обсчитать кучу моторов и фоновых задач. Для этого

1. Вам необходимо будет разработать периферию, работающую с моторами в реальном времени (ШИМ, токи, обратная связь, обработка приоритетных входов)
2. Вам необходимо накатить на Ваш линукс RTOS
3. Написать остальное

Выше Вам намекнули, что это удовольствие как бы не из дешёвых, Вы сами программист и ситуацию на рынке труда представлять должны. Хорошие схемотехники тоже на дороге не валяются

Именно по этому Вам и пишут что возьмите специализированные контроллеры от ТI и других производителей. TMS320F28377D позволит Вам одновременно управлять 4-я моторами, поддержка есть, примеры есть, алгоритмы есть, всё есть. Хотите по EMIF соедините его с каким нибудь контроллером. Вами всё равно уже принято решение с нуля делать.

Не хотите так возьмите SoC типа Zynq-7000. Благо их сейчас у Всех как собак нерезаных и корки для мотор контрола и платно и бесплатно дают. Будут у Вас ядра ARM9 ( хотя надо ли оно Вам) и периферию потребную сделаете. И будет у Вас всё на одном камешке.


PS. Я Вам может секрета и не открою - Вы совершаете одну поголовную ошибку стартаперов вышедших из SOFTWARE. И ошибка эта следующая - жизненный цикл проекта SOFTWARE вообще не то же самое что жизненный цикл проекта HARDWARE. Почитайте в чём разница и осмыслите ещё раз. Вас как программиста может уберечь от многих граблей.

Так что фильтруйте кучу потока сознания с форума и слушайте что Вам специалисты из предметной области говорят. После этого пишите ТЗ и проработайте его со специалистами -много сэкономите времени и нервов.

Немного полезного офтопа

На данный момент я наблюдаю бум идей и стартапов из программистской среды. И все поголовно суют туда ардуино, распберри и прочие конструкторы и опенсорс приложения. И почти поголовно стартаперы не понимают сути и специфики реализации железа для вопроса в котором начинают стартап на конструкторах ваять.
Для примера из последних перлов. Заказчик говорит мне нужно с распберри связать по USB атмегу которая АЦП будет опрашивать и данные в распберри передавать. Ну ладно хозяин барин. Начинаем вникать - задача опросить 10 АЦП по SPI и передать в распберри со скоростью чуть ли не раз в секунду. Задаём вопрос - а накой USB то. Ответ - а я по другому не умею и по I2C не смогу с атмегой пообщаться. В результате проект упростили вдвое, кучу изначальных решений выкинули по причине их бредовости и избыточности, написали кусок кода на питоне для работы с мегой и все счастливы. Только Мы кучу времени лишнего убили.



Ну я и понаписал...

ГЫЫЫ... Сами пилим сейчас приложение где 2 мотроа VESC ом управляются. Не самое удобное решение для вписывания его в требования конструктива. И всё те же вопросы с заказчиком которые описал выше.

Нет там никаких открытых алгоритмов.
Иначе не пришлось бы вам с VESC связываться.

Ну не совсем открытых, но информации то много по построению регуляторов.

Я в основном AC моторы смотрю. Но вот бегло http://www.ti.com/lit/an/sprabq7a/sprabq7a.pdf

Или имеется в виду что должен быть кусок кода - который можно воткнуть не думая

Открою секрет почему у нас сейчас VESC - собралась команда стартаперов и сделали прототип на проводах. Моторы естественнго крутились от VESC. А мы сейчас всё это в более менее серийно промышленный вид переводим с сохранением наработок. То есть мы тут не инициаторы - это требование ТЗ. Требований переделать не было. Изначально всё как было, надо моторы крутить - чего делать будем? VESC возьмём чего париться, работает же.

Я не голословно писал про современный путь стартаперов

Вот ещё http://www.tij.co.jp/jp/lit/ug/tiduar7a/tiduar7a.pdf

И даже не копал глубоко то. Сейчас у производителей мода на motor control приложения

...