Спасибо! пробный период перед приобретением — это интересно. Несмотря на то, что для софта это нормально, для устройства как-то не подумали применить. Реализуем это первым шагом, а затем логично перейдем и к подписке. Ещё раз спасибо за идею!
Спасибо за предложение! Тоже думали, что схема с арендой/подпиской должна быть, но пока не решили, как реализовать. Если продукт «пойдет», то сделаем и её.
1) Как отмечалось в прошлой части перевода, там есть логика атомарного захвата аккумулятора, которая на ARM ядре совершенно не нужна
2) Если создавать DataPath в Datapath Config Tool, то там создаётся cy_psoc3_dp даже для пятого (как именно — я сейчас делаю авторскую статью)
Так что в третьем всё то же самое должно быть на уровне UDB. Разве что эпоха процессоров MCS-51 уже уходит в прошлое. Поэтому на практике — не проверял.
Если что — самая минималистичная макетка на PSoC5 — это CY8CKIT-059
Что на АЛИ, что в Терре она стоит около 1650 рублей (в Терре от трёх штук — дешевле, но кто для себя больше одной сразу берёт?). На АЛИ доставка включена, в Терре придётся добавить доставку, если нет пункта выдачи поблизости.
Добрый день!
Исходники можно скачать тут: www.astrosoft.ru/upload/files/Osc+Zoom_public20190201.rar
Модель осциллографа — Hantek 6254BC. Там в архиве есть EXEшник — \Osc+Zoom\osc\bin\x86\Release\osc1.exe — его можно запускать без сборки проекта. Все нужные DLL лежат рядом. Перед отправкой проверил — у меня WIN7 работает. У автора — тоже. За остальное — никаких гарантий. Собирается всё в Visual Studio 9.0, она же 2008 — у автора есть задача, чтобы всё работало в Windows XP.
Вы про ПО осциллографа? Короткий ответ: Самодельное ПО на C#
Длинный ответ: Мы с товарищем купили по четырёхканальному Хантэку. Но ПО для четырёх каналов у них совсем неудобное. Много лишних движений с комбо боксом канальным. А нормального позиционирования в буфере у Хантэка никогда не было. Взяли SDK от него — это несерьёзно! В том режиме, в котором к нему идёт пример — всё работает, в остальных — съезжает калибровка. Несколько месяцев постигали суть их калибровки, постигли. Потом ещё оказалось, что DLLки, идущие с их ПО и с SDK — совершенно разные вещи. Взяли от ПО. Но одна функция дурацкая — пришлось дизассемблировать и править по живому. В общем, подготовка заняла полгода. Потом товарищ за несколько месяцев реализовал своё видение интерфейса для осциллографов. Единственное, чего не хватает для классики — функции sin(x)/x. Но он никак не хочет понять, зачем она, а мне — больше нравится линейное построение. Так как делалось под нас двоих — оставлено, как есть.
Выкладывать это на тот же github — надо много переделывать. Кто писал — не является профессиональным программистом (я участвовал только в подготовительных работах). Но если вдруг кто-то хочет надёргать идей — все исходники имеются и не закрыты никакими соглашениями.
Кстати, чисто к слову. У PSoC есть две очень приятных особенности по сравнению с обычными контроллерами
1) Если мы хотим соединить ножки — мы это просто через внутреннюю коммутацию делаем. Точнее, мы соединяем сигналы, а ресурс «ножки» при этом не расходуется.
2) Не надо думать о схождении пасьянса ножек. Я когда перетаскивал Marlin с Ардуино на STM32, долго и упорно раскладывал пасьянс, ведь часть ножек может быть выходом таймера, часть — входами АЦП, часть — SPI, часть — UART, причём часто на одной ноге может быть часть функций на выбор, а одна функция выбрасывается всего на 2-3 ножки. Короче, пасьянс я раскладывал долго. А тут всё через трассировку делаем. Какую ножку на функцию назначили, на ту нам и выбросят сигнал. Ибо всё-таки простенькая, но ПЛИС внутри. Теоретически, даже аналоговая коммутация есть, но на практике не проверял, только видел, что сопротивление будет килоомное.
Но это так, просто к месту высказывание. Само собой, за это надо платить. Причём рублями. При равных ядрах Cortex M3 в PSoC5LP и STM32F103, первый дороже. Но если его уж по тем или иным причинам взяли, то эта особенность очень греет душу.
Просто не вижу функциональных отличий от таймера( 1шт) в режиме ШИМ с фиксированной длительностью( 92 цикла) и изменяемым периодом.
Хорошо. Согласен. Правда, пока не ясно, как завязать работу этих двух таймеров (шагающего и считающего шаги), чтобы после каждого шага не задействовать ЦП. А ещё 32 битных таймеров у STM32 не так много, а 16 битов нам не хватит для хорошего задания всех требуемых частот. А если в ход пойдёт перепрограммирование делителей входной частоты, то тут уже пойдёт такая математика (чтобы константу 92 поменять), что проще не извращаться, а построить систему по классическому варианту, что на STM32, собственно и делается на практике.
Но ещё раз повторю, что цель цикла статей — показать, как можно работать с UDB. Не по принципу «Товарищи! Все переходим на это!», а просто чтобы все имели в виду. Меня оно в одном проекте сильно выручило. Детали из-за NDA не могу раскрыть, но на STM32 оно не решалось (требуемая скорость великовата была), а добавлять ПЛИС — это ещё один корпус с обвязкой и кучей ног STM на связь с ПЛИС (скорость же нужна была высокая). На UDB же всё прекрасно сделалось с применением единственного корпуса самого PSoC. Причём эта штука может даже без стабилизатора работать — она почти всеядна по питанию (от 2.7 до 5.5В). Поэтому владеть навыками программирования таких систем — стоит. Практиковаться лучше на чём-то интересном и более-менее сложном. Посему управление шаговиками — всего лишь иллюстрация на более-менее боевых вещах, что отражено в тексте.
Так что мне кажется, что говорить «На STM32 в целом, можно достичь примерно того же» — не совсем корректно. Ключевое слово — «примерно». Тут или всё, или ничего. Или очень красиво, но на UDB, или «в лоб», но на STM32. Полумеры нужны только когда для решения «в лоб» не хватает мощности, но её же хватает. А для такой же красоты — не хватает связующих звеньев, которые живут в UDB.
Иногда дело не только в красоте, но это уже не учебные задачи. Но я зацикливаюсь в рассуждениях… Поэтому обрываю их.
По первой части — не совсем два таймера. Если уж на то пошло, то три таймера.
1) Одновибратор, вырабатывающий сигнал Step нужной длины
2) Таймер задержки одного шага
3) Счётчик шагов
Только они связаны логикой, недоступной центральному процессору. Не факт, что STM32 сможет их переключать так же без отвлечения на каждом шаге.
По второй части — как Вы обычному ШИМу обеспечите точную подстройку частоты? Когда двигатель работает в одиночку — это не критично, но когда они шагают вместе — важно, чтобы средняя частота у них была завязана так, чтобы они остановились все в один и тот же момент времени. Но беда в том, что здесь совсем не ШИМ. Отличительная особенность ШИМ — постоянная частота, но разная скважность. У меня частота при разгоне и торможении — разная (при этом одновибратор, вырабатывающий импульс STEP никто не отменял). Так что и тут Вы не совсем правы.
И опять же, главная фишка в том, что подстройка всех этих параметров на критичном по времени участке не отвлекает ЦП. ЦП построил задание и ушёл. Строить он может с любой скоростью и любыми отвлечениями. Главное — чтобы успел построить к моменту, когда пора начинать. Шагать надо — точно. И именно этим занимается UDB, а не ЦП. Именно он отмеряет время между шагами, именно он формирует ход шагов.
Но ещё раз повторю, я тут не защищаю какую-то новую систему управления двигателями. Банальному STM32 в режиме прерываний от таймера уже хватает мощи на всё про всё, это Меге не хватало при микрошаге 1/32. Я просто нашёл интересные красивые решения для UDB. А на некрасивых всё уже давно работает.
Главная проблема Marlin (о которой я писал в первой части, ссылка — в начале статьи) как раз состоит в том, что там одна задача строит эти самые вектора, а другая — выдаёт шаги. И вот эти самые шаги съедают почти всю процессорную мощь, так как прерывания приходят безумно часто. Подробнее — во введении к первой части (оно огромное, перетаскивать в комментарий не стоит).
Предлагаемое решение — именно для второй задачи. Нам построили вектор. В классике — дальше начинаем шагать средствами процессора (с возможными вылетами за допустимую производительность, решаемой подачей двух или более шаговых импульсов на прерывание). В нашем случае — строим график шагов в памяти, после чего за нас шагает аппаратура (причём для каждого двигателя — независимо, так как у каждого свой UDB). И как дошагает, так мы знаем, где мы. Полная аналогия с шагающим обработчиком прерываний Marlin, только без отвлечения ЦП. И с возможной большей частотой шагов.
Процессорному ядру никто не мешает в это время строить график шагов для следующего вектора, чтобы не было задержек. Уж что-что, а задержки мне знакомы, я ради них три версии Wifi «прошивки» для ESP8266 делал, первые две подтормаживали чуть-чуть.
Но главное применение данной информации — это изучение возможностей UDB. Потому что интереснее изучать такие вещи на чём-то, более серьёзном, чем мигание светодиодами. Вот, хороший повод.
Число шагов программа кладёт в D1, во время работы оно попадает в A1. Автомат будет работать, пока это значение не занулится. Так что шаги отсчитываются точно.
Судя по осциллограммам, всё будет верно. Если честно, я просто добился осциллограмм, как в настоящем 3D принтере (я их снимал в 2016-м, когда Marlin на STM32 перетаскивал), а на практике пока времени не было проверять. Здесь речь идёт скорее о практических опытах с UDB, чтобы разбавить сухую теорию. А играть приятнее с чем-то реальным. Проблема частых прерываний в 3D принтере — вполне реальная вещь.
В целом, что описано в данной статье — это сферический конь в вакууме. Если головку резко дёрнуть — двигатель пропустит шаги при разгоне. Тут-то погрешность и набежит. Чтобы этого не происходило — как я отметил в тексте, надо добавлять ускорения. Чуть попозже опишу, как я этого добивался (снова — применительно к практике работы с UDB). Тут — просто и так огромный текст получился.
Вот и я к такому выводу пришёл. Не панацея, но там, где возможно — на вход в прерывания такты не тратятся, проблемы приоритетов — не стоит, так как всё исполняется в параллель, проблемы кэша не стоит, поэтому всё отмеряется с точностью до такта… Сплошные положительные эмоции.
Жаль, что не везде это можно заменить. Вычислительные мощности — ограничены, а когда надо данные пересылать — там уже латентность шины всех ограничивает, на эту тему у меня в голове отдельная большая статья крутится. Но где можно заменить прерывания на обработку в UDB — там эмоции только положительные.
Попробовал написать развёрнуто. Получилось громоздко. Перепишу кратко.
На FPGA это точно не похоже. Тут нет тех ресурсов, которые есть там. UDB — это что-то между CPLD и FPGA. Если в FPGA мы создаём сущности сами, а в CPLD у нас на это нет ресурсов, то тут ресурсы есть, но они спущены нам сверху (DataPath и АЛУ, как часть его, плюс семибитные счётчики). PLD используются для связывания ресурсов и настройки их логики.
Так что мне кажется, что тут надо вывихивать мозг в сторону разработки микропрограмм. Завтра-послезавтра надеюсь довести до выкладывательного состояния ещё одну статью, где на базе UDB делается этакий сопроцессор для центрального процессора. Там нет законченного практического результата, но как раз я постарался показать в стиле «А можно вот так, а можно — так...».
Ещё можно посмотреть видеоуроки по ссылке из этой статьи (раздел «Ссылки на теорию»). Это — примеры, как мыслят сотрудники компании-производителя.
Когда говорим о скорости, помним, что это живёт в контроллере с ядром Cortex M3. Насколько я помню, у него предельная частота около 80 МГц (у меня сейчас в текущем проекте стоит 72). Выше не может быть в принципе. А так — в упомянутом текущем проекте у одного блока Fmax была чуть выше 60 МГц. Одно неверное движение, и она упала до 16. Изменил режим входной ножки — вернулась обратно. Бывали случаи, когда предельная частота блока была в районе 24 МГц, изменяя логику — удавалось поднять до 33. В общем, порядки значений ясны. Значение Fmax, как и для всей программируемой логики, выдаётся в отчётах о компиляции.
Интерфейсы в PSoC реализуются двояко. Зависит от семейства. Может быть один UART аппаратный, остальные — на UDB. То же касается и других интерфейсов. Всё надо смотреть в документе TRM. На первом рисунке к этой статье (который ещё без номера) видно, что у PSoC5LP имеются аппаратные таймеры-ШИМы, имеется аппаратный CAN, имеются аппаратный I2S и аппаратный USB. остальное — через UDB. У других семейств — иначе.
Про вычислительные инструкции — будет понятнее после следующей порции перевода.
Всё как раз началось с практической статьи. Но оказалось, что не все знакомы с самой идеей UDB. В планах — делать сухие переводы документа (в нём практики нет) и перемежать их с практическими авторскими вещами. Если тема не окажется неинтересной, и планы не будут изменены.
По поводу процессоров без ISP — тут Redd вряд ли поможет… впрочем, мы в практике уже давненько с ними не сталкивались.
1) Как отмечалось в прошлой части перевода, там есть логика атомарного захвата аккумулятора, которая на ARM ядре совершенно не нужна
2) Если создавать DataPath в Datapath Config Tool, то там создаётся cy_psoc3_dp даже для пятого (как именно — я сейчас делаю авторскую статью)
Так что в третьем всё то же самое должно быть на уровне UDB. Разве что эпоха процессоров MCS-51 уже уходит в прошлое. Поэтому на практике — не проверял.
Что на АЛИ, что в Терре она стоит около 1650 рублей (в Терре от трёх штук — дешевле, но кто для себя больше одной сразу берёт?). На АЛИ доставка включена, в Терре придётся добавить доставку, если нет пункта выдачи поблизости.
Исходники можно скачать тут: www.astrosoft.ru/upload/files/Osc+Zoom_public20190201.rar
Модель осциллографа — Hantek 6254BC. Там в архиве есть EXEшник — \Osc+Zoom\osc\bin\x86\Release\osc1.exe — его можно запускать без сборки проекта. Все нужные DLL лежат рядом. Перед отправкой проверил — у меня WIN7 работает. У автора — тоже. За остальное — никаких гарантий. Собирается всё в Visual Studio 9.0, она же 2008 — у автора есть задача, чтобы всё работало в Windows XP.
Длинный ответ: Мы с товарищем купили по четырёхканальному Хантэку. Но ПО для четырёх каналов у них совсем неудобное. Много лишних движений с комбо боксом канальным. А нормального позиционирования в буфере у Хантэка никогда не было. Взяли SDK от него — это несерьёзно! В том режиме, в котором к нему идёт пример — всё работает, в остальных — съезжает калибровка. Несколько месяцев постигали суть их калибровки, постигли. Потом ещё оказалось, что DLLки, идущие с их ПО и с SDK — совершенно разные вещи. Взяли от ПО. Но одна функция дурацкая — пришлось дизассемблировать и править по живому. В общем, подготовка заняла полгода. Потом товарищ за несколько месяцев реализовал своё видение интерфейса для осциллографов. Единственное, чего не хватает для классики — функции sin(x)/x. Но он никак не хочет понять, зачем она, а мне — больше нравится линейное построение. Так как делалось под нас двоих — оставлено, как есть.
Выкладывать это на тот же github — надо много переделывать. Кто писал — не является профессиональным программистом (я участвовал только в подготовительных работах). Но если вдруг кто-то хочет надёргать идей — все исходники имеются и не закрыты никакими соглашениями.
1) Если мы хотим соединить ножки — мы это просто через внутреннюю коммутацию делаем. Точнее, мы соединяем сигналы, а ресурс «ножки» при этом не расходуется.
2) Не надо думать о схождении пасьянса ножек. Я когда перетаскивал Marlin с Ардуино на STM32, долго и упорно раскладывал пасьянс, ведь часть ножек может быть выходом таймера, часть — входами АЦП, часть — SPI, часть — UART, причём часто на одной ноге может быть часть функций на выбор, а одна функция выбрасывается всего на 2-3 ножки. Короче, пасьянс я раскладывал долго. А тут всё через трассировку делаем. Какую ножку на функцию назначили, на ту нам и выбросят сигнал. Ибо всё-таки простенькая, но ПЛИС внутри. Теоретически, даже аналоговая коммутация есть, но на практике не проверял, только видел, что сопротивление будет килоомное.
Но это так, просто к месту высказывание. Само собой, за это надо платить. Причём рублями. При равных ядрах Cortex M3 в PSoC5LP и STM32F103, первый дороже. Но если его уж по тем или иным причинам взяли, то эта особенность очень греет душу.
Но ещё раз повторю, что цель цикла статей — показать, как можно работать с UDB. Не по принципу «Товарищи! Все переходим на это!», а просто чтобы все имели в виду. Меня оно в одном проекте сильно выручило. Детали из-за NDA не могу раскрыть, но на STM32 оно не решалось (требуемая скорость великовата была), а добавлять ПЛИС — это ещё один корпус с обвязкой и кучей ног STM на связь с ПЛИС (скорость же нужна была высокая). На UDB же всё прекрасно сделалось с применением единственного корпуса самого PSoC. Причём эта штука может даже без стабилизатора работать — она почти всеядна по питанию (от 2.7 до 5.5В). Поэтому владеть навыками программирования таких систем — стоит. Практиковаться лучше на чём-то интересном и более-менее сложном. Посему управление шаговиками — всего лишь иллюстрация на более-менее боевых вещах, что отражено в тексте.
Так что мне кажется, что говорить «На STM32 в целом, можно достичь примерно того же» — не совсем корректно. Ключевое слово — «примерно». Тут или всё, или ничего. Или очень красиво, но на UDB, или «в лоб», но на STM32. Полумеры нужны только когда для решения «в лоб» не хватает мощности, но её же хватает. А для такой же красоты — не хватает связующих звеньев, которые живут в UDB.
Иногда дело не только в красоте, но это уже не учебные задачи. Но я зацикливаюсь в рассуждениях… Поэтому обрываю их.
1) Одновибратор, вырабатывающий сигнал Step нужной длины
2) Таймер задержки одного шага
3) Счётчик шагов
Только они связаны логикой, недоступной центральному процессору. Не факт, что STM32 сможет их переключать так же без отвлечения на каждом шаге.
По второй части — как Вы обычному ШИМу обеспечите точную подстройку частоты? Когда двигатель работает в одиночку — это не критично, но когда они шагают вместе — важно, чтобы средняя частота у них была завязана так, чтобы они остановились все в один и тот же момент времени. Но беда в том, что здесь совсем не ШИМ. Отличительная особенность ШИМ — постоянная частота, но разная скважность. У меня частота при разгоне и торможении — разная (при этом одновибратор, вырабатывающий импульс STEP никто не отменял). Так что и тут Вы не совсем правы.
И опять же, главная фишка в том, что подстройка всех этих параметров на критичном по времени участке не отвлекает ЦП. ЦП построил задание и ушёл. Строить он может с любой скоростью и любыми отвлечениями. Главное — чтобы успел построить к моменту, когда пора начинать. Шагать надо — точно. И именно этим занимается UDB, а не ЦП. Именно он отмеряет время между шагами, именно он формирует ход шагов.
Но ещё раз повторю, я тут не защищаю какую-то новую систему управления двигателями. Банальному STM32 в режиме прерываний от таймера уже хватает мощи на всё про всё, это Меге не хватало при микрошаге 1/32. Я просто нашёл интересные красивые решения для UDB. А на некрасивых всё уже давно работает.
Предлагаемое решение — именно для второй задачи. Нам построили вектор. В классике — дальше начинаем шагать средствами процессора (с возможными вылетами за допустимую производительность, решаемой подачей двух или более шаговых импульсов на прерывание). В нашем случае — строим график шагов в памяти, после чего за нас шагает аппаратура (причём для каждого двигателя — независимо, так как у каждого свой UDB). И как дошагает, так мы знаем, где мы. Полная аналогия с шагающим обработчиком прерываний Marlin, только без отвлечения ЦП. И с возможной большей частотой шагов.
Процессорному ядру никто не мешает в это время строить график шагов для следующего вектора, чтобы не было задержек. Уж что-что, а задержки мне знакомы, я ради них три версии Wifi «прошивки» для ESP8266 делал, первые две подтормаживали чуть-чуть.
Но главное применение данной информации — это изучение возможностей UDB. Потому что интереснее изучать такие вещи на чём-то, более серьёзном, чем мигание светодиодами. Вот, хороший повод.
В целом, что описано в данной статье — это сферический конь в вакууме. Если головку резко дёрнуть — двигатель пропустит шаги при разгоне. Тут-то погрешность и набежит. Чтобы этого не происходило — как я отметил в тексте, надо добавлять ускорения. Чуть попозже опишу, как я этого добивался (снова — применительно к практике работы с UDB). Тут — просто и так огромный текст получился.
Жаль, что не везде это можно заменить. Вычислительные мощности — ограничены, а когда надо данные пересылать — там уже латентность шины всех ограничивает, на эту тему у меня в голове отдельная большая статья крутится. Но где можно заменить прерывания на обработку в UDB — там эмоции только положительные.
На FPGA это точно не похоже. Тут нет тех ресурсов, которые есть там. UDB — это что-то между CPLD и FPGA. Если в FPGA мы создаём сущности сами, а в CPLD у нас на это нет ресурсов, то тут ресурсы есть, но они спущены нам сверху (DataPath и АЛУ, как часть его, плюс семибитные счётчики). PLD используются для связывания ресурсов и настройки их логики.
Так что мне кажется, что тут надо вывихивать мозг в сторону разработки микропрограмм. Завтра-послезавтра надеюсь довести до выкладывательного состояния ещё одну статью, где на базе UDB делается этакий сопроцессор для центрального процессора. Там нет законченного практического результата, но как раз я постарался показать в стиле «А можно вот так, а можно — так...».
Ещё можно посмотреть видеоуроки по ссылке из этой статьи (раздел «Ссылки на теорию»). Это — примеры, как мыслят сотрудники компании-производителя.
Интерфейсы в PSoC реализуются двояко. Зависит от семейства. Может быть один UART аппаратный, остальные — на UDB. То же касается и других интерфейсов. Всё надо смотреть в документе TRM. На первом рисунке к этой статье (который ещё без номера) видно, что у PSoC5LP имеются аппаратные таймеры-ШИМы, имеется аппаратный CAN, имеются аппаратный I2S и аппаратный USB. остальное — через UDB. У других семейств — иначе.
Про вычислительные инструкции — будет понятнее после следующей порции перевода.