Три статьи назад мы сделали голову для шинного анализатора USB, после чего – обсуждали вопросы моделирования и гоняли эту голову на моделях. Правда, всё это было не зря. В прошлой статье я показательно нашёл пару сбоев логики, а в реальности их было чуть больше. Поэтому, начни я всё проверять сразу в железе — сидел бы и сокрушался: «А чего оно так себя ведёт?» Теперь же я уверен, что в поведенческой модели вся логика делает именно то, что было задумано. Что дальше? Те, кто делает серьёзные большие проекты, дальше переходят к моделированию синтезированной модели, а в конце — модели, привязанной к реальной топологии упаковки в ПЛИС (так называемое Gate-Level моделирование). Там уже учитываются задержки на всех трассировочных ресурсах при именно этом результате компиляции. Но проект нашей сложности этого не требует. Нам было достаточно убедиться, что вся логика реализована верно. И теперь мы можем перейти к сборке реального анализатора и проверке его работы на практике.

В прошлых статьях мы прошли достаточно большой путь к созданию шинного анализатора USB. Мы разработали логический анализатор, набив руку на самой технологии, дальше – разработали голову USB-анализатора. Затем – выяснили, что код получился сложным, так что его следует отмоделировать. Но вот беда, доступная модель микросхемы ULPI разработана на языке SystemC. Мы научились работать с этим языком. Наконец-то, мы владеем всеми необходимыми навыками и готовы провести проверку нашего ядра. Приступаем!

В прошлой статье мы познакомились с процессом моделирования «прошивки» в среде ModelSim, где и целевой код, и генератор тестовых воздействий написаны на языке Verilog. Жаль, но для решаемой в цикле цели этого недостаточно. Я уже многократно продвигал идею, что разработка для комплекса Redd должна идти с наименьшими трудозатратами. Если модель устройства пишется быстро, её можно написать с нуля. В прошлый раз мы сделали модель шины, по которой писали байты в сумматор. Но ULPI — очень сложная вещь. Написать её модель с нуля — ой, как не просто. Если можно найти готовую, лучше это сделать. И я нашёл… Увы и ах, она оказалась на языке SystemC. Как начать работать с этим языком, мы сейчас и рассмотрим.

Как я уже несколько раз упоминал в прошлых статьях, я один из разработчиков сервиса All Hardware, через который любой желающий может удалённо поработать с различными отладочными платами, которые туда выкладывают производители микроконтроллеров. По умолчанию, в каждую плату загружено типовое демонстрационное приложение. Проект для самостоятельной сборки этого приложения можно скачать, чтобы начать опыты не с чистого листа. Всё бы ничего, но разные пользователи предпочитают разные среды разработки. Всё многообразие, разумеется, охватить невозможно, но хотя бы Eclipse, а значит, вообще GNU (в случае STM32 — это скорее спецсборка STM32 Cube IDE) и Keil c IAR — стоит. Собственно, мне было поручено произвести хоть какую-то унификацию демонстрационных проектов для плат STM32. В статье я расскажу сначала, как быть простому пользователю, который зашёл на сервис и скачал пример. Что нужно сделать, чтобы собрать его. Ну, а уже затем, будет немножко мемуаров, обосновывающих выбранное решение, а также просто описывающих впечатления о работе.

Иногда получается, что при выполнении очередного проекта, я случайно открываю какие-то обстоятельства, которые, вроде, никто не скрывает, можно даже найти документацию, поясняющую суть… Но многие, включая меня, находятся в плену заблуждений, поэтому не ищут ту документацию, полагаясь на совершенно неверную картину мира. У меня уже намечается целый цикл из статей, в которых я просто сообщаю, что всё, оказывается, не так, как многие (включая меня) думали. Была у меня статья про DMA, была статья про производительность шины PCI Express. К этому же циклу можно отнести статью про конфигурационные ПЗУ для ПЛИС Altera.

Сегодня мне хотелось бы рассказать пару слов про работу Windows Firewall, или, как его называют в русифицированной ОС – брандмауэра. В целом, это очень хорошая штука, но в частности… Оказывается, по умолчанию он работает в достаточно интересном режиме. Как говорится: «А пацаны и не знают». Итак, начинаем разбираться, что там к чему.

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

