Comments 50
Мне интуиция говорит, что нужно писать эмуляторы оборудования. Те же моки, но в железе.
«А вот эти три вольта на 1мА изображают 10кВ с током в 500А и мы его типа-коммутируем». А рядом железка, которая выдаёт результаты теста.
Насчёт «без ОС» — в моём представлении (опять же, наивном) — программа должна писаться на каком-то высокоуровневом DSL'е, который транслируется потом в монолитный блобик машинного кода, намертво интегрированный с библиотекой (изображающей из себя ядро и libc в одной ипостаси). И именно на уровне обработки DSL'я должны проверяться все граничные условия и корректность обработки событий (на математическом уровне проверки — как выведение типов в хорошо типизированных языках).
«А вот эти три вольта на 1мА изображают 10кВ с током в 500А и мы его типа-коммутируем». А рядом железка, которая выдаёт результаты теста.
Насчёт «без ОС» — в моём представлении (опять же, наивном) — программа должна писаться на каком-то высокоуровневом DSL'е, который транслируется потом в монолитный блобик машинного кода, намертво интегрированный с библиотекой (изображающей из себя ядро и libc в одной ипостаси). И именно на уровне обработки DSL'я должны проверяться все граничные условия и корректность обработки событий (на математическом уровне проверки — как выведение типов в хорошо типизированных языках).
Эмуляторы оборудования, они же «макеты», конечно же делаются и применяются в ряде случаев. Когда нужно провести какое-то научное исследование в лабораторных условиях. Железкой, выдающей результаты «теста», может являться меньший по мощности электродвигатель. Но иногда можно и сделать программируемый имитатор, который в себе крутит модель объекта управления и взаимодействует с отлаживаемой системой управления. Более того, иногда сама модель объекта управления встраивается непосредственно в софт системы управления. Например, можно встроить модель электродвигателя с систему управления преобразователя частоты — у меня в одном из проектов так сделано. Однако всё это не сильно лучше модели в матлабе — объект можно промоделировать лишь настолько, насколько вы можете математически его описать. И как бы вы не отладили всё это на модели, на макете или на эмуляторе — на объекте окажется всё по-другому. И всё равно придется смотреть переходные процессы, перенастраивать десятки параметров, дописывать фильтры, добавлять новые неожиданные защиты и т.п. Поэтому на объекте желательно иметь доступными те же самые средства отладки, которые использовались «в лабораторных условиях» — иначе поиск проблем на объекте может затянуться на неопределенное время, а бесконечные командировки могут «съесть» весь бюджет проекта.
А юнит-тесты не используются?
Мол, у нас есть релюха, которая 20кА коммутирует. У нас естьустройство, которое отлажено на коммутации микроамперными токами. Теперь мы берём и собираем стенд, где эта штука коммутирует 20кА. Не реальный мотор, а просто 20кА.
Я понимаю, что железо делать — не мегабайты кода писать, но те же принципы тестирования, что отработаны в софте, возможно, могут быть применены и в железе, не?
Мол, у нас есть релюха, которая 20кА коммутирует. У нас есть
Я понимаю, что железо делать — не мегабайты кода писать, но те же принципы тестирования, что отработаны в софте, возможно, могут быть применены и в железе, не?
Очень дорого так делать. Если у софта цена тестирования — это лишь цена времени программиста, то чтобы в железе сделать юнит-тест «релюхи на 20кА» — нужно сделать целый дорогущий стенд, причем состоящий не просто из релюхи на 20кА, а еще источника на 20кА и того, куда эти 20кА утекут (целая комната силовых шкафов). Делать такой стенд только ради того, чтобы проверить, что у контроллера ножка ставится в единицу, которая эту релюху включает, конечно, никто не будет. Если вы, конечно, не производитель этой релюхи, а не её пользователь как готового продукта. Более того, сами такие объекты, где надо коммутировать 20кА, это единичные объекты, а скорее даже это может оказаться один специализированный софт для одного единственного объекта с этой релюхой. И делать по кусочкам еще один такой же объект только для юнит-тестов — учетверенная цена объекта. Но такие «юнит-тесты» на самом деле делают, но называется это пусконаладкой устройства/объекта. Никто не приходит на только собранную электрическую вундервафлю на 20кА и не нажимает кнопку «поехали», где она сразу включается в номинальный режим. Сначала собираются аппаратчики и программисты на заводе-производителе, где начинают постепенную наладку устройства, включая узлы по кусочкам и проверяя, что на выходе то что надо. Потом включают это нечто на холостом ходе, небольшом токе, всё измеряют, осциллографируют, правят косяки. Потом дают небольшую мощность, тестовый прогон, проверяют все защиты, имитируя те или иные отказы. Если есть сомнение в каком-то узле, могут уже на оборудовании поставить какой-то эксперимент, приняв нужные меры предосторожности. Потом номинал, прогон на тепло с записью всей телеметрии, потом разборка на куски и отправка заказчику, там монтаж, первое включение там, продолжение правки косяков (которые вдруг повылезали еще), прогон 72 часа, сдача объекта… потом начало тестовой эксплуатации, где всё еще продолжают вылезать иногда косяки, которые приезжают и правят… И так постепенно оборудование входит в строй.
Поэтому — нет, для 20кА юнит-тестов не делают, или делают, только если сомневаются в каком-то физическом явлении, но это не тест уже, а скорее исследовательская работа, и делается она только если ни на модели, ни на объекте это проверить никак нельзя. Все юнит-тесты софта в основном делаются софтом же, либо совсем простым оборудованием типа еще одного контроллера-имитатора, тумблеров, лампочек и т.п.
Но, как я уже сказал, реальное устройство имитатором полноценно не описать, а поэтому особо интеллектуальные куски кода, увы, приходится рожать во время пусконаладки. И даже если это делается всё на заводе-изготовителе, то всё равно для программиста — это уже не отладка «на столе», это настоящие шкафы в пыльном цеху, где и сесть особо негде, и удлиннителей для зарядки ноутбука вечно нет, и провода силовые везде висят, и шум, и брызги то масла, то тосола летят, и интернет еле ловит (хорошо если из репозитория запуллить что-то получится или спросить консультации в чате у коллег) — никакой комфортной отладки. А ещё обязательно рядом будет стоять заказчик, который будет смотреть через плечо в ноутбук и спрашивать: «Почему не работает? Мы должны были поставить оборудование еще на той неделе! Вы же говорили, что программа написана, почему не включаете? Как это ток пульсирует, зачем он так делает?»…
Поэтому нужно заранее иметь все инструменты, которыми можно быстро и эффективно понять, в чем может быть проблема и оперативно исправить её. Как программист, я бы с удовольствием согласился бы на юнит-тесты железа, но реалии обычно таковы что «Мы заказали силовые ключи и трансформатор, поставка долгая, вы пока пишите спокойно программу, а они придут через шесть месяцев на завод, там их смонтируют в силовые шкафы за две недели, потом вы поедете настроите все (недели вам хватит?), а на к концу седьмого месяца оборудование должно быть у заказчика». Вот и все юнит-тесты на этом…
Поэтому — нет, для 20кА юнит-тестов не делают, или делают, только если сомневаются в каком-то физическом явлении, но это не тест уже, а скорее исследовательская работа, и делается она только если ни на модели, ни на объекте это проверить никак нельзя. Все юнит-тесты софта в основном делаются софтом же, либо совсем простым оборудованием типа еще одного контроллера-имитатора, тумблеров, лампочек и т.п.
Но, как я уже сказал, реальное устройство имитатором полноценно не описать, а поэтому особо интеллектуальные куски кода, увы, приходится рожать во время пусконаладки. И даже если это делается всё на заводе-изготовителе, то всё равно для программиста — это уже не отладка «на столе», это настоящие шкафы в пыльном цеху, где и сесть особо негде, и удлиннителей для зарядки ноутбука вечно нет, и провода силовые везде висят, и шум, и брызги то масла, то тосола летят, и интернет еле ловит (хорошо если из репозитория запуллить что-то получится или спросить консультации в чате у коллег) — никакой комфортной отладки. А ещё обязательно рядом будет стоять заказчик, который будет смотреть через плечо в ноутбук и спрашивать: «Почему не работает? Мы должны были поставить оборудование еще на той неделе! Вы же говорили, что программа написана, почему не включаете? Как это ток пульсирует, зачем он так делает?»…
Поэтому нужно заранее иметь все инструменты, которыми можно быстро и эффективно понять, в чем может быть проблема и оперативно исправить её. Как программист, я бы с удовольствием согласился бы на юнит-тесты железа, но реалии обычно таковы что «Мы заказали силовые ключи и трансформатор, поставка долгая, вы пока пишите спокойно программу, а они придут через шесть месяцев на завод, там их смонтируют в силовые шкафы за две недели, потом вы поедете настроите все (недели вам хватит?), а на к концу седьмого месяца оборудование должно быть у заказчика». Вот и все юнит-тесты на этом…
Так есть же ITM и ETM у армов – оно делает все тоже самое и бесплатно.
Ну это так шутка…
Ну это так шутка…
добавлю к автору что работа с подобными штуками очень сильно меняет стиль программирования и даёт возможность на си писать более компактные и быстрые в циклах программы чем это делают мастера ассемблера при подготовке своей статьи (но не комментариев), когда мигалка светодиодом с задержкой реализуется в один сдвиг и одну сумму (см цикл while (true)).
например тут:
http://habrahabr.ru/post/274901/#comment_8738493
Да и вообще привыкаешь думать критериями фазы, вращения, частотами и условиями устойчивости
у меня например есть своя библиотека с «чёрной магией», например:
1. нонстоп обмен потоками данных при помощи дма без прерываний в реалтайме (помним, нам надо избегать прерываний вообще, т.к. реалтайм)
2. всякие быстрые синусы и тригонометрия по таблицам (кстати именно таблицы и жрут часто очень много флеша)
3. быстрые и ОЧЕНЬ быстрые (быстрее аналогов boost-а) lockfree очереди состоящие из просто вычисления адреса указателя и размера кол-ва данных в указателе
4.и просто стопятьсот мелочей например как очень шустро вычислить квадратный корень там где его нет аппаратно, пусть даже немного неточно, или точно вычислить квадратурный детектор
это я со звуком работаю если что а не с приводами
да даже там есть очень сложные штуки типа эхо-подавления когда надо найти глобальный минимум в 256 мерном пространстве в реалтайме да ещё чтоб системма в целом самовозбуждалась
например тут:
http://habrahabr.ru/post/274901/#comment_8738493
Да и вообще привыкаешь думать критериями фазы, вращения, частотами и условиями устойчивости
у меня например есть своя библиотека с «чёрной магией», например:
1. нонстоп обмен потоками данных при помощи дма без прерываний в реалтайме (помним, нам надо избегать прерываний вообще, т.к. реалтайм)
2. всякие быстрые синусы и тригонометрия по таблицам (кстати именно таблицы и жрут часто очень много флеша)
3. быстрые и ОЧЕНЬ быстрые (быстрее аналогов boost-а) lockfree очереди состоящие из просто вычисления адреса указателя и размера кол-ва данных в указателе
4.и просто стопятьсот мелочей например как очень шустро вычислить квадратный корень там где его нет аппаратно, пусть даже немного неточно, или точно вычислить квадратурный детектор
это я со звуком работаю если что а не с приводами
да даже там есть очень сложные штуки типа эхо-подавления когда надо найти глобальный минимум в 256 мерном пространстве в реалтайме да ещё чтоб системма в целом самовозбуждалась
Все слишком категорично.
Я разрабатываю частотники и прочую силовую электронику вполне нарушая все эти выше перечисленные принципы.
Вот здесь один приведен для примера — habrahabr.ru/post/256611
Cделан строго с применением RTOS. Без RTOS я вообще силовую электронику не делаю.
Отлаживаю по JTAG. Гальвано-изолированный JTAG стоит копейки.
Пользуюсь точками останова вовсю и во время работы силовых цепей. А ARM-ах на точках останова не обязательно останавливается вся периферия. ШИМ-ы могут оставаться работать, это как зададите.
Гораздо удобнее чем JTAG это SWD интерфейс.
Графики в реальном времени могут строить и Keil и IAR. Даже у Segger-а производителя отладчиков J-Link есть построитель графиков с передачей по отладочному каналу.
Вместо CAN применяю RS232, по нему передаю информацию в PC со скоростью 1.25 Мбит, это гораздо быстрее CAN-а.
А не менее мощный аналог UniCON это FreeMaster от NXP. Имеет открытый протокол и все сорсы.
Я разрабатываю частотники и прочую силовую электронику вполне нарушая все эти выше перечисленные принципы.
Вот здесь один приведен для примера — habrahabr.ru/post/256611
Cделан строго с применением RTOS. Без RTOS я вообще силовую электронику не делаю.
Отлаживаю по JTAG. Гальвано-изолированный JTAG стоит копейки.
Пользуюсь точками останова вовсю и во время работы силовых цепей. А ARM-ах на точках останова не обязательно останавливается вся периферия. ШИМ-ы могут оставаться работать, это как зададите.
Гораздо удобнее чем JTAG это SWD интерфейс.
Графики в реальном времени могут строить и Keil и IAR. Даже у Segger-а производителя отладчиков J-Link есть построитель графиков с передачей по отладочному каналу.
Вместо CAN применяю RS232, по нему передаю информацию в PC со скоростью 1.25 Мбит, это гораздо быстрее CAN-а.
А не менее мощный аналог UniCON это FreeMaster от NXP. Имеет открытый протокол и все сорсы.
Было бы интересно, если бы Вы рассказали о вашем опыте разработки с практической стороны на ARM. Про точки останова во время работы силовых цепей, где их можно ставить, где нет, как сконфигурировать периферию, чтобы это было безопасно — ШИМы-то работать будут, а вот будет ли обновляться вектор напряжения? Как не промахнуться с точкой останова?
Какой дешевый JTAG с изоляцией посоветуете, который не сбоит при ШИМящих киловольтах по соседству?
Где в Keil и IAR можно посмотреть осциллограмму синуса тока фазы, как это организовать? Это очень интересно, так как я, как пользователь Code Composer Studio от тексас, банально не нашел этих опций в Keil и IAR.
Грамотно использовать RTOS — согласен, можно. Небольшой платой за «оверхед» можно получить очень много полезных вещей. На мощных микроконтролерах это уместно, особенно если вы эту RTOS освоили и знаете все её подводные камни. Но, зависит, конечно, от МК — например, у меня проект в стиле «Bare metal» под DSP микроконтроллер TI TMS320F2810 занял буквально всю флеш-память — RTOS туда просто некуда вставить. Это нужно МК с в два раза большей памятью брать. В общем, соглашусь, что RTOS — дело привычки.
За FreeMaster — спасибо, обязательно посмотрим на его возможности. По описанию действительно похож на нашу разработку.
Какой дешевый JTAG с изоляцией посоветуете, который не сбоит при ШИМящих киловольтах по соседству?
Где в Keil и IAR можно посмотреть осциллограмму синуса тока фазы, как это организовать? Это очень интересно, так как я, как пользователь Code Composer Studio от тексас, банально не нашел этих опций в Keil и IAR.
Грамотно использовать RTOS — согласен, можно. Небольшой платой за «оверхед» можно получить очень много полезных вещей. На мощных микроконтролерах это уместно, особенно если вы эту RTOS освоили и знаете все её подводные камни. Но, зависит, конечно, от МК — например, у меня проект в стиле «Bare metal» под DSP микроконтроллер TI TMS320F2810 занял буквально всю флеш-память — RTOS туда просто некуда вставить. Это нужно МК с в два раза большей памятью брать. В общем, соглашусь, что RTOS — дело привычки.
За FreeMaster — спасибо, обязательно посмотрим на его возможности. По описанию действительно похож на нашу разработку.
В Keil это тут: www.keil.com/support/man/docs/uv4/uv4_db_dbg_logicanalyzer.htm
Да, спасибо, действительно, получилось запустить — изначально не нашел этой опции потому что функцию рисования «аналоговых» графиков в Keil спрятали в логический анализатор. Для работы пришлось задействовать по мануалу Trace режим, указать все галочки, после чего график нарисовался. Однако он не очень обрадовал — работает режим отрисовки текущего значения переменной (причем не очень быстро), а вот режима отображения данных из массива в виде графика опять же нету (а это самое главное!). Так что Code Composer Studio в этом плане впереди. Кроме того, почему-то в Keil отрисовка графиков работала довольно капризно, через раз — надо было то перезапускать сеанс отладки, то передергивать питание платы — иначе ничего не рисовалось. Проверял на stm32f4discovery по SWD интерфейсу.
Чтобы отобразить массив, я объявлял еще одну переменную и в цикле присваивал ей элементы массива. И уже саму переменную выводил в анализатор. Про не очень быстро — непонятно, т.к. у меня все работает в реалтайме. STMF4.
даже среда для плис — квартус умеет и снимать и рисовать аналоговые графики, например есть где либо внутри или на ножках плис, например знаковое 16 битное с ацп или внутренне расчитанная синусойда — в SignalTap можно подключиться и снимать график в реалтайме не разрушая этот реалтайм. Максимум что будет если кристалл заполнен на более чем 70% то сильно съедут тайминги на сотни пикосекунд.
Более того в сигнал тапе можно делать на порядки больше всего. тактироваться с разных источников, сложное тактирование а апериодическое, условия и целые скрипты написать по поиску нужного тебе события.
В отличии от микроконтроллеров сигналтап в плис вообще почти не вмешивается в алгоритм и строго гарантирует и реалтайм и любое количество каналов, их разрядность и вообще что угодно — лишь бы оставшихся ресурсов плис хватило.
Я на плис делаю многие вещи связанные с переферией в десятки раз быстрее чем на старших микроконтроллерах. Т.к. ты делаешь только то что тебе нужно а не изучаешь мегамонстра под все случаи жизни, и пытаешся его запустить и абуздать шатл.
Более того в сигнал тапе можно делать на порядки больше всего. тактироваться с разных источников, сложное тактирование а апериодическое, условия и целые скрипты написать по поиску нужного тебе события.
В отличии от микроконтроллеров сигналтап в плис вообще почти не вмешивается в алгоритм и строго гарантирует и реалтайм и любое количество каналов, их разрядность и вообще что угодно — лишь бы оставшихся ресурсов плис хватило.
Я на плис делаю многие вещи связанные с переферией в десятки раз быстрее чем на старших микроконтроллерах. Т.к. ты делаешь только то что тебе нужно а не изучаешь мегамонстра под все случаи жизни, и пытаешся его запустить и абуздать шатл.
Да, осциллограммы в реальном времени — круто! Только правда через CAN уже не совсем в реальном, но плюсы перевешивают, согласен :) MDK/ARM так тоже умеет, только через дебаггер. При этом разрешение именно что реал-тайм. Т.е. я на МК с 168 МГц в цикле присваиваю одной глобальной переменной значения масива и на экране логического анализатора вижу график этого массива. И такой красоты сохраняется последних несколько секунд. Работе контроллера не мешает.
Еще одна полезная штука, тоже однажды делал себе с нуля — сохранять таймстемпы для заданных пользователем событий. Позволяет красиво визуализировать последовательность событий. Например, в начало-конец каждого превырвания добавить по пользовательскому событий — и вуаля, можно увидеть, как часто прерывания происходят, в каком порядке и сколько каждое из них длится. Доп. нагрузка на контроллер, правда, в этом случае есть, но небольшая — таймстемпы берутся из аппаратного таймера, пишется все в циклический буфер…
Еще одна полезная штука, тоже однажды делал себе с нуля — сохранять таймстемпы для заданных пользователем событий. Позволяет красиво визуализировать последовательность событий. Например, в начало-конец каждого превырвания добавить по пользовательскому событий — и вуаля, можно увидеть, как часто прерывания происходят, в каком порядке и сколько каждое из них длится. Доп. нагрузка на контроллер, правда, в этом случае есть, но небольшая — таймстемпы берутся из аппаратного таймера, пишется все в циклический буфер…
Захватывать вообще все данные работы системы управления с огромной частотой обновления обычно не требуется. Для «реального времени» хватает вяло обновляющихся данных о текущем состоянии «телеметрии» — частоте вращения, мощности, температуре и т.п. А когда происходит сбой, вот тогда и нужна осциллограмма его процесса с хорошим разрешением по времени. Кроме микроконтроллера её записать всё равно никто не успеет. А раз она записана внутри, передавать «наверх» данные можно уже тоже не торопясь. Поэтому в таком стиле работы вообще быстрого интерфейса связи не требуется как такового. Хоть это CAN, хоть RS 9600 кБит/с — не важно.
Касательно последовательности событий — можно записывать время, как вы говорите, а можно, имея «осциллограф» в самом быстром прерывании, просто осциллографировать счетчики других прерываний или флаги нахождения внутри прерывания. Тогда можно точно также увидеть, где что вызывалось. Но это уже нюансы реализации — просто для вашего способа нужно писать отдельную утилиту для выкачивания и визуализации этих данных, а если есть осциллограф внутри, то нужно лишь добавить на каждое событие счетчик и смотреть его.
Касательно последовательности событий — можно записывать время, как вы говорите, а можно, имея «осциллограф» в самом быстром прерывании, просто осциллографировать счетчики других прерываний или флаги нахождения внутри прерывания. Тогда можно точно также увидеть, где что вызывалось. Но это уже нюансы реализации — просто для вашего способа нужно писать отдельную утилиту для выкачивания и визуализации этих данных, а если есть осциллограф внутри, то нужно лишь добавить на каждое событие счетчик и смотреть его.
Наезд на RTOS не совсем понятен. RTOS совсем не мешает прерываниям, и не надо их заменять на переключение задач, это разные штуки. А многие рутинные вещи RTOS очень даже упрощает, позволяя написать простой код вместо сложной машины состояний…
Ну, мешает или нет — это зависит от конкретной RTOS. Если мне не изменяет память, то порт uC/OS для stm32, например, все обработчики прерывания пропускал через свой программный «контроллер прерываний».
То есть, вместо специализированного обработчика сначала вызывался один общий обработчик от ОС, который программно проверял источник прерывания и вызывал нужный обработчик из массива указателей.
Зачем это делалось я сходу не скажу.
Но в той же freeRTOS такой проблемы нет.
То есть, вместо специализированного обработчика сначала вызывался один общий обработчик от ОС, который программно проверял источник прерывания и вызывал нужный обработчик из массива указателей.
Зачем это делалось я сходу не скажу.
Но в той же freeRTOS такой проблемы нет.
а как в моторном деле обстоят дела с ПЛИС?
Применяется или нет?
На плис же гораздо быстрее и гибче можно сделать свою переферию с нужыми таймерами, мёртвыми интервалами и запусками ацп когда надо да и всю рутинную работу по усереднению и управлению тоже можно свалить на ПЛИС. В добавок плис может работать с очень малым шагом управления и переваривать в реалтайме очень жирный поток от АЦП — сотни миллионов выборок в секунду запросто даже начального уровня типа МАКС 2… МАКС5. Я на плис например спокойно и без оптимизаций делал обработку потока видеоданных для FullHD видеопотока.
У той же Альтеры есть немало демо и отладочных плат на FPGA.
Применяется или нет?
На плис же гораздо быстрее и гибче можно сделать свою переферию с нужыми таймерами, мёртвыми интервалами и запусками ацп когда надо да и всю рутинную работу по усереднению и управлению тоже можно свалить на ПЛИС. В добавок плис может работать с очень малым шагом управления и переваривать в реалтайме очень жирный поток от АЦП — сотни миллионов выборок в секунду запросто даже начального уровня типа МАКС 2… МАКС5. Я на плис например спокойно и без оптимизаций делал обработку потока видеоданных для FullHD видеопотока.
У той же Альтеры есть немало демо и отладочных плат на FPGA.
Всё дело в цене. ПЛИС с ARM ядром, на которой можно будет синтезировать все необходимые периферийные устройства априори будет дороже, чем готовый микроконтроллер с таким же набором периферии. Обычно микроконтроллеры для задач электропривода уже оптимальны — не возникает острого желания что-то переделать аппаратно. Рутинной же работы по управлению нет — это различные гибкие структуры управления двигателем, с фильтрами, тригонометрией, таблицами, причем все уставки должны настраиваться и т.п. — такие задачи гораздо приятнее решаются программным путем на Си. Однако для ПЛИС место в приводе находится — иногда на ней удобно сделать быстродействующий контур тока, на ней можно сделать драйвера силовых ключей с самодиагностикой и т.п. И да, некоторые разработчики на ней даже делают полностью систему управления. Но в большинстве случаев хватает специализированного микроконтроллера, где вся периферия уже изобретена — это и время разработки сокращает (не нужно проектировать своё тоже самое), и цену.
А вариант использования дешевой ПЛИС + синтезируемого ядра микроконтроллера (не обязательно платных *blaze/nios/ppc/arm (раз уж стоит вопрос цены), можно что-нить подобрать на opencores)? Знакомый разработчик лет десять назад для работы написал аналог меги и был им доволен (причём аналог не только в плане ядра, а ещё и обвязки в виде всяких таймеров, uart-ов и прочего её фарша) настолько, что перевёл разработки целиком на ПЛИС.
Я не специалист в ядрах ПЛИС, но, думаю, что если сравнивать готовый 32х разрядный микроконтроллер и аналогичное по функциональности и скорости работы ядро, собранное на ПЛИС, то ПЛИС выйдет точно дороже микроконтроллера. Кроме того, какое бесплатное 32х разрядное DSP ядро можно предложить для синтеза, чтобы на нем можно было решать сложные вычислительные задачи электропривода? Какие компиляторы Си-кода на него использовать? Достаточно ли они функциональны, хорошо ли работает оптимизатор? Если для «меги» это еще можно представить, то электропривод — это совсем другой класс задач… Нужно максимально использовать готовые решения, собирать микроконтроллер из кусочков — это задача для производителей микроконтроллеров, или разработчиков с очень специфическими задачами, где стандартные микроконтроллеры не подходят. Для электропривода всё уже есть.
Объясните почему CAN лучше RS-485? Я вот никак не пойму. RS-485 имеет 2х тактный выход, а CAN однотактный(тянет только вниз)…
Как раз за счет этого и лучше. За счет так называемых рецессивных и доминантных состояний на линии. Если в RS-485 два устройства начнут передавать одновременно, возникнет коллизия — битые данные. В кэне передающие узлы контролируют линию. Если узел выставил рецессивный 1, а прочитал доминантный 0, то значит кто-то другой на линии передает свои более приоритетные данные. Этот узел «затыкается», данные продолжает посылать более успешный узел, посылка доходит до всех в сети в сохранности. А заткнувшийся узел пробует передать свое сообщение уже вслед еще раз. Поэтому при одновременной передаче доступ к линии (выигрывает арбитраж) получает узел с самым приоритетным началом посылки (идентификтором) — т.е. чем меньше идентификатор в цифровом представлении, тем выше приоритет (одинаковые идентификаторы — запрещены). Так автоматически разрешаются коллизии — не нужен мастер в сети, все шлют «когда хотят». А еще на этом же механизме (рецессивных и доминантных состояний) основано подтверждение посылки — в самом конце передачи есть битик, который должен быть всегда равен единице и который называется битом подтверждения (ack). Если какой-то из узлов плохо расслышал посылку, то он утягивает линию в ноль — передающий узел видит, что посылку кто-то не воспринял и автоматически (аппаратно) перепосылает еще раз. В RS всё это невозможно. Это же всё и минус CAN — такая система накладывает ограничения на максимальную длину линии/частоту передачи, чтобы узел на конце линии, выставив доминантный ноль, мог за время передачи одного бита быть услышан узлом в начале сети (скорость света, переходные процессы и всё такое). CAN — это не просто линия передачи, а целый протокол — там и бит стаффинг, и контрольная сумма и арбитраж (неразрушающий доступ к линии), и перепосылка данных — и все это на аппаратном уровне выполняется контроллером CAN линии в микроконтроллере.
Может я не понял, но помехоустойчивость это способность работать в сложной ЭМ обстановке(2х тактный выход как раз там покажет себя с положительной стороны) и разруливание коллизий на нее не влияет. То, что плюшек больше на CAN я не спорю.
Если CAN рассматривать не просто как физическую линию, а вместе с неотъемлемыми функциями аппаратной проверки контрольной суммы и перепосылки сообщения, то он покажет себя лучше по сравнению с RS, несмотря на более «слабый» физический сигнал передачи. И по количеству неполученных посылок CAN выиграет в большинстве случаев у RS — он просто перепошет битое сообщение, никто даже и не заметит. А в RS вы явно получите битые данные и будете программно уже их верифицировать протоколом более высокого уровня. Так что всё зависит от методов сравнения.
а у CAN все проверки разве на аппаратном уровне?
Арбитраж доступа, механизмы контроля и предотвращения ошибок (а их в CAN несколько — bit stuffing, проверка контрольной суммы), автоматическая перепосылка недоставленного сообщения — все это реализуется на аппаратном уровне. Вероятность невыявления ошибки передачи 4,7×10−11 (Из вики). Таким образом, надежность передачи сообщений в CAN очень высока. При этом программисту не надо об этом особо задумываться — отправляешь данные и знаешь, что они дойдут. В RS все тяготы разрешения конфликтов, расчета контрольных сумм, проверок доставлено ли сообщение и т.д. ложатся на плечи программиста.
не туда
Читаю, прямо по-живому всё! Спасибо, приятно осознавать что ты не одинок)
Но у меня есть чем поделиться: motorcontrol построен на stm32f3, а данные я снимаю через STMStudio по SWD.
Быстродействие можно довести до 50-80Гц, в зависимости от числа снимаемых переменных.
Есть возможность записи в регистры. Контроллер не останавливается и не резетится.
Минус — сидишь рядом с 20-30КВт оборудованием, да и SWD довольно чувствителен к помехам, даже с экранированными кабелями.
А вот снятие осциллограмм из ОЗУ приходилось делать через дебуггер CoIDE, копируя-вставляя столбец данных массива в Calc.
Если-бы STMStudio умела считывать и строить график по массиву — цены бы ей небыло.
Писать свою оболочку пока нет времени, стараемся получить нужный результат на том что есть.
Вот картинка для примера, рад буду ответить на вопросы или попробовать что-то новое.
Но у меня есть чем поделиться: motorcontrol построен на stm32f3, а данные я снимаю через STMStudio по SWD.
Быстродействие можно довести до 50-80Гц, в зависимости от числа снимаемых переменных.
Есть возможность записи в регистры. Контроллер не останавливается и не резетится.
Минус — сидишь рядом с 20-30КВт оборудованием, да и SWD довольно чувствителен к помехам, даже с экранированными кабелями.
А вот снятие осциллограмм из ОЗУ приходилось делать через дебуггер CoIDE, копируя-вставляя столбец данных массива в Calc.
Если-бы STMStudio умела считывать и строить график по массиву — цены бы ей небыло.
Писать свою оболочку пока нет времени, стараемся получить нужный результат на том что есть.
Вот картинка для примера, рад буду ответить на вопросы или попробовать что-то новое.
У нас есть порт нашего CANopen драйвера под STM32F4, я думаю, его можно и для f3 собрать, только он… инкапсулирован в RS :) То есть пакеты, которые аппаратно должны были бы идти по CAN, засунуты в RS и добавлена сверху контрольная сумма. Я это делал, когда мне нужно было поиграть с STM32F4 discovery, но играть хотелось со своей оболочкой, а с даташитом CAN разбираться не хотелось. Там всё работает, только медленно. Раз вы так мучаетесь… мы можем вам собрать упрощенную версию оболочки и драйвера, где вы сможете смотреть несколько переменных через массив. А в будущем мы, может быть, портируем наш CANopen для STM полноценно.
Спасибо за предложение, очень ценим такую открытость!
Благодаря вашей статье совершили очередной подход к документации к STMStudio и нашли как сделать скоростное получение переменных.
И сразу удалось довести до ума контроллер. С передачей по CAN пока повременим.
Получается, что ST ничуть не хуже TI в плане motorcontrol — просто не так распиарен. Ну и я даже не знаю как с 4х параллельно работающих ADC переходить на один)
Благодаря вашей статье совершили очередной подход к документации к STMStudio и нашли как сделать скоростное получение переменных.
И сразу удалось довести до ума контроллер. С передачей по CAN пока повременим.
Получается, что ST ничуть не хуже TI в плане motorcontrol — просто не так распиарен. Ну и я даже не знаю как с 4х параллельно работающих ADC переходить на один)
UPD: сегодня, по горячим следам, был найден способ записи и передачи stmstudio пакета данных, записанного в оперативку с любой скоростью. Пока только на их же примере, но на днях попробую на реальном силовом блоке. Snapshot trigger capture.
Как Вы оцениваете юзабельность нового кортесаМ4 от НИИЕТ? Хорошая микросхема получилась?
Юзабельна. Подождите, пожалуйста, 1 день — уже дописываю статью.
Любопытный материал будет, у Вас ведь эксклюзив, я так понимаю — была возможность с прототипом работать.
А эта микросхема уже пошла в серию, или до сих пор опытные образцы только? На сайте НИИЕТ ее пока нет в списке продукции
А эта микросхема уже пошла в серию, или до сих пор опытные образцы только? На сайте НИИЕТ ее пока нет в списке продукции
Даже чуть больше, чем с прототипом. К1921ВК01Т уже доступен к заказу. Пожалуйте к прочтению: geektimes.ru/company/npf_vektor/blog/269246
С огромным удовольствием читаю ваши статьи, и недоумеваю: почему же для новых локомотивов (в частности) закупают зарубежные тяговые приводы, если уже умеем делать всё сами?!
Спасибо. Уметь делать — это не тоже самое, что выпускать серийно. Еду тоже всяк умеет готовить, однако за перекусом все стоят в макдоналдс, а за кофе в старбакс. К нам на фирму каждый месяц приходит очередной заказчик, который говорит — мне нужен двигатель на пару мегаватт в поезд/дирижабль/марсоход/кофеварку, у вас есть готовый на складе? Мне нужен ЗАВТРА! Мы говорим — нету, но мы разрабатывали похожий. Для вас можем сделать то что надо на заказ. Сроки — год, оплата разработки — с вас. И заказчик уходит покупать в сименс. Потому что у них есть готовое. Понятно, что никто не хочет оплачивать разработку и освоение производства.
Так ведь прикол в том, что сами тяговые двигатели делаем сами. Стало быть, точно так же пришлось проводить НИРы и проектирование тяговых преобразователей, но почему это потребовалось отдать Альстому? Точно такая же фигня и со сроками разработки, и со стоимостью, с их точки зрения это было создание ТПр для вообще незнакомой им железки, а не комплексный проект, как могло быть в случае локализации.
Это все конечно необходимо для исследовательских задач, но так ли это нужно для большинства задач управления мотором, когда рынок кишит комплексными серво-решениями с внешним управлением как по примитивному STEP/DIR, так по скоростному CAN (CANopen CiA 402), так и по скоростному Ethernet (PROFINET IRT, EtherCat, Powerlink etc.). Как я понимаю, на CAN-Ethernet серводрайверах внедрены готовые типовые схемы управления, нужно только выбрать и настроить коэффициенты регуляторов — на сколько это ограничивает простор? Достаточно ли этого, скажем, для скоростной портальной 2осевой системы? А может бывают программируемые серводрайверы?
P.S. Любопытно, так как вы смогли справиться со стабилизацией тока в дуге?
P.P.S. Правильно ли я вообще назвал это серводрайвером? или правильней сервопривод, сервоконтроллер, сервоусилитель?
P.P.P.S. usb-can адаптер продаете отдельно? или может исходники есть? :)
P.S. Любопытно, так как вы смогли справиться со стабилизацией тока в дуге?
P.P.S. Правильно ли я вообще назвал это серводрайвером? или правильней сервопривод, сервоконтроллер, сервоусилитель?
P.P.P.S. usb-can адаптер продаете отдельно? или может исходники есть? :)
Если мы говорим о готовом покупном приводе, то там все уже спроектировано и отлажено, а производитель в необходимых случаях предоставляет свое ПО для снятия осциллограмм, прошивки и настройки всех регуляторов. А тут я рассказывал как самим на фирме уметь производить такие сложные устройства и их отлаживать. Конечно, это всегда философский вопрос, зачем что-то делать, если всё уже сделано… Но, пожалуй, оставим его за кадром :)
Со стабилизацией тока в дуге справились, пришлось сделать спец. логику поверх ПИД регулятора для режимов розжига и падения шлака на электрод, чтобы оперативно отрабатывать неожиданные нештатные ситуации, в рабочем режиме справляется очень-очень быстродействующий ПИД (частота обсчета 100кГц)
Как по-русски правильно называть преобразователи для серводвигателей я не знаю. Слышал и сервопривод, и сервоконтроллер, и инвертор, и драйвер, и контроллер, и блок питания, и сервоусилитель, и… в общем, названия устоявшегося нет. Мне нравится сервоконтроллер, но длинновато.
USB-CAN используем готовые. Очень нравится продукция фирмы Марафон, но поддерживаем еще пару импортных аналогичных.
Со стабилизацией тока в дуге справились, пришлось сделать спец. логику поверх ПИД регулятора для режимов розжига и падения шлака на электрод, чтобы оперативно отрабатывать неожиданные нештатные ситуации, в рабочем режиме справляется очень-очень быстродействующий ПИД (частота обсчета 100кГц)
Как по-русски правильно называть преобразователи для серводвигателей я не знаю. Слышал и сервопривод, и сервоконтроллер, и инвертор, и драйвер, и контроллер, и блок питания, и сервоусилитель, и… в общем, названия устоявшегося нет. Мне нравится сервоконтроллер, но длинновато.
USB-CAN используем готовые. Очень нравится продукция фирмы Марафон, но поддерживаем еще пару импортных аналогичных.
А что, а что если передать софт для отладки по CAN в свободное пользование?))
Для отечественного К1921ВК01Т — пожалуйста bitbucket.org/niietcm4/motorcontroldemo
Sign up to leave a comment.
Способы отладки ПО микроконтроллеров в электроприводе