«Развернись на 180 градусов, проедь вперёд и включи фары»,
«Подъедь ближе к свету»,
«Если рядом ничего нет — проедь вперёд, потом поверни направо».

Хочется, чтобы даже игрушечные роботы понимали такие команды с полуслова. Без заученных фраз, без кнопок, без пульта. Нас к этому приучают голосовые ассистенты — Siri, Alexa, Алиса, но в DIY-проектах или любительской робототехнике такие интерфейсы встречаются редко, особенно когда речь идёт о чём-то более сложном, чем «вперёд» и «назад».

Готовых решений с распознаванием речи для различных устройств в продаже не нашёл, поэтому решил собрать всё самостоятельно. Получился контроллер для робота, который не просто «слушает», а действительно понимает команды.  

Когда мне предстоит начать работу с новым микроконтроллером, я обычно гляжу, а какое у него быстродействие GPIO. Сколько тактов на одну запись уходит по факту. Такая у меня традиция. Было дело, я так выяснил, что китайские клоны STM32 работают с GPIO чуть быстрее, чем оригинал. Для дешёвых контроллеров обычно ничего более интересного такие проверки не выявляют, но традиция есть традиция. Не изменял я ей и при начале освоения CH32x035 на базе RISC-V. И вот для него картинки получились такими интересными, что я решил поделиться ими с общественностью. Не то, чтобы там было что-то революционное, но от привычных мне они точно отличаются.

А ещё я добавлю к ним немного выводов… И нутром чую, что в комментариях мне объяснят, что я понимаю всё неправильно, а на самом деле… Но я буду только рад обоснованным высказываниям. Вместе мы установим истину.

В предыдущей статье я начал разбирать протокол управления блоком питания Fnirsi DPS-150. Там был разобран формат посылки, были выявлены команды и отклики на них, а также сделан черновой анализ внутренностей фирменной программы управления блоком. Детали процесса я обещал показать позже. Вот, эта пора настала. Сегодня мы получим настолько полные таблицы команд и откликов, насколько это требуется для реальной работы.

Сейчас мы переживаем революционный период, когда нейросети и ИИ перестают быть чем-то далёким и чуждым, и всё прочнее закрепляются в нашей жизни: школьники решают примеры при помощи Алисы, программисты ищут варианты решений в ChatGPT, художники стали осваивать искусство доработки изображений, сгенерированных в Midjourney или Шедевруме. Мы начинаем подгонять ИИ под себя. Именно рядовые пользователи, а не многомиллионные корпорации, предлагающие шаблонные решения.

Неудивительно, что ИИ-функционал теперь доступен и в устройствах для DIY. Посмотрим, что можно приобрести из таких устройств прямо сейчас. 

Сегодня я начну рассказывать, как изучал протокол программного управления блоком питания Fnirsi DPS 150. До подробного описания всех команд и откликов мы в этот раз, правда, не дойдём, но зато рассмотрим шаги, которые обязательно в итоге приведут нас к успеху. То есть, эта часть – не руководство, как программировать блок, а описание, как вскрывался протокол. Кому это интересно – начинаем.

Давно я ничего не писал про LiteX. Во-первых, очень много работы. Во-вторых, пришлось почитать курс студентам, подготовка тоже дико отвлекала, но наконец семестр подходит к концу. Ну, и в-третьих, в своих опытах я на пару шагов дальше того, что описываю, и вот эти опыты меня затянули. Пока что там всё выглядит достаточно мрачно. Производительность там такая, что плакать хочется. В общем, было трудно прерваться, чтобы описать то, что находится ещё на гарантированно светлой стороне.  Но если вы читаете эти строки, то я себя пересилил.

Я уже многократно писал,  что рассматриваю LiteX как некий аналог подсистемы Qsys из среды разработки Quartus. То есть, как удобное средство составить шинно-ориентированную систему из множества готовых ядер. Но если Qsys – он только для Альтер, то LiteX – он подходит и для Altera (Intel), и для Xilinx, и для Lattice. А сейчас я по работе плотно вожусь именно с Латтисами. У Латтисов самое узкое место – это параметр FMax. И вот построение базовых систем на базе шины Wishbone у Litex получается очень красиво. Там FMax выходит достаточно высоким. Даже у Латтисов он превышает 100 МГц.