В прошлой паре статей мы рассмотрели пример «прошивки» для комплекса Redd, делающей его ПЛИСовую часть логическим анализатором общего применения. Дальше у меня было желание сделать следующий шаг и превратить его в шинный USB-анализатор. Дело в том, что фирменные анализаторы такого вида очень дорогие, а мне необходимо провести проверку, почему одна и та же USB поделка, если её подключить к машине, работает, а если включить машину, когда всё уже воткнуто в разъём, не работает. То есть, программные анализаторы тут не справятся. По мере написания я как-то увлёкся и написал блок из пяти статей. Теперь можно сказать, что в них показан не только сам анализатор, но и типовой процесс его создания в режиме «на скорую руку». В статье будет показано, как сделать такой анализатор не только на базе Redd, но и на готовых макетных платах, которые можно приобрести на Ali Express.

В прошлой статье мы сделали аппаратуру, реализующую логический анализатор на базе комплекса Redd. Статья разрослась так, что рассмотрение программной поддержки мы отложили на потом. Пришла пора разобраться с тем, как мы будем получать и отображать данные, которые анализатор копит в ОЗУ.

В прошлой статье цикла мы потренировались сохранять данные из потокового интерфейса в память средствами DMA. Пришла пора сделать какую-то полезную поделку, используя полученные навыки. Очень полезная при удалённой отладке вещь — анализатор. Вообще, при работе с комплексом скорее нужны специализированные шинные анализаторы, но начинать лучше с чего-то попроще. Поэтому сейчас мы сделаем простейший логический анализатор на 32 канала. Понятно, что он будет совсем-совсем примитивным, но зато мы сделаем его своими руками. У кого ещё нет комплекса Redd, могут повторить опыт, используя любую макетную плату с ПЛИС фирмы Altera (Intel) и микросхемой ОЗУ. Итак, приступаем.

В рамках проекта All-Hardware довелось мне освоить работу с экраном на макетной плате LPC55S69-EVK фирмы NXP. Пикантность ситуации состоит в том, что штатно эта плата поставляется без экрана, так что в освоение работы также входил поиск экрана, который можно достать в наших краях, и его подключение.



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

Продолжаем двигаться к созданию реальных устройств на базе ПЛИС комплекса Redd. Для другого проекта All-Hardware мне нужен простенький логический анализатор, поэтому будем двигаться именно в этом направлении. Повезёт — дойдём и до шинного анализатора USB (но это пока в отдалённой перспективе). Сердцем любого анализатора является ОЗУ и блок, который сначала закачивает в него данные, а затем изымает их. Сегодня мы как раз спроектируем его.

Для этого мы освоим блок DMA. Вообще, DMA — моя любимая тема. Я даже делал большую статью про DMA у некоторых контроллеров ARM. Из той статьи видно, что DMA отнимает такты у шины. В текущей статье мы рассмотрим, как дела обстоят в случае процессорной системы на базе ПЛИС.

В прошлом блоке статей про комплекс для удалённой отладки Redd, я показал, что работа с ним – это не только работа с ПЛИС. Мало того, ПЛИС – это всего лишь очень интересная, но всё-таки весьма специфичная часть комплекса. Основная же его часть – мосты FTDI и прочие USB-шные вещи. Особого интереса тема не вызвала, но тем не менее, теперь все знают, какие именно основные аппаратные средства имеются в комплексе. И мы снова можем вернуться к рассмотрению интересной темы – ПЛИС.

Продолжим традицию предыдущего блока и будем дальше искать необязательные части. Сегодня мы научимся обходиться без процессорного ядра Nios II. Да-да. В процессорной системе Nios II само процессорное ядро – важный, но не обязательный элемент. Мы потренируемся делать систему без него, вынося все управляющие функции на уровень центрального процессора комплекса Redd.

Когда человек много лет рыл бункер и запасал там продукты, он должен испытывать глубокое моральное удовлетворение, если бункер понадобился. Он будет довольный заявлять: «А я говори-и-и-ил!» То же касается и того, кто делал запасы продуктов в кладовой, когда все закупались в магазинах только на сегодня. А вот с нашим комплексом для удалённой работы Redd как-то и не хочется злорадствовать. Он проектировался для удалёнки в мирное время. И использовался задолго до первых новостей из Китая.

Давно я про него ничего не писал. Другие проекты отвлекают, да и интерес, судя по рейтингу последней из опубликованных статей, уже упал. Сил на подготовку статьи отнимают много, и это имеет смысл делать только если оно нужно достаточному числу читателей.

