Портировать контроллер BLDC с STM32 на Rockchip 3399?, Легко ли избавиться от STM, когда есть ARM SOC? Опции

[baritono]

Есть 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) ес-сно сохраняются.

[aaarrr]

Есть ли шанс малой кровью...

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

[AlexandrY]

... Двигателей будет от 2 до 6. Вроде мощи у RK3399 достаточно, интерфейсов тоже. Внешние чипы (DRV8302) ес-сно сохраняются.

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

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

[gosha-z]

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

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

[Vasily_]

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

[baritono]

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

Сообщение отредактировал baritono - Feb 27 2018, 18:09

[jcxz]

Но RK3399 настолько мощнее и многоядернее STM32, что проблем быть не должно.

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

[baritono]

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

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

[jcxz]

Даже на ядре 1ГГц ногодрыгом GPIO не сделать нужный ШИМ?

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

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

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

[aaarrr]

Даже на ядре 1ГГц ногодрыгом GPIO не сделать нужный ШИМ?

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

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

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

[a123-flex]

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

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

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

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

[AlexandrY]

Судя по всему главное в этом проекте - это понимание теории

Так проект же экспериментальный, там нет никаких железно отлаженных алгоритмов.
Например обсервер скорости вращения ротора мужик взял из сомнительного исследования - 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.
Автор постарался это сделать тщательно избегая комментирования своих сорсов. Ну это наверняка ему самому аукнется.

[jcxz]

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

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

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

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

Обычные НЧ фильтры имеют длину в 128 коэффициентов! Причем профайлинга нигде не видно. Пробовл ли он вообще это юзать?

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

[AlexandrY]

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

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

[Flik]

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

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

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

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

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

Прикрепленные файлы

 Designing_a_Direct_PWM_Interface_2014_1.pdf ( 405.38 килобайт ) Кол-во скачиваний: 31