Очень часто в условиях жёсткой конкуренции сроки изготовления рабочего образца изделия очень малы. А времени для полноценного тестирования и отладки, поиска слабых мест почти не остаётся. И всё это на фоне возрастающей сложности как электронной части, так и программной. В связи с этим, в данное время практически все электронные устройства, имеющие в своём составе программируемые элементы (процессоры, микроконтроллеры, ПЛИС, DSP), позволяют изменять своё программное обеспечение непосредственно самим пользователем, без каких-либо сложных манипуляций и наличия технологической аппаратуры. В крайнем случае, может понадобиться специальное технологическое программное обеспечение, но это всё же лучше, чем необходимость использования специализированных программаторов, кабелей и наличия навыков, необходимых знаний в этой области. Существует множество способов обновления программного обеспечения, именуемого "прошивкой", в конечном рабочем изделии. В моём роутере, например, достаточно просто через WEB-интерфейс выбрать файл новой прошивки и нажать одну кнопку. Всё интуитивно понятно, легко и просто.

Как-то возникла задача сделать нечно подобное. Пойти по примеру производителей роутера - затруднительно, ввиду того, что они используют встроенную операционную систему, WEB-сервер, FTP-сервер. Естесственно, что это более красивое решение требует гораздо больших ресурсов для разработки "с нуля". Так что, эту идею пришлось оставить на обозримое будущее, которое, надеюсь, наступит. Более простым решением показалось задействовать штатный интерфейс RS-485. Данный интерфейс уже использовался для управления и отладки программного обеспечения, изменения параметров устройства. Осталось ещё возложить на него функции по обновлению программного обеспечения. Для этого необходимо доработать как встроенное программное обеспечение, так и управляющую программу для компьютера или написать отдельную.

Требования, предъявляемые к системе обновления ПО стандартные - простота со стороны пользователя, надёжность, защита от неудачного обновления и откат к предыдущей рабочей версии ПО. В устройстве используется ПЛИС фирмы Altera. А именно - Stratix II. Данное семейство ПЛИС поддерживает Remote System Upgrade на аппаратном уровне, а это означает, что должно быть меньше мороки с защитой от неудачного обновления и откатом к рабочей версии встроенного ПО.

Немного о структуре встроенного программного обеспечения. Для обработки поступающих команд в изделии используется встроенный 32-битный процессор NIOS. Операционная система отсутствует, сама программа для NIOS написана на языке C. Неплохой набор для старта. В программном обеспечении уже реализовано чтение и запись блоков данных произвольной длины по произвольным адресам в оперативной памяти DDR SDRAM. Кроме этого, реализована команда копирования блока данных произвольной длины из памяти DDR SDRAM по заданному адресу в память конфигуратора EPCS64, где и хранится конфигурация ПЛИС и программа процессора NIOS. Конфигурационные данные располагаются в самом начале адресного пространства конфигуратора EPCS64, то есть, начиная с нулевого адреса. Программа для процессора хранится непосредственно после конфигурационных данных. Память же самого конфигуратора разбита на страницы. В разных страницах можно хранить различные варианты конфигурационных данных и откомпилированной программы процессора NIOS. Подробнее о переключении страниц и вариантах загрузки из конфигуратора можно узнать из "Описание мегафункции ALTREMOTE_UPDATE". В данном применеии нам не требуется высокой скорости конфигурирования ПЛИС (быстрого включения), поэтому вполне может подойти режим дистанционного конфигурирования. В этом режиме вначале загружается прошивка с нулевой страницы (базовая прошивка), которая позволяет загрузить любую другую прошивку с любой другой страницы, предварительно проверить её корректность, а также выполнить обновление прошивки до более новой версии. В случае неуспешного конфигурирования "рабочей прошивкой" можно всегда вернуться к "базовой прошивке" на странице 0.

Что же из себя должна представлять "базовая конфигурация", находящаяся на странице 0 конфигуратора? Тут может быть несколько вариантов, рассмотрим 2 из них.

• Вариант 1
  Базовая конфигурация выполняет только сервисные функции - проверка и обновление прошивки, выбор и загрузку необходимой конфигурации из имеющихся. В данном случае базовая конфигурация по своей структуре будет отличаться от основной "рабочей" конфигурации. В данном случае кроме базовой конфигурации необходимо иметь рабочую конфигурацию, не доступную для изменеия извне по интерфейсу обновления встроенного ПО. Это необходимо для того, чтобы в случае некорректного обновления рабочей конфигурации, можно было бы всегда вернуться к предыдущей заведомо рабочей конфигурации, которая всегда хранится в неизменном виде и гарантирует работоспособность изделия. Подводя итог, можно отметить, что обязательно потребуется одна сервисная базовая конфигурация, одна рабочая базовая конфигурация и отдельная новая рабочая конфигурация, которой может и не быть (в этом случае будет использована рабочая базовая конфигурация).
• Вариант 2
  Базовая конфигурация представляет собой обычную рабочую конфигурацию, выполняющую все необходимые функции "рабочей" конфигурации и сервисные функции проверки, обновления прошивки, выбора и загрузки более новой конфигурации. В данном случае отпадает необходимость кроме базовой конфигурации на странице 0 иметь дополнительную рабочую конфигурацию, не доступную для модификации извне по интерфейсу обновления встроенного ПО. Данную функцию будет выполнять всё та же базовая конфигурация. Более того, более новая рабочая конфигурация может быть полностью идентичной базовой конфигурации, то есть, отпадает необходимость разрабатывать несколько конфигураций для одного изделия.

Учитывая данные особенности рассмотренных вариантов, был выбран вариант 2, как более технологичный, универсальный и экономный.

• Формат данных
• Аппаратная реализация
• Подключение ALTREMOTE_UPDATE к NIOS
• Программная реализация
• Текст программы драйвера с примерами использования на языке С