Но так как сейчас удалёнка у всех на устах, возникло желание поделиться одной наработкой, которая может кому-то помочь. Это не наша разработка, я проводил исследования в рамках работы над сервисом удаленной работы с отладочными платами All-Hardware. Вот их результаты сейчас и опишу. Проект USB/IP известен многим. Но он давно свёрнут авторами. Самые свежие драйверы были под WIN7. Сегодня я опишу, где скачать вариант для WIN10, и покажу, как я его проверял. Кроме того, разработчики современного аналога уверяют, что у них сделан не только Windows-клиент, но и Windows-сервер (правда, в этом режиме я тестирование не вёл: задача того не требовала). Но кому-то это тоже может оказаться полезным.

В прошлой статье мы рассмотрели теорию по управлению тысячей мелочей в комплексе Redd, но чтобы не раздувать объём, отложили практику на следующий раз. Пришла пора провести практические опыты. Те же, кто не пользуется комплексом Redd, тоже смогут найти в этой статье полезные знания, а именно — методику подачи Vendor команд в USB накопители из ОС Linux, ведь как уже говорилось, контроллер STM32 в комплексе выполняет функцию SD-ридера, то есть — накопителя.

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

Мы закончили большой теоретический блок, показывающий, как можно строить ПЛИС-подсистему для комплекса Redd; как организовывать связь между ПЛИС и центральным процессором комплекса; как легко сохранять скоростные потоки данных в ОЗУ, имеющем прямую связь с ПЛИС, для последующей их неспешной перекачки к центральному процессору (или наоборот, помещать данные в это ОЗУ для последующей быстрой выдачи в канал). Мы рассмотрели методики трассировки работы процессора Nios II. Мы умеем оптимизировать быстродействие процессорной системы на базе Nios II, чтобы работа шла максимально эффективно. В общем, мы изучили весь необходимый минимум теории, и пора бы перейти к практике, спроектировав не очень сложное, но практически полезное устройство… Но имеется одно НО.

Из комментариев к статьям я заметил, что некоторые читатели полагают, что Redd и ПЛИС — как Ленин и Партия. Что они неразрывно связаны. На самом деле всё совсем не так. Просто начать разговор о комплексе Redd хотелось с чего-то интересного, а что может быть интереснее, чем ПЛИС? Ну, а начав разговор, прерываться на полуслове глупо. И вот, наконец, большой логический блок завершён. И чтобы показать, что ПЛИС — это далеко не весь Redd, предлагаю сделать ориентировочно три статьи о вещах, не связанных с ними. Ну, а завершив этот блок, уже перейти к ПЛИСовой практике.

До сих пор в этой серии статей мы рассматривали, какие функции предоставляет Nucleus SE. Сейчас пришло время посмотреть, как ее можно использовать в реальном приложении встраиваемого ПО.

До сих пор мы рассматривали тему, как повысить быстродействие системы, применяя какие-то интенсивные методы. Но на самом деле, есть методы и экстенсивные. Сейчас мы работаем на тактовой частоте 50 МГц, что связано с использованием компонента из набора для университетской программы (а без него невозможно тактировать SDRAM, которая требует, чтобы тактовые импульсы, идущие на микросхему, были сдвинуты относительно основных). Когда я вводил этот компонент в игру, то предупреждал, что данное решение — временное. Тогда я вываливал на читателя такое количество новой информации, что любое лишнее занудство могло привести к восклицанию: «Да ну эти ПЛИС, тут всё так сложно!». Сейчас мы уже легко и непринуждённо конструируем процессорные системы, уже всё страшное позади. Пришла пора разобраться, как можно сделать свой компонент, который позволяет повысить тактовую частоту как процессора, так и подключённой к нему периферии.

В прошлой статье мы выяснили, что кэш — это безусловно полезная штука, но применительно к контроллерной логике он иногда создаёт трудности. В частности, он вносит непредсказуемость длительности импульсов либо иных задержек при программном формировании временных диаграмм. Ну, и в «общепрограммистском» плане, неудачное расположение функции может свести выигрыш от кэша на нет, постоянно провоцируя его перезагрузку из медленной памяти. Я упоминал, что 15 лет назад мы вынуждены были делать специальный препроцессор, который устранял возникающие проблемы для процессора SPARC-8, и обещал, что расскажу, как легко устранить подобные трудности при разработке для синтезированного процессора Nios II, рекомендуемого для использования в комплексе Redd. Пришла пора выполнить обещание.

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



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