USB-polygon-14: работа в Linux
Лирическое отступление
Вопрос, описываемый в этом выпуске, не имеет прямого отношения к развитию проекта. Однако в соответствии с ТЗ, приведенном в первом выпуске, проект должен быть по возможности кроссплатформенным. До сих пор кроссплатформенность проверялась только в разных Windows, что несерьезно.
Добравшись до попытки отладки записи в устройство, имитирующее FAT32, я решил проверить отличия работы с устройством в Linux. Тут меня ждал сюрприз: автоопределение «флэшки» не сработало. Причем, флэшка в системе как бы присутствует, вот вывод fdisk -l:
Disk /dev/sdg: 8 MiB, 8388608 bytes, 16384 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
/dev/sdg1 62 4157 4096 2M c W95 FAT32 (LBA)
А попытка монтирования вручную выдала ошибку:
mount: wrong fs type, bad option, bad superblock on /dev/sdg1,
missing codepage or helper program, or other error
В конце концов причина обнаружилась в полях загрузочной записи раздела, по смещению 30h (Номер сектора структуры FSINFO) и по смещению 32h (Номер сектора - копии загрузочного). Пришлось внести некоторые поправки в написанное ранее. Но дело не в этом.
Раз есть отличия в поведении устройства (читай — программы устройства) в разных ОС, значит, надо как-то ликвидировать эту разницу. Проверять придется в той системе, в которой работает не так, как ожидается, то есть, в Linux. При этом до сих пор написание, компиляция и прошивка велись в Windows (преимущественно 7). Значит, следует отладить написание, компиляцию и прошивку в Linux — не перезагружаться же теперь каждый раз!
Написание и компиляция
Про инструмент для написания кода даже писать не интересно. Это может быть абсолютно любой редактор простого текста, plain text editor. В моем случае это VIM, с идентичными настройками в обоих семействах ОС, так что отличий практически нет. Основное отличие связано с тем, что в Windows компилировать приходится с использованием Cygwin, поэтому настраивать компиляцию прямо в VIM чуть сложнее, чем в Linux, где это сделано практически «из коробки». Все остальное одинаково.
Для компиляции в Windows, повторюсь, потребовался Cygwin (как описывал в выпуске 3), в Linux этот программный комплекс, разумеется, не нужен. Можно скачать с сайта Atmel сборку AVR Toolchain for Linux и прописать в .bashrc путь к ней в виде добавки к переменной окружения $PATH (как и в Cygwin). По идее, тогда команда make в папке проекта сделает все, что нужно.
Однако я еще при установке Debian выбрал почти все пакеты с буквосочетанием «avr» в названии, в частности, «avr-libc», «binutils-avr», <avra» и «gcc-avr». Теперь мне не нужен упомянутый пакет, make работает и так.
Прошивка
А вот с прошивкой начались сложности. Я рассчитывал на FLIP, зная, что есть версия под Linux.
Первое легкое разочарование нашел на странице продукта на сайте Atmel. Linux-версия отстает от виндовой на две минорных (3.2 1 против 3.4.7 на момент написания данного опуса), что, как бы, намекает на прекращение сопровождения. Это само по себе не вполне понятно: программа написана на java, так что должна быть существенной частью кроссплатформенной. Ну да ладно, если бы только в этом дело.
Скачал, распаковал, запустил. Точнее, попытался запустить из консоли. Получил ошибку:
FLIP_HOME is not defined, please use setenv to set flip home
e.g :
setenv FLIP_HOME /home/flip.3.2.1/bin
Ну, это нормально, об этом еще README предупреждал. Вот только не setenv надо бы, а export:
export FLIP_HOME="/home/romeogolf/coding/flip_toolchain/flip.3.2.1/bin/"
скомандовал я в консоли и повторил запуск. Тогда мне написали так:
JAVA_HOME is not defined please use setenv to set java home
e.g :
setenv JAVA_HOME /usr/java/jdk1.6.0_02/jre
Ладно, тоже ожидаемо. Пишу:
export JAVA_HOME=/usr/lib/jvm/java-8-oracle/jre/bin/
В результате после очередной попытки запуска FLIP получаю несколько больше текста:
=====================================================
JAVA_HOME = /usr/lib/jvm/java-8-oracle/jre/
=====================================================
LD_LIBRARY_PATH = /home/romeogolf/coding/flip_toolchain/flip.3.2.1/bin/:
=====================================================
PATH = /home/romeogolf/coding/flip_toolchain/flip.3.2.1/bin/:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
=====================================================
= start flip
=====================================================
=====================================================
= end flip
=====================================================
А заодно ошибка, с сообщением в длиннющем окошке во весь экран.
Выяснил, что java-программа, которой является FLIP, 32-разрядная, а в моем Debian`е установлена 64-разрядная java-машина. Скачал 32-разрядную jre с сайта Oracle, распаковал куда попало и указал переменную JAVA_HOME с путем к 32-разрядной jre:
export JAVA_HOME="/home/romeogolf/coding/jre1.8.0_131/"
Появилось такое окно с ошибкой:
Надоело, плюнул, поискал альтернативы. Первая и довольно популярная — dfu-programmer. Есть для Linux и Windows.
На странице проекта есть ссылки на репозиторий и страницу загрузки win-сборки и исходников.
Оказалось, есть этот пакет и в репозитории Debian. Утилита консольная, командной строки, в отличие от FLIP, но может ли это напугать рискнувшего работать в Linux? Установил через Synaptic. Запустил:
dfu-programmer --version
Получил в ответ:
dfu-programmer 0.6.1
хотя последняя версия на данный момент уже 0.7.2. Думаю, однако, что это не принципиально. Запустил:
dfu-programmer --targets
и нашел в появившемся списке целей свой at90usb162. Запустил для пробы команду сброса:
dfu-programmer at90usb162 reset
получил в ответ:
no device present
Разумеется, плата при этом была в сбросе: нажал «Reset», нажал «HWB», отпустил «Reset», отпустил «HWB». Немножко подумал, догадался запустить ту же команду через sudo — плата запустилась. Рискнул стереть:
dfu-programmer at90usb162 erase
Судя по всему, флэшка очищена, ибо не запускается, зато видна команде dfu-programmer без кнопки «HWB». Ну, то есть, я перезапустил кнопкой «Reset» на плате и посмотрел, что получилось. Потом опять сбросил с «HWB» и попробовал записать имеющуюся прошивку:
dfu-programmer at90usb162 flash /{...}/MassStorage.hex
Пишет в ответ, зараза:
Error while flashing
Стало грустно и непонятно. Порылся в интернетах, подумал и решил попробовать еще раз команду «flash» — заработало!!! После пары попыток обнаружил, что прошивать командой «flash» надо сразу после «erase», без промежуточных сбросов.
В общем, использовать dfu-programmer мне понравилось больше, чем FLIP. Во-первых, его проще использовать в командном режиме, стало быть, проще работать без мыши. В окне FLIP некоторые кнопки не имеют соответствующих горячих клавиш или пунктов меню, приходится хвататься за мыша. Опять же, в командах прописываются сразу все нужные параметры, типа целевого контроллера или пути к HEX-файлу, а в окне FLIP надо нажимать какие-то кнопки, искать в диалоговых окнах нужное.
Скачал win-сборку этой замечательной утилиты с драйверами в комплекте. Написал простенький CMD-файл в корне проекта с-программы для платы:
e:\{...}\dfu-programmer-win-0.7.2\dfu-programmer at90usb162 erase
e:\{...}\dfu-programmer-win-0.7.2\dfu-programmer at90usb162 flash MassStorage.hex
e:\{...}\dfu-programmer-win-0.7.2\dfu-programmer at90usb162 reset
@pause
Запуск этого файла дает такой результат:
e:\{...}\usb-polygon-embed\MassStorage>e:\{...}\dfu-programmer-win-0.7.2\dfu-programmer at90usb162 erase
Checking memory from 0x0 to 0x2FFF... Not blank at 0x1.
Erasing flash... Success
Checking memory from 0x0 to 0x2FFF... Empty.
e:\{...}\usb-polygon-embed\MassStorage>e:\{...}\dfu-programmer-win-0.7.2\dfu-programmer at90usb162 flash MassStorage.hex
Checking memory from 0x0 to 0x217F... Empty.
0% 100% Programming 0x2180 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>] Success
0% 100% Reading 0x3000 bytes...
[>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>] Success
Validating... Success
0x2180 bytes written into 0x3000 bytes memory (69.79%).
e:\{...}\usb-polygon-embed\MassStorage>e:\{...}\dfu-programmer-win-0.7.2\dfu-programmer at90usb162 reset
Для продолжения нажмите любую клавишу . . .
Очень понравилось.
Резюме
Работа с платой в Windows и в Linux стала практически идентичной, одними и теми же инструментами с одинаковыми результатами. Плата также ведет себя одинаково в обоих семействах ОС.
Софт на С++ для работы с платой, по-видимому, будет отличаться, в силу отличий API разных ОС для работы с файлами. Но с этим позже.