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

Так и я и 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-микрухи брать не очень хочется, т.к. желательна возможность модификации алгоритмов и нежелательна жёсткая завязка на вероятных партнёров. ПЛИС - пожалуй, лучший вариант на перспективу, но для прототипа дороговато, да и ясности по требованиям достаточной нет.

Сообщение отредактировал baritono - Feb 28 2018, 21:22

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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