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

[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

 

[jcxz]

В ПЛИС делаете регистры откуда забирать данные о состоянии мотора и регистры куда записывать задание. А уж какой процессор вы выберете для обсчёта регуляторов это дело вкуса. Ваш на частоте 1ГГц справится с обсчётом кучи моторов.

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

[AlexandrY]

А что будет если линух не отдал вовремя время задаче, считающей и кладущей в эти регистры.

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

[jcxz]

Если говорить в принципе, то линух дал бы случайные задержки не более пары мкс на таком SoC-е как у TC

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