Что ж, мы уже знаем все, что нам нужно для программирования UDB. Но одно дело знать, а совсем другое уметь это делать.
Поэтому сегодня мы обсудим, где и как можно найти вдохновение для совершенствования собственных навыков, где набраться опыта.
Как видно из перевод документации , там сухие знания, даже не всегда привязанные к реальной практике (я обратил на это внимание в довольно пространной заметке к последнему на сегодняшний день переводу).
На самом деле статистика просмотров статей показывает, что переводы читает всё меньше людей.
Было даже предложение прервать этот цикл как неинтересный, но частей осталось всего две, так что в итоге было просто решено сбавить темп их подготовки.
В общем, документация на контроллер — вещь необходимая, но не самодостаточная.
Где еще можно черпать вдохновение? 
Прежде всего, могу порекомендовать отличный документ AN82156 Проектирование компонентов PSoC Creator с путями к данным UDB .
В нем вы найдете типовые решения, а также несколько типовых проектов.
При этом в начале документа разработка ведется с помощью UDB Editor, а ближе к концу — с помощью Datapath Config Tool, то есть документ охватывает все аспекты разработки.
Но, к сожалению, глядя на цену одного чипа PSoC, я бы сказал, что если он может решить только проблемы, описанные в этом документе, то цена контроллера сильно завышена.
ШИМ и стандартные последовательные порты могут быть изготовлены без PSoC. К счастью, круг задач, решаемых PSoC, гораздо шире.
Поэтому дочитав AN82156, начинаем искать другие источники вдохновения.
Следующий полезный источник — примеры, поставляемые с PSoC Creator. Я уже упоминал о них в примечании к одной из частей перевода документации компании (см.
Здесь ).
Они хранятся примерно здесь (диск может отличаться): E:\Program Files (x86)\Cypress\PSoC Creator\4.2\PSoC Creator\psoc\content\CyComponentLibrary. Вам следует искать файлы *.
v, то есть тексты verilog, или *.
vhd, поскольку синтаксис языка VHDL требует немного большего описания, и в этом языке иногда можно найти интересные нюансы, скрытые от глаз Verilog. программист. Беда в том, что это не примеры, а готовые решения.
Это здорово, они отлично отлажены, но у нас, обычных программистов, и у программистов Cypress разные цели.
Наша задача — за короткий промежуток времени сделать что-то вспомогательное, а затем начать использовать это в своих проектах, на которые будет потрачена основная часть нашего времени.
Он в идеале должен решать задачи, поставленные перед нами сегодня, и если завтра мы захотим вставить тот же код в другой проект, где все будет немного по-другому, то завтра мы доработаем его под эту ситуацию.
Для разработчиков Cypress компонент является конечным продуктом, поэтому они могут тратить на него большую часть своего времени.
И они должны предусмотреть всё-всё-всё.
Поэтому, когда я посмотрел на эти тексты, мне стало грустно.
Они слишком сложны для тех, кто только начал искать вдохновение для своих первых проектов.
А вот в качестве справочников эти тексты вполне подходят. Они содержат множество ценных структур, которые нужны при создании собственных вещей.
Там тоже есть очень интересные уголки.
Например, есть, сейчас я скажу в стиле «масло-масло», модели для лепки (давно один суровый преподаватель отговаривал меня переводить симуляцию как нечто иное, чем «симуляция»).
Их можно найти в каталоге E:\Program Files (x86)\Cypress\PSoC Creator\4.2\PSoC Creator\warp\lib\sim. Самый интересный каталог для программиста Verilog: E:\Program Files (x86)\Cypress\PSoC Creator\4.2\PSoC Creator\warp\lib\sim\presynth\vlg. Описание компонентов в документации хорошее.
А вот поведенческие модели для всех стандартных компонентов описаны здесь.
Иногда это лучше, чем документация (которая написана тяжелым языком и в ней отсутствуют некоторые существенные детали).
Когда непонятно поведение того или иного компонента, стоит начать пытаться разобраться в нем, просматривая файлы из этого каталога.
Сначала я пробовал искать в Гугле, но очень часто на найденных мною форумах находил только домыслы и никакой конкретики.
Здесь есть конкретика.
Но тем не менее справочник – это прекрасно, но где искать учебник, чему учиться? Честно говоря, ничего особенного.
Хороших готовых примеров для UDB Editor очень мало.
Мне ужасно повезло, что когда я вдруг решил поиграться с RGB-светодиодами, я наткнулся на красивый пример специально для UDB Editor (о нем я писал в статья , с чего начался весь цикл).
Но если вы много работаете поисковиком, вы все равно найдете примеры для Datapath Config Tool, поэтому я и сделал предыдущая статья чтобы все поняли, как пользоваться этим инструментом.
И находится замечательная страница, на которой собрано множество примеров.
здесь .
Эта страница содержит разработки, сделанные сторонними разработчиками, но проверенные Cypress. То есть именно то, что нам нужно: мы тоже сторонние разработчики, но хотим учиться на том, что точно проверено.
Давайте посмотрим на пример, который привел меня на эту страницу: аппаратный калькулятор квадратного корня.
Конечные пользователи включают его в путь обработки сигнала, добавляя компонент в схему.
На этом примере мы научимся анализировать такой код, и тогда каждый сможет отправиться в путь самостоятельно.
Итак, необходимый пример можно скачать с сайта связь .
Давайте рассмотрим это.
Там есть примеры (которые каждый рассмотрит самостоятельно) и есть библиотеки, расположенные в каталоге \CJCU_SquareRoot\Library\CJCU_SquareRoot.cylib. Для каждого типа (целочисленного или с фиксированной запятой) и для каждой разрядности существует свое решение.
Мы должны это отметить.
Универсальность хороша при разработке в UDB Editor, но при разработке с использованием Datapath Edit Tool, как мы видим, люди так страдают. Не беспокойтесь, если вы не достигнете универсального успеха (но если вы добьетесь успеха, тем лучше).
На верхнем уровне (схемотехнике) останавливаться не буду, так как мы изучаем не работу с PSoC, а работу с UDB. Рассмотрим вариант средней сложности — 16 битный, но целочисленный.
Он находится в каталоге CJCU_B_Isqrt16_v1_0. Первое, что необходимо сделать, это открыть граф переходов микропрограммного автомата.
Без него мы даже не догадаемся, какой алгоритм вычисления квадратного корня использовался, поскольку Google предлагает на выбор несколько принципиально разных алгоритмов.
Пока ничего не ясно, но это предсказуемо.
Необходимо добавить дополнительную информацию.
Давайте посмотрим на государственное кодирование.
Поразительно, что они не закодированы обычным инкрементным двоичным кодом.
Я уже упоминал этот подход в своих статьях, но никогда не использовал его в конкретных примерах.
Напомню, что оперативная память динамической конфигурации АЛУ имеет всего три адресных входа.
То есть АЛУ может выполнять одну из восьми операций.
Если у машины больше состояний, то правило «для каждого состояния своя операция» становится невозможным.
Поэтому выбираются состояния, в которых операции для АЛУ идентичны; в них три бита, подаваемые по адресу оперативной памяти динамической конфигурации (обычно младшие), кодируются одинаково, а остальные кодируются по-разному.
Как разложить такой пасьянс – проблема разработчика.
Разработчики изучаемого кода собрали его именно так, как показано выше.
Добавим эту информацию на график, а также раскрасим в похожие цвета состояния, выполняющие в АЛУ одну и ту же функцию.
Никаких закономерностей пока не выявилось, но мы продолжаем открывать график.
Откройте инструмент редактирования Datapath и изучите уже содержащуюся в нем логику.
Обратите внимание, что у нас есть два блока Datapath, соединенные в цепочку.
Когда мы делаем что-то своё, нам тоже может понадобиться это (хотя Datapath Edit Tool может создавать уже сцепленные блоки, так что это не страшно): 
При чтении (и даже при заполнении) графиков, соответствующих АЛУ, мы всегда открываем документ со следующей картинкой: 
Правда, разработчики этого примера позаботились о нас и заполнили поля для комментариев.
Теперь мы можем использовать их, чтобы понять, что для чего настроено.
При этом отметим для себя, что написание комментариев всегда полезно как для тех, кто будет поддерживать код, так и для нас, когда через полгода мы все о нем забудем.
Смотрим на код X000, соответствующий состояниям 0 и 12:
Из комментария уже понятно что к чему (содержимое регистра D0 копируется в регистр А0, а содержимое D1 копируется в регистр А1. Зная это, тренируем свою интуицию на будущее и находим аналогичную запись в полях настроек : 
Там мы видим, что АЛУ работает в режиме ПРОХОДИТЬ , сдвиговый регистр тоже ПРОХОДИТЬ , поэтому никаких других действий фактически не выполняется.
Попутно заглядываем в текст Verilog и видим там, чему равно значение регистров D0 и D1: 
При желании то же самое можно просмотреть в Datapath Config Tool, выбрав меню View-> Initial Register Values: 
Для его просмотра удобнее напрямую анализировать код Verilog; для создания своей версии работайте через редактор, чтобы не держать синтаксис в голове.
Давайте аналогичным образом посмотрим на все остальные функции ALU (предварительно глядя на комментарии): 
Перерабатываем граф переходов машины с учетом новых знаний: 
Что-то уже вырисовывается, но я пока не могу с уверенностью поместить на этот график ни один из алгоритмов, найденных Google. Вернее, о некоторых мы можем с уверенностью сказать, что это не они, но даже по вполне правдоподобным я все же не могу дать уверенный ответ, что это они.
Активное использование регистров FIFO F0 и F1 сбивает с толку.
Собственно, в файле
\CJCU_SquareRoot\Library\CJCU_SquareRoot.cylib\CJCU_Isqrt_v1_0\API\CJCU_Isqrt.c
Вы можете видеть, что F1 используется для передачи аргумента и возврата результата: 
Тот же текст:
Теги: #Программирование микроконтроллеров #Компьютерное оборудование #микроконтроллеры #Системное программирование #PSoC #UDB #UDBvoid `$INSTANCE_NAME`_ComputeIsqrtAsync(uint`$regWidth` square) {
-
Немного О Smart И Утилитах Мониторинга
19 Oct, 24 -
Облачные Сервисы Oracle Для Ит-Мониторинга
19 Oct, 24 -
Эксперименты Над Олимпиадной Задачей.
19 Oct, 24 -
Рефлог Github V1.5.16
19 Oct, 24
