В прошлой статье мы сделали достаточно сложный модуль. Разумеется, я вставил в тело статьи уже отлаженный результат. Но мне показалось, что достаточно странно, когда автор говорит «делай, как я», но при этом не показывает очень важного процесса. Давайте я покажу, как вообще проводится отладка системы путём моделирования. Причём в следующей статье будут содержаться сведения, которые ещё неделю назад не знал даже я. Но, чтобы перейти к ним, надо разобраться с базовыми принципами. Итак. Давайте рассмотрим, как быстро подготовить и не менее быстро запустить процесс моделирования в среде 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 — вспомогательный инструмент, так что тратить на него уйму времени неправильно. То есть разработка под него должна идти быстро. Но это совсем не значит, что получившиеся программы должны быть неоптимальны. Собственно, если их совсем не оптимизировать, то просто мощности аппаратуры не хватит, чтобы реализовать нужную тестовую систему. Поэтому процесс, как я и сказал, должен быть быстрым и непринуждённым, но вот некоторые принципы оптимизации разработчик должен всегда держать в уме.



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

Основным требованием при разработке Nucleus SE была высокая степень совместимости с главным ОСРВ-продуктом Mentor – Nucleus RTOS. Nucleus SE поддерживает определенную часть функционала Nucleus RTOS, о чем много раз говорилось в предыдущих статьях, однако в этой статье я постараюсь собрать все ключевые отличия в одном месте. Данная статья задумывалась как краткий справочник для всех, кто собирается переходить с одного ядра на другое, либо находится в процессе выбора ядра для определенного проекта.



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

В Nucleus RTOS система может быть создана с неопределенным количеством объектов ядра, единственным ограничением здесь выступает количество доступных ресурсов (то есть памяти). Nucleus SE имеет ограничение в шестнадцать объектов каждого типа; система может иметь от одной до шестнадцати задач и от нуля до шестнадцати объектов каждого типа (почтовые ящики, очереди и т.д.). Несмотря на то, что этот лимит может быть увеличен, потребуются значительные усилия, так как в Nucleus SE широко используется возможность хранения индекса объекта в полубайте (четыре бита). Кроме того, при более чем шестнадцати задачах планировщик приоритетов (Priority), скорее всего, станет очень неэффективным. Приложение, функционал которого серьезно страдает от данных ограничений, не подходит для Nucleus SE, в данном случае Nucleus RTOS является гораздо более подходящим выбором.

При отладке обычных программ, точки останова можно ставить почти везде и в достаточно больших количествах. Увы. Когда программа исполняется на контроллере, это правило не действует. Если идёт участок, в котором формируется временная диаграмма, то остановка всё испортит. А проход на низкой и на высокой частоте — это не одно и то же. Граничные условия — бич разработчиков. Или, скажем, шина USB. В NIOS II я с нею не работал, но на STM32 — это ужас. И хочется что-то посмотреть, и при остановке словишь таймаут. В общем, очень часто, несмотря на наличие передовой JTAG отладки, поведение программы в критичных по времени участках покрыто мраком. Как было бы здорово хотя бы после исполнения поглядеть, по какой цепочке прошла программа, какие ветвления сработали, а какие нет!

Ещё важнее знать историю развития исключений. На NIOS II мне этого делать не доводилось, а вот на Cyclone V SoC в ядре ARM — вполне. При отладке всё работает, а стартуешь программу из ПЗУ — получаешь исключение. Как в него вошли — видно, а какое развитие ситуации привело к этому — нет. Трассировка же срывает все покровы.

Обработка ошибок – не самая распространенная вещь для операционных систем, предназначенных для приложений встраиваемых систем. Это является неизбежным результатом ограниченных ресурсов, поскольку все встраиваемые системы имеют те или иные ограничения. И лишь небольшое количество таких систем имеет возможность вести себя как настольные системы, то есть предлагать пользователю возможность выбора действий в случае возникновения исключительных событий.

В Nucleus SE, в целом, существуют три типа проверки ошибок:

• средства для проверки работоспособности выбранной конфигурации, чтобы убедиться, что выбранные параметры не приводят к возникновению ошибок;
• опционально включаемый код для проверки поведения времени выполнения;
• определенные функции API, способствующие разработке более надежного кода.

Все это будет рассмотрено в данной статье, вместе с некоторыми идеями, касающимися диагностики силами пользователя.

В предыдущих статьях мы уже познакомились с шиной Avalon-MM, где MM означает Memory Mapped, то есть проецируемая на память. Эта шина вполне себе универсальная. К ней может быть подключено несколько ведущих (Master) и несколько ведомых (Slave) устройств. Мы уже подключали сразу два ведущих устройства (Instruction Master и Data Master), потому что у процессора NIOS II гарвардская архитектура, так что шины команд и данных у него разные, но многие авторы для упрощения разработки ПО снаружи подключают их к одной и той же общей шине.

Если какой-то блок на шине имеет функциональность прямого доступа к памяти (DMA), то он также будет содержать ведущее устройство для шины.

Собственно, на этом факте (много ведущих, много ведомых) и основано главное неудобство данной шины. Когда мы проектировали своё ведомое устройство, нам приходилось декодировать адрес. Когда же мне доводилось делать своего ведущего, возни с арбитражем было существенно больше. А ведь красной нитью через весь цикл статей идёт утверждение, что разработка под Redd — вспомогательная часть проекта, она не должна требовать слишком много трудозатрат. И если можно освободиться от рутины, мы должны от неё освободиться.

У любой операционной системы есть определенный механизм запуска. Принцип работы этого механизма у каждой системы свой. Обычно говорят, что система загружается (англ. boot), это сокращение от «bootstrap», которое отсылает к выражению «pull oneself over a fence by one’s bootstraps» (перебраться через ограду, потянув себя за ремешки на обуви), что примерно описывает, как система самостоятельно переходит из состояния, в котором память заполнена пустотой (прим. переводчика: если совсем точно, то мусором) к стабильному выполнению программ. Традиционно в память загружается небольшая часть программы, она может храниться в ПЗУ. В прошлом она могла вводиться при помощи переключателей на передней панели компьютера. Этот начальный загрузчик считывал более сложную программу загрузки, которая уже загружала операционную систему. Сегодня настольный компьютер загружается следующим образом: код в BIOS ищет устройства (жесткие диски, CD-ROM, USB-флешки), с которых можно загрузиться, после чего загружается операционная система.

ОС для встраиваемых систем также может инициализироваться подобным образом. И в самом деле, встраиваемые операционные системы, разработанные на основе настольных операционных систем, так и загружаются. Но в большинстве «классических» ОСРВ используется гораздо более простой (а, следовательно, более быстрый) способ.