Загрузка конфигурации в ПЛИС через USB или разбираем FTDI MPSSE
Пишем загрузчик ПЛИС в LabVIEW. Часть 1

В первой статье мы обкатали алгоритм загрузки на старом добром Си, во второй статье разобрались, как в LabVIEW можно организовать программу и реализовать простой интерфейс пользователя. В этот раз мы познакомимся с новыми приемами работы в LabVIEW, разберем особенности обработки ошибок и завершим проект: реализуем протокол загрузки файла конфигурации в ПЛИС.

У большинства "нормальных" программистов, мягко говоря, неоднозначное отношение к технологии LabVIEW. Тут спорить можно долго и безрезультатно. Ситуацию усугубляет то, что в сети масса примеров программ на LabVIEW, но все они ориентированы на новичка и сводятся к "ой, смотрите как все просто, соединил крутилку с индикатором, кручу ручку, меняется циферка", или в лучшем случае на график в цикле выводится случайное число или синус, все это сопровождается зубодробительным интерфейсом в виде гигантских тумблеров, крутилок и стрелочных индикаторов. Лично меня такой подход сознательного упрощения раздражает. В небольшом цикле статей я постараюсь познакомить читателя с процессом разработки прикладного ПО на LabVIEW. Для того, чтобы не уделять много времени предметной области, воспользуемся подробно описанным алгоритмом загрузки файла конфигурации в ПЛИС через FTDI в режиме MPSSE (Загрузка конфигурации в ПЛИС через USB или разбираем FTDI MPSSE). В этой статье я покажу как реализовать такой же загрузчик ПЛИС, но на языке LabVIEW.

В жизни каждого плисовода наступает момент, когда требуется написать собственный загрузчик файла конфигурации в ПЛИС. Пришлось мне участвовать в разработке учебного стенда для кафедры одного технического вуза. Стенд предназначен для изучения цифровой обработки сигналов, хотя в рамках этой статьи это не имеет особого значения. А значение имеет то, что в основе стенда стоит ПЛИС (Altera Cyclone IV), на которой по задумке автора стенда студенты собирают всякие схемы ЦОС. Стенд подключается к компьютеру через USB. Требуется выполнить загрузку ПЛИС с компьютера через USB.

Принято решение для подключения к ПК использовать FTDI в ее двухканальной ипостаси — FT2232H. Один канал будет использован для конфигурации ПЛИС, другой может быть использован для высокоскоростного обмена в режиме FIFO.

Широко известный в узких кругах легковесный менеджер пакетов opkg получил распространение в embedded Linux не случайно. Opkg используется во многих встраиваемых дистрибутивах и проектах, например, в OpenEmbedded, Yocto Project, OpenWRT, Ångström, Arago Project и некоторых других. Менеджер прост в эксплуатации, для полноценной работы вполне достаточно встроенной справки, а на просторах всемирной паутины множество статей о том, как устроен сам пакет ipk (opkg работает с таким форматом): как его создать, как установить и т.д и т.п. Однако подавляющее большинство информации посвящено тому, как работать на уже установленной на целевую платформу (target) системе в online-режиме, но специфика Embedded подразумевает, что образ корневой файловой системы, а также ядро готовятся заранее на некоторой инструментальной платформе (host), отличной от целевой. Иными словами, собираем ядро и файловую систему на рабочем компьютере, упаковываем в образ, образ тиражируем на железо. Эта статья посвящена тому, как с помощью менеджера opkg установить пакеты в подготавливаемый образ rootfs.

Год назад выполнял довольно интересную работу по разработке встраиваемого компьютера для одного предприятия, занимающегося электроникой. Компьютер ничего принципиально интересного не представлял: процессор Cortex A-8, работающий на субгигагерцовых частотах, 512Mb DDR3, 1Gb NAND, легковесная сборка Linux. Однако устройству, в который компьютер встраивался, а значит и ему самому, предстояло работать в довольно жестких условиях. Широкий температурный диапазон (от -40 до +85 градусов Цельсия), влагостойкость, стойкость к электромагнитным излучениям, киловольтные импульсы по питанию, защита от статики в 4 кВ и много чего интересного, что хорошо описано в различных ГОСТах на спецтехнику, – это все про него. Одно из основных требований заказчика – срок выработки на отказ не менее 10 лет. При этом производитель обеспечивает гарантийный ремонт изделия в течении пяти лет, потому вопрос не риторический, а денежный и серьезный. В изделие была заложена соответствующая элементная база. Прибор с честью прошел испытания и получил требуемые сертификаты, но разговор не про то. Проблемы начались когда была изготовлена установочная партия, и устройства разошлись по отделам и КБ для создания прикладного ПО. Пошли возвраты с формулировкой: «Чего-то не загружается».