USB-polygon-3: Первое включение

Включение и опознание

Плата смонтирована и проверена «на дым». Дым при включении не пошел, компьютер тоже не сгорел. Плата работает, правда, определяется как неизвестное устройство.

Контроллер для платы выбирался специально с таким расчетом, чтобы программировать без программатора, непосредственно через USB-порт. Пришло время проверить, как устройство готово к этой процедуре. С сайта Atmel скачиваю программу FLIP, устанавливаю ее. Для скачивания, правда, придется зарегистрироваться, но регистрация очень простая, никаких особенных данных не просят. Есть варианты для Windows (работает и в 7, и в ХР) и Linux (проверил в Debian).

Если на компьютере с Windows не установлена виртуальная машина Java, то надо выбрать дистрибутив FLIP, в который включена JRE.

После установки FLIP в Windows на запрос драйвера после подключения платы нужно указать его местоположение в районе C:\Program Files\Atmel\Flip 3.4.7\usb (для Windows XP):

Теперь устройство (чистое и непрошитое) будет определяться системой:

И открываться в FLIP даже без нажатий на кнопку HWB на плате.

И вот FLIP запущен, устройство подключено, обнаружено и открыто, хотелось бы что-то туда прошить. Но что?!

Проверка работоспособности платы

Компилятор для начала

Готовых прошивок для моей платы нет, разумеется. Надо написать для начала что-то совсем примитивное, помигать светодиодами. Просто убедиться, что плата прошивается и включается. Пришла пора выбора инструмента. Желательно что-то простое, даже консольное. В идеале — кроссплатформенное. Первое, что приходит в голову для AVR — Atmel Studio, но в плане простоты это перебор, а в плане кроссплатформенности — недобор.

Неглубоко порывшись в интернетах, нашел упоминание о таком пакете, как WinAVR. Весит немного, устанавливается элементарно. Содержит в себе ряд утилит командной строки, обычно имеющихся в дистрибутивах Linux (cat, cmp, find, make, grep, gzip, less, sed и еще кое-что). Включает в себя и командную оболочку sh. Помимо компилятора имеется и подборка заголовочных файлов на разные случаи жизни, с мнемоникой для аппаратной составляющей разных контроллеров и с полезными функциями (типа crc16 или delay), которые можно использовать в своих проектах. В комплект входит еще и текстовый редактор Programmer`s notepad, который для небольших самоделок может вполне сойти за IDE, но я им не пользовался, попробовал только разик.

Установил, настроил (в смысле, прописал в системной переменной PATH пути к папкам avr, bin и util\bin).

Программа для проверки

Написал примитивнейший код на С в файле test.c:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

#include <avr/io.h>
#include <util/delay.h>

int main(void)
{
    PORTD = 0x00; /* инициализация порта со светодиодами */
    DDRD = 0xFF;  /* назначение порта на выход */
    char cnt = 0; /* инициализация счетчика */

    while (1)
    {
        cnt++;
        PORTD = cnt;
        _delay_ms(10); /* использование библиотечной функции задержки */
    }
}

Теперь его бы как-то подготовить для прошивки… WinAVR рассчитан в первую очередь на работу с Makefile. И хотелось бы заготовку какую-нибудь, потому что стряпать этот файл самостоятельно, конечно, можно, но тогда надо вникать в работу компилятора хотя бы в общих чертах. А мне бы это попозже, мне бы светодиодиком моргнуть сначала…

Короче, нашел заготовку Makefile в книжке «Программирование на языке С для AVR и PIC микроконтроллеров. Изд. 2-е, переработанное и дополненное» Ю. А. Шпак, 2011. В этой книге кроме прочего в общих чертах описана работа с WinAVR, а в файлах на компакт-диске есть несколько проектов, заточенных именно под WinAVR, с Makefile в составе. Правда, позже обнаружил, что пример Makefile есть в составе WinAVR, в папке sample. А еще где-то там есть мастер создания Makefile, но с этим я уже не стал заморачиваться.

Компиляция и первые вопросы

Поправил Makefile под свои цели, то есть, MCU присвоил значение at90usb162, F_CPU = 8000000, TARGET = test. Запустил make, получил hex-файл. Ну, не только hex, там много чего появилось, но для FLIP мне нужен hex.

Make запускал не заморачиваясь из файлового менеджера Unreal commander. Логичнее было бы использовать консольный, типа FAR, но этот был уже открыт. Для того, чтобы консольное окно не закрылось, отработав, команду make запускал с зажатой клавишей Shift. Получилось так:

Выдача результата весьма информативна в плане человекочитаемости — за это спасибо Makefile. Можно также запустить make clean, эта команда сотрет все, что наделал make:

А если запустить make вторично без clean, то получим такой вывод:

Здесь видно, что компиляции никакой не делалось, потому что незачем, зато есть размер программы до компиляции и после, что позволит сравнить, скажем, занимаемую в кристалле память при внесении изменений в код программы.

В программе FLIP открыл полученный hex, запустил прошивку кнопкой RUN. Кнопкой Start Application запустил выполнение. Получилась ерунда какая-то: светодиод PD0 моргает, остальные — не горят. Нажал кнопку Reset, не помогло. Отключил плату от USB, включил снова — ура, заработало! Пока не понял, в чем дело, может, по каким-то причинам контроллер сбрасывается. Предположил, что из-за сторожевого таймера.

Про наличие сторожевого таймера в контроллере я в курсе, а как с ним работать — пока нет. Думал, что он по умолчанию отключен, но пока не буду читать описание на эту тему, сделаю проще. Нашел готовый проект на основе такого контроллера и посмотрел, как этот таймер обездвижить, не вдаваясь в подробности. Добавил в программу

#include <avr/wdt.h>

и в самое начало функции main() еще три строчки:

    /* Disable watchdog if enabled by bootloader/fuses */
    MCUSR &= ~(1 << WDRF);
    wdt_disable();

Помогло! Теперь счетчик стал моргать и после запуска программы кнопкой в окне FLIP, и кнопкой Reset на плате.

Немножко побаловался, подключая и отключая плату по USB, понажимал кнопку Reset на плате, попробовал вводить в режим программирования комбинацией кнопок Reset и HWB. Покуражился и над программой — накладывал на счетчик битовые маски, выводил фиксированные числа. Пока что все получается.

Надо сказать, код еще маленький, а уже красотой не блещет. Работа со сторожевым таймером не отлажена и сделана без понимания, для задержки используется довольно корявая библиотечная функция, неоправданно кушающая ресурсы. Но я не заморачиваюсь пока что. Основную свою цель код выполняет — работоспособность контроллера и платы проверена. А потом я не буду расширять возможности именно этой программы, а напишу более приличную или возьму чужую заготовку и переделаю под свои нужды. В любом случае, оттачивать эту времянку смысла нет.

Выбор компилятора

Можно продолжить работу, написать что-то более интересное. Но немного смущает тот факт, что у WinAVR последняя активность автора проекта проявлялась довольно давно. Если проект заброшен, то не хотелось бы начинать с его использования, так как если вдруг начнет получаться что-то более-менее серьезное, потом могут появиться проблемы при необходимости перевода на другой более современный и развитый инструмент компиляции и сборки.

Кроме того, WinAVR — это, все-таки, для Windows, поэтому надо как минимум найти аналог для Linux, точнее наоборот — то в Linux, из чего сделали этот аналог (потому как основой является gcc и ряд линуксовых утилит). А еще лучше найти нечто кроссплатформенное, чтобы проекты (те же Makefile) можно было перемещать между системами без правок.

Стал копать в этом направлении. Накопал, что автор WinAVR работает теперь в Atmel в этом же направлении, над компилятором, входящим в состав Atmel Studio, а также доступным отдельно в виде Atmel AVR Toolchain for Windows и for Linux

Казалось бы, Atmel AVR Toolchain и WinAVR — это одно и то же, тем более, что от того же автора. Однако есть заметные отличия:

• В WinAVR входят утилиты для AVR и AVR32, а в Toolchain это разные комплекты;
• В Toolchain нет своего редактора, типа Programmer`s notepad, что само по себе не страшно, нормальных редакторов для написания кода навалом, предпочитаю VIM;
• В WinAVR есть папка sample, а в Toolchain только примеры, запрятанные в папке doc (которая есть и в WinAVR);
• Самое неприятное — в Toolchain нет папки utils, в которой есть командная оболочка sh. Значит, придется еще поставить линуксообразную среду, типа cygwin или mingw.

