Да нет, это как раз для среднего потребителя motor-control микроконтроллеров. Там примерно такое же количество периферии, как и у тексаса в их TMS320F28335. И она вся «расходится» вполне себе на управление даже одним двигателем. Скажем, если у вас управление каждой фазой организовано полным мостом и есть еще обмотка возбуждения или какой-нибудь DCDC, то вот они и кончились. Или многофазный SRD. Или если у вас трехуровневый инвертор. Т.е. в любой задаче где что-то чуть сложнее, чем просто шестиключевой инвертор, нужно много ШИМов. Два квадратурных энкодера — один на двигатель, другой на рабочий орган после редуктора, это тоже «классика» сервоприводов. Но, конечно, можно уместить кое-как управление двумя простыми синхронными двигателями или несколькими ДПТ, если нужно.
Да, очень интересные подробности — вот что значит комментарий специалиста! Но, возможно, во флеш внедрить «жучка» уже сложнее, чем напрямую в модуль интерфейса связи, например, вида «приняли такую-то посылку — выключаемся». Потом топология флеша — она довольно специфична и однородна, наверное, явно «инородный элемент» будет видно?
Есть и еще один момент. Топологическое проектирование К1921ВК01Т было выполнено в России, Цифровыми решениями, что практически исключает наличие «жучков» в кристалле микроконтроллера, которые заставили бы его выключиться от какого-то внешней команды. И, несмотря на то, что изготовление идет на сторонней фабрике, «внедрить» что-то лишнее в кристалл практически невозможно: во-первых, фабрика даже часто не знает, что именно она делает (для неё это просто слои топологии), «доработка» без «исходных кодов» очень сложна, а во-вторых, всегда можно сравнить, что изготовлено и что было заказано, послойно. Но я это говорю так, с дилетантского подхода, проектировщики микроконтроллеров, наверное, более грамотно это сформулируют. Хотя я как-то видел статью, где описался новый возможный способ «внедрения жучков» прямо на этапе литографии.
Вопрос немного непонятен. При разработке микроконтроллера закупаются его составные части — IP-блоки. Это небольшие законченные и отлаженные аппаратные модули, написанные (чаще всего) на языке VHDL — например, блок CAN или блок UART. Закупается сам блок и лицензия на его использование. Из этих кусочков собирается микроконтроллер. В том числе также закупается и лицензируется ядро ARM. Т.е. это «исходные коды» для железа микроконтроллера. Потом интегратор чипа микроконтроллера собирает всё вместе, стыкует, и получается новый МК. Вот в данном случае блоки ШИМ, CAP, QEP, менеджер АЦП были сделаны самостоятельно, а остальные куплены или уже были сделаны/куплены у НИИЭТ и Цифровых решений ранее. Сами технологии изготовления чипа тут вообще не причем, чипы изготавливаются у всего мира на фабриках в Тайване/Китае, как и в этом случае. Ну это всё так, «на пальцах». Вот тут у Цифровых решений чуть подробнее: www.dsol.ru/projects/plis_n_sbis/motor
Ах, точно-точно. Вы написали подробности, и я сразу вспомнил. У тексаса тоже такой косяк с фифо. Но там получилось сделать у нас костыль — мы при передаче данных из фифо включили себе же их на прием в фифо и поставили прерывание, когда всё примется — тогда же и передача окончена, переключаем RS485 на прием :) Да, может статься, что и здесь тоже самое, надо покурить даташиты и включить попробовать RS485.
Этот камень… не для радиолюбителей, да… Но и у НИИЭТа, и у Миландра есть полно простеньких камней, посмотрите. Правда, конечно, и покупать надо на юр. лицо, и стоить будут «не по ардуиновски».
Даташит тот. Он состоит из описания и приложения. В описании на стр. 124 про прерывания UART сказано, что по передаче есть прерывание как по FIFO (достигло заданного уровня), так и по опустошению. Регистры описаны дальше, в приложении, стр. 24 во второй половине документа. Еще UART имеет связь с DMA, которым его можно пополнять. Про какую проблему у миландровского камня вы говорите я не знаю, я лично UARTом пользовался на НИИЭТе через библиотеку и глубоко в него не погружался. Знаю, что у тексаса была проблема с флагом опустошености буфера при использовании фифо, если опросить флаг опустошенности в момент пересылки данных из фифо в буфер передачи, то там иногда можно прочитать было «буфер пуст», из-за чего надо было три раза подряд опрашивать :) А что здесь вы имеете ввиду не знаю.
Возможно, но не совсем — Цифровые решения делали модуль АЦП с прицелом как раз на DMA, они объясняли, что если сконфигурировать DMA так, а менеджер АЦП — сяк, то можно получить очень эффективный забор данных и раскладку их в оперативку. Но это надо было для каких-то задач цифровой обработки сигналов, а не электропривода, поэтому как именно это работает и для какой задачи надо от меня всё время ускользало :)
Сейчас в мире всё делается из запчастей, микроконтроллеры в том числе — это и написано в статье. Не сказал бы, что там что-то «кривое» — надо прочитать даташит и пользоваться тем, что оно умеет. АЦП такое устанавливается и на другие микроконтроллеры — у всего свои нюансы. Что при изобретении новых блоков опирались на лучшие даташиты существующих МК, да еще и модернизировали — это плюс, а не минус. Представьте, если бы в ШИМ изобрели заново с нуля? А так — привычно и эффективно.
ШИМ высокой точности мы не успели, его тестировали сами Цифровые решения. Сказали что работает, но точность немного плавает от температуры. Мы тоже собираемся попробовать включить его вскоре для серводвигателя, но пока сказать нечего. АЦП мы использовали для начала в наиболее простом режиме — автоусреднение по нескольким точкам и забор результата измерения канала из своего регистра. Запуск от таймера. Это всё работает «как у всех». Забор данных в DMA включали просто для теста, но в живом проекте пока не понадобилось. Управление, действительно, мудреное. НИИЭТ, кажется, до сих пор не сумел это выразить словами в своей документации (мы пользовались доками Цифровых решений). Но в самом простом применении АЦП включается достаточно легко.
Ну половина из них — так, решаема со временем. Самое главное — сколько же «чертей» может быть припрятано в первом… Но если не попробовать, то и не узнать. Может и нет ничего особо? :)
Ну там всё равно развязка самое дорогое. Можно, например, взять ISO1050DUB — это совмещенный драйвер+развязка, 4 доллара. Сам драйвер где-то 2 стоит хороший. Может есть и дешевле, не знаю.
У нас есть порт нашего CANopen драйвера под STM32F4, я думаю, его можно и для f3 собрать, только он… инкапсулирован в RS :) То есть пакеты, которые аппаратно должны были бы идти по CAN, засунуты в RS и добавлена сверху контрольная сумма. Я это делал, когда мне нужно было поиграть с STM32F4 discovery, но играть хотелось со своей оболочкой, а с даташитом CAN разбираться не хотелось. Там всё работает, только медленно. Раз вы так мучаетесь… мы можем вам собрать упрощенную версию оболочки и драйвера, где вы сможете смотреть несколько переменных через массив. А в будущем мы, может быть, портируем наш CANopen для STM полноценно.
Очень дорого так делать. Если у софта цена тестирования — это лишь цена времени программиста, то чтобы в железе сделать юнит-тест «релюхи на 20кА» — нужно сделать целый дорогущий стенд, причем состоящий не просто из релюхи на 20кА, а еще источника на 20кА и того, куда эти 20кА утекут (целая комната силовых шкафов). Делать такой стенд только ради того, чтобы проверить, что у контроллера ножка ставится в единицу, которая эту релюху включает, конечно, никто не будет. Если вы, конечно, не производитель этой релюхи, а не её пользователь как готового продукта. Более того, сами такие объекты, где надо коммутировать 20кА, это единичные объекты, а скорее даже это может оказаться один специализированный софт для одного единственного объекта с этой релюхой. И делать по кусочкам еще один такой же объект только для юнит-тестов — учетверенная цена объекта. Но такие «юнит-тесты» на самом деле делают, но называется это пусконаладкой устройства/объекта. Никто не приходит на только собранную электрическую вундервафлю на 20кА и не нажимает кнопку «поехали», где она сразу включается в номинальный режим. Сначала собираются аппаратчики и программисты на заводе-производителе, где начинают постепенную наладку устройства, включая узлы по кусочкам и проверяя, что на выходе то что надо. Потом включают это нечто на холостом ходе, небольшом токе, всё измеряют, осциллографируют, правят косяки. Потом дают небольшую мощность, тестовый прогон, проверяют все защиты, имитируя те или иные отказы. Если есть сомнение в каком-то узле, могут уже на оборудовании поставить какой-то эксперимент, приняв нужные меры предосторожности. Потом номинал, прогон на тепло с записью всей телеметрии, потом разборка на куски и отправка заказчику, там монтаж, первое включение там, продолжение правки косяков (которые вдруг повылезали еще), прогон 72 часа, сдача объекта… потом начало тестовой эксплуатации, где всё еще продолжают вылезать иногда косяки, которые приезжают и правят… И так постепенно оборудование входит в строй.
Поэтому — нет, для 20кА юнит-тестов не делают, или делают, только если сомневаются в каком-то физическом явлении, но это не тест уже, а скорее исследовательская работа, и делается она только если ни на модели, ни на объекте это проверить никак нельзя. Все юнит-тесты софта в основном делаются софтом же, либо совсем простым оборудованием типа еще одного контроллера-имитатора, тумблеров, лампочек и т.п.
Но, как я уже сказал, реальное устройство имитатором полноценно не описать, а поэтому особо интеллектуальные куски кода, увы, приходится рожать во время пусконаладки. И даже если это делается всё на заводе-изготовителе, то всё равно для программиста — это уже не отладка «на столе», это настоящие шкафы в пыльном цеху, где и сесть особо негде, и удлиннителей для зарядки ноутбука вечно нет, и провода силовые везде висят, и шум, и брызги то масла, то тосола летят, и интернет еле ловит (хорошо если из репозитория запуллить что-то получится или спросить консультации в чате у коллег) — никакой комфортной отладки. А ещё обязательно рядом будет стоять заказчик, который будет смотреть через плечо в ноутбук и спрашивать: «Почему не работает? Мы должны были поставить оборудование еще на той неделе! Вы же говорили, что программа написана, почему не включаете? Как это ток пульсирует, зачем он так делает?»…
Поэтому нужно заранее иметь все инструменты, которыми можно быстро и эффективно понять, в чем может быть проблема и оперативно исправить её. Как программист, я бы с удовольствием согласился бы на юнит-тесты железа, но реалии обычно таковы что «Мы заказали силовые ключи и трансформатор, поставка долгая, вы пока пишите спокойно программу, а они придут через шесть месяцев на завод, там их смонтируют в силовые шкафы за две недели, потом вы поедете настроите все (недели вам хватит?), а на к концу седьмого месяца оборудование должно быть у заказчика». Вот и все юнит-тесты на этом…
Да, спасибо, действительно, получилось запустить — изначально не нашел этой опции потому что функцию рисования «аналоговых» графиков в Keil спрятали в логический анализатор. Для работы пришлось задействовать по мануалу Trace режим, указать все галочки, после чего график нарисовался. Однако он не очень обрадовал — работает режим отрисовки текущего значения переменной (причем не очень быстро), а вот режима отображения данных из массива в виде графика опять же нету (а это самое главное!). Так что Code Composer Studio в этом плане впереди. Кроме того, почему-то в Keil отрисовка графиков работала довольно капризно, через раз — надо было то перезапускать сеанс отладки, то передергивать питание платы — иначе ничего не рисовалось. Проверял на stm32f4discovery по SWD интерфейсу.
Эмуляторы оборудования, они же «макеты», конечно же делаются и применяются в ряде случаев. Когда нужно провести какое-то научное исследование в лабораторных условиях. Железкой, выдающей результаты «теста», может являться меньший по мощности электродвигатель. Но иногда можно и сделать программируемый имитатор, который в себе крутит модель объекта управления и взаимодействует с отлаживаемой системой управления. Более того, иногда сама модель объекта управления встраивается непосредственно в софт системы управления. Например, можно встроить модель электродвигателя с систему управления преобразователя частоты — у меня в одном из проектов так сделано. Однако всё это не сильно лучше модели в матлабе — объект можно промоделировать лишь настолько, насколько вы можете математически его описать. И как бы вы не отладили всё это на модели, на макете или на эмуляторе — на объекте окажется всё по-другому. И всё равно придется смотреть переходные процессы, перенастраивать десятки параметров, дописывать фильтры, добавлять новые неожиданные защиты и т.п. Поэтому на объекте желательно иметь доступными те же самые средства отладки, которые использовались «в лабораторных условиях» — иначе поиск проблем на объекте может затянуться на неопределенное время, а бесконечные командировки могут «съесть» весь бюджет проекта.
Я не специалист в ядрах ПЛИС, но, думаю, что если сравнивать готовый 32х разрядный микроконтроллер и аналогичное по функциональности и скорости работы ядро, собранное на ПЛИС, то ПЛИС выйдет точно дороже микроконтроллера. Кроме того, какое бесплатное 32х разрядное DSP ядро можно предложить для синтеза, чтобы на нем можно было решать сложные вычислительные задачи электропривода? Какие компиляторы Си-кода на него использовать? Достаточно ли они функциональны, хорошо ли работает оптимизатор? Если для «меги» это еще можно представить, то электропривод — это совсем другой класс задач… Нужно максимально использовать готовые решения, собирать микроконтроллер из кусочков — это задача для производителей микроконтроллеров, или разработчиков с очень специфическими задачами, где стандартные микроконтроллеры не подходят. Для электропривода всё уже есть.
«Ширпотреб» как раз давно уже есть. Не хватало монстра.
Поэтому — нет, для 20кА юнит-тестов не делают, или делают, только если сомневаются в каком-то физическом явлении, но это не тест уже, а скорее исследовательская работа, и делается она только если ни на модели, ни на объекте это проверить никак нельзя. Все юнит-тесты софта в основном делаются софтом же, либо совсем простым оборудованием типа еще одного контроллера-имитатора, тумблеров, лампочек и т.п.
Но, как я уже сказал, реальное устройство имитатором полноценно не описать, а поэтому особо интеллектуальные куски кода, увы, приходится рожать во время пусконаладки. И даже если это делается всё на заводе-изготовителе, то всё равно для программиста — это уже не отладка «на столе», это настоящие шкафы в пыльном цеху, где и сесть особо негде, и удлиннителей для зарядки ноутбука вечно нет, и провода силовые везде висят, и шум, и брызги то масла, то тосола летят, и интернет еле ловит (хорошо если из репозитория запуллить что-то получится или спросить консультации в чате у коллег) — никакой комфортной отладки. А ещё обязательно рядом будет стоять заказчик, который будет смотреть через плечо в ноутбук и спрашивать: «Почему не работает? Мы должны были поставить оборудование еще на той неделе! Вы же говорили, что программа написана, почему не включаете? Как это ток пульсирует, зачем он так делает?»…
Поэтому нужно заранее иметь все инструменты, которыми можно быстро и эффективно понять, в чем может быть проблема и оперативно исправить её. Как программист, я бы с удовольствием согласился бы на юнит-тесты железа, но реалии обычно таковы что «Мы заказали силовые ключи и трансформатор, поставка долгая, вы пока пишите спокойно программу, а они придут через шесть месяцев на завод, там их смонтируют в силовые шкафы за две недели, потом вы поедете настроите все (недели вам хватит?), а на к концу седьмого месяца оборудование должно быть у заказчика». Вот и все юнит-тесты на этом…