В предыдущих статьях мы уже научились добавлять в систему устройства, доступные по шине через регистры команд-состояний (CSR), а также пассивные (Slave) устройства с шиной Wishbone. Сегодня мы добавим на шину активное (Master) устройство. Поехали!

Наш цикл про ПЛИС Lattice ECP5 растянулся уже на шесть статей. Мы уже научились не только создавать простые проекты для них, но набили руку в разработке сложных систем на базе кроссплатформенной открытой среды LiteX. В целом, я уже набрал материалов, чтобы выдать инструкцию, как подключится к шине Wishbone в роли активного устройства (Master), но перед публикацией хочется провести ряд проверок, чтобы не наболтать не того.

С другой стороны, ещё в первой статье цикла я обещал, как будет формализована методика сборки синтезатора Yosys и разводчика NextPNR под Windows, рассказать, как это сделать, так как на тот момент у меня процесс сборки прошёл в режиме «неделю промучился, как-то сделал, повторить не смогу». Мой коллега систематизировал все те наброски, и теперь я могу поделиться итогами с общественностью. Так что, кто дружит с Linux, сегодня вряд ли узнает что-то интересное, а вот любители Windows – получат сведения, как начать работать с ПЛИС Lattice в этой ОС. Приступаем.

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

Пока что наши собственные модули были подключены к  системе через регистры команд и состояний (CSR). Часто этого более, чем достаточно, но иногда всё-таки разрабатываемые блоки должны содержать в себе сложные наборы регистров, а может даже и память. И без прямого подключения к системной шине не обойтись.

Сегодня мы подключим пару собственных Slave-устройств к системной шине Wishbone, которая будет создана средой LiteX. Устройства, разумеется, будут описаны на Верилоге. Приступаем!

В предыдущей статье мы начали осваивать построение шинно-ориентированных систем на базе среды Litex (которая всё делает на Питоне) с внедрением собственных модулей на Верилоге. Статья так разрослась, что практические опыты мы оставили на потом. Пришла пора провести их. Сегодня мы подключимся к VGA-монитору и поуправляем изображением, которое выдаёт модуль gpu, описанный в файле gpu.v, то есть, реализованный на языке Verilog. Управлять мы им будем через регистр команд, расположенный в блоке CSR, спроецированном на шину Wishbone. Все эти сущности, в свою очередь относятся к среде Litex. Инструменты для опытов мы тоже будем использовать штатные, Litex-овские. Приступаем!

В предыдущей паре статей я рассуждал про ПЛИС Lattice. Давайте сегодня поговорим об эффективной разработке под них. Один наш крупный руководитель уверяет, что из разговоров с иностранными Заказчиками, он выяснил, что российских разработчиков считают пишущими классные вещи, но делающими это крайне медленно. Ну, разумеется, по сравнению с разработчиками из других стран. И разумеется, «классные» идёт на первом месте.

Один из методов обхода проблемы скорости разработки – использование готовой инфраструктуры для проектов. Я делал цикл статей про комплекс Redd, где продвигал использование готовой шинной инфраструктуры в среде разработки Quartus. Сначала это была честная процессорная система, потом – процессор мы изъяли, а шины – оставили.

Затем я делал пару циклов, где активно использовал данный подход. Мне приходилось дописывать только проблемно-ориентированные модули, остальное — среда разработки создавала за меня.

Есть ли что-то подобное для Lattice в частности и сцепки Yosys/NextPNR в целом? Вы не поверите! Решение не просто есть, но оно ещё и настолько кроссплатформенное, что подойдёт и для Yosys/NextPNR, и для Quartus, и для Vivado! И называется оно Litex. Итак, давайте попробуем поэкспериментировать с ним для подхода, который я уже давно продвигаю: «делаем штатную основу, а на неё нанизываем свои целевые блоки».