В первой статье цикла я активно продвигал идею, что разработка кода под 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-флешки), с которых можно загрузиться, после чего загружается операционная система.

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

Все современные микропроцессоры и микроконтроллеры содержат какие-либо механизмы прерывания. Эти механизмы необходимы для обеспечения «отзывчивости», требуемой многими приложениями. Безусловно, отзывчивость и предсказуемость являются основной целью при использовании ОСРВ, но при этом они противостоят друг другу. Использование прерываний может нарушить целостность реального времени ОС. Эта проблема и ее решение были затронуты в одной из предыдущих статей (#4 и #6). В этой статье мы рассмотрим стратегию обработки прерываний, используемую в Nucleus SE. Во всех случаях прерывания НЕ управляются Nucleus SE: они обрабатываются при возникновении согласно приоритету и векторам обычным способом. Время их выполнения просто «крадется» из доступного времени в коде основного приложения и планировщика. Очевидно, из этого следует, что все обработчики прерывания должны быть простыми, короткими и быстрыми.

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



Открыть коробочку с такими платами и быстро взять одну для решения каких-то задач — в порядке вещей. Именно так, недавно я взял очередную плату, прошил уже хорошо отлаженной и проверенной «прошивкой» и… получил неопознанное USB-устройство. Взял другую плату, «прошил» её, там устройство заработало. Тут бы делу и конец, но интересно же, в чём дело. Поэтому, как пришли выходные, я занялся детальным исследованием, почему же она не работает.

В прошлой статье я сказал, что нам пора переходить к потоковым протоколам. Но начав подготовку рассказа о них, я понял, что сам плаваю в одной очень важной теме. Как уже отмечалось, у меня с Линуксом достаточно своеобразные отношения. В общем, я понял, что сам не могу создать с нуля приложение на С++, которое удовлетворяло бы всем принципам программирования для Redd. Можно было бы попросить кого-то сделать это, а затем просто воспользоваться готовым шаблоном, но цикл статей призван научить всех вести разработку под Redd с нуля. Поэтому я попросил своего начальника (большого специалиста по Линуксу), и он разъяснил мне, что за чем нажимать. Затем я чуть переосмыслил его слова и теперь считаю нужным зафиксировать все знания письменно. Это избавит таких, как я, от мучительных раздумий: «Так… Что он сделал – понятно, но как мне это повторить?». В общем, кто работает под Линуксом, можете пробежать следующие два раздела по диагонали. Вряд ли вы найдёте там что-то новое (дальше – найдёте). А остальным я предлагаю на выбор две методики разработки, которые соответствуют декларируемым принципам работы под Redd: низкие трудозатраты на разработку и удалённая отладка.

Идея программных таймеров была введена в одной из предыдущих статей. Они являются объектами ядра, предоставляющими задачам простой способ запуска событий по времени, или, чаще всего, способ выполнять действия на регулярной основе. Все детали функционала, связанного со временем (точность, обработка прерываний и т.д.) в Nucleus SE были рассмотрены в предыдущей статье.

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

Понятие времени в контексте ОСРВ была введена в одной из предыдущих статей, вместе с идеей о связанных со временем функциях, доступных в ОСРВ.

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

Мы завершаем нашу эпопею с переводом фирменной документации Cypress об UDB. Последний выпуск – про адресацию UDB – перед вами.

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

Очередная глава из официальной документации Cypress про управление тактированием и сбросом. Как уже упоминалось в первой статье этого цикла, этот модуль обеспечивает выбор и разрешение тактирования, а также выбор сброса внутри UDB. Подробнее — под катом.

Ну что ж, мы уже знаем всё, что нужно для программирования UDB. Но одно дело – знать, и совсем другое – уметь. Поэтому сегодня мы обсудим, где и как можно черпать вдохновение для повышения собственного мастерства, где набираться опыта. Как видно из перевода документации, там есть сухие знания, которые даже не всегда привязаны к реальной практике (я заострил на этом внимание в достаточно пространном примечании, к последнему на сегодняшний день переводу). Собственно, статистика просмотров статей показывает, что переводы читает всё меньше и меньше людей. Было даже предложение прервать этот цикл, как неинтересный, но осталось всего две части, поэтому, в конце концов, просто было решено снизить темп их подготовки. В общем, документация на контроллер – штука нужная, но не самодостаточная. Где же ещё черпать вдохновение?



В первую очередь, могу порекомендовать отличный документ AN82156 Designing PSoC Creator Components with UDB Datapaths. В нём вы найдёте типовые решения, а также несколько типовых проектов. Причём в начале документа разработка идёт при помощи UDB Editor, а ближе к концу – при помощи Datapath Config Tool, то есть, документ охватывает все аспекты разработки. Но к сожалению, глядя на цену одной микросхемы PSoC, я бы сказал, что если она может решить только вопросы, описанные в этом документе, то контроллер сильно переоценен. ШИМы и стандартные последовательные порты можно делать и без PSoC. К счастью, диапазон решаемых PSoC задач намного шире. Поэтому, закончив чтение AN82156, начинаем искать иные источники вдохновения.

В данной статье мы продолжим рассматривать каналы передачи данных.

Вспомогательные службы каналов

Nucleus RTOS имеет четыре вызова API, которые предоставляют вспомогательные функции, связанные с каналами: сброс канала, получение информации о канале, получение количества каналов в приложении и получение указателей на все каналы в приложении. Первые три функции реализованы в Nucleus SE.

После небольшого перерыва мы продолжаем публиковать переводы статей «Вся правда об ОСРВ» Колина Уоллса. В этот раз поговорим о каналах передачи данных (далее – каналы), которые были уже были упомянуты в одной из предыдущих статей, а именно в #5. Каналы, по сравнению с почтовыми ящиками (#21 и #22) или очередями (#23 и #24), предоставляют более гибкий способ передачи простых сообщений между задачами.

Я очень люблю видеоуроки. Почему-то информацию с текста лично я воспринимаю весьма и весьма плохо. А есть вещи, в которых информации на бумаге не так много. Возьмём, к примеру, уроки игры на балалайке: на YouTube есть замечательные разборы, как играть ту или иную мелодию (кому интересно, ищем по имени «Сергей Воронцов»), но повторить и заучить последовательность с потокового видео сложно. Надо или записывать на бумагу (судя по комментариям под уроками, некоторые так и делают), или докупать дополнительные материалы (но я не жадный, а домовитый).



В общем, в моём балалаечном случае, да и при многих других, надо идти так: посмотрел фрагмент, поставил на паузу, повторил несколько раз за автором, продолжил просмотр. Если что-то непонятно — отмотал назад, посмотрел повнимательнее. Но как это всё мотать, если руки заняты? Тем более, в моём случае они заняты пусть не огромным баяном, но всё-таки какой-никакой, а балалайкой. Значит, работать надо при помощи ног.