Наверняка можно переделать Makefile таким образом, чтобы компиляция запускалась с использованием командной оболочки Windows. Однако так получилось, что cygwin у меня уже имеется, было нужно раньше по другим причинам. Опять же, Makefile пришлось бы делать разные для разных типов операционных систем.

Cygwin, повторюсь, у меня установлен, причем, в довольно таки полной комплектации — довольно много выбрано пунктов в основном разделе, разделах разработки и отладки, практически все системные утилиты и, конечно, vim. В подробности установки вдаваться не буду, это отдельная тема.

Запустил терминал, добавил в настройках bash добавку к системной переменной PATH — путь к Atmel AVR Toolchain:

Заодно добавил HISTCONTROL для удобства. Запустил для пробы make clean:

Ну, и для гарании — make:

Как видно, результаты идентичные с WinAVR. При этом не пришлось трогать Makefile, и проект работоспособен в разных вариантах Windows (при установленном cygwin) и в Linux. WinAVR можно удалять. Atmel AVR Toolchain при желании можно позднее прикрутить к какой-нибудь среде, или к Atmel Studio, или (для пущей кроссплатформенности) к Eclipse, но пока вполне достаточно консоли. Для навигации по файлам проекта — любой файловый менеджер (у меня Unreal Commander), для написания/редактирования текста программ — любой текстовый редактор (у меня GVIM for Windows) и для компиляции — make в консоли cygwin. Пока что достаточно, а там видно будет.

Итог

Устройство работоспособно, определяется, прошивается, запускается и сбрасывается. Инструмент выбран и худо-бедно настроен.

В общем, все заработало, и можно приступать к чему-то более интересному, чем моргание светодиодиком. По крайней мере, хотя бы управляемое моргание. А уж больше всего хочется связаться с компьютером по USB и передавать туда-сюда какие-нибудь пакеты каких-нибудь данных. Но это уже другая история.