Портировать контроллер 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) ес-сно сохраняются.

[baritono]

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

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

[a123-flex]

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

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

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

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

[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 задается командами с внешнего интерфейса.
Поэтому чисто на юзере проблемы с быстродействием если они возникнут.