Еще раз об ISP и DFU.

Канва темы этой статьи витала где-то в воздухе еще до покупки Arduino UNO, и заключалась она в том что действительно интересно иметь и использовать возможность наличия в качестве преобразователя из USB в ком-порт не микросхему жесткой логики FT232R (как в старой ардуине - Duemilanove) - а еще один контроллер. Зачем? Да не важно! Просто многофункциональные и гибкие устройства это круто! Но вот появилась у меня "уна", а за ней и ее редакция R3 с контроллером mega16u2 ... А вместе с тем и понимание того, что интерфейсный контроллер, практически неподочто больше использовать то и ... почему? С одной стороны - программирование под "интерфейсный" контроллер (назовем его так) - mega8u2 (в первых двух) или mega16u2 (в третьей ревизии) - это "прощай ардуина", и переход к непосредственно средствам разработки для AVR. Т.е. по крайней мере совсем другой уровень. Но если даже и так - то какая функция будет возложена на основной контроллер ардуины? Ведь коли мы решили разобраться и попрограммить под интерфейсный контроллер ардуины (связку контроллера через USB-порт с компом) - то для этого есть уже готовые "игрушки", например такая как teensy - которая и контроллер содержит более функциональный и ноги все разведены, юзай как хочешь. Ардуиновский же интерфейсный контроллер только с редакции R2 стал иметь разведенными 4 ноги для общего использования (не густо, но хоть что-то, сначала и этого не было). Конструировать же что-то хитрое, вроде единой системы из двух "камней", сопряженных через RS232, один из которых обеспечивает протокол связи с компом (как некое специфичное устройство), а второй обрабатывает взаимодействие с железной периферией? - сложно ... зачем брать два контроллера (читай притянуть за уши ардуину) - непонятно. Проще взять один более функциональный и программить для него (опять возврат к teensy), но опять-таки теряется идея ардуины как конструктора и удобного средства разработки и отладки кода. Вот практически и приходим к тому, что наличие интерфейсного контроллера (вместо преобразователя) не оправдано ;-((

На этом я успокоился некоторое время назад ... до прочтения одной из веток официального форума (невзначай блуждая по нему). Идея иметь на ардуине еще и программатор, причем без потери основного функционала (режимы переключаются перемычкой) - показалось очень привлекательным. Нужно повторить!

На чем? Ардуины R2 (как у автора) у меня нет. Зато есть R3 (мысль о совместимости?) - но надо пробовать. Достал свою "уну", а она еще с не распаяными штырями ISP на интерфейсном контроллере ...

Дело поправимое. Резервируем прошивку (например через usbasp). Далее приходит в голову проверить работу в режиме DFU (через Flip) - как когда-то я делал с первой "уной" и описывал это ... Но нюансы не всегда документируются и иногда забываются, а порой забывается и то, что задокументировано и где, а искать, перечитывать - лень ... ну да отвлеклись. Вобщем замыкаем ресет на землю, отпускаем - и хрен! - опять видим ком-порт, и никакого DFU. К чему бы это? Чешем репу ... Потом вспоминаем что в прошлом случае паялся еще и резистор ("активирующий" DFU), переворачиваем красненькую "эртришку" - никаких площадок под резистор (как было в случае описанном в упомянутой ранее статье) - нет. Сразу не хотелось верить, что установку данного резистора (а стало быть и активацию DFU) разработчик данного клона (EKitsZone), просто не предусмотрел. С таким внимательным подходом к разработке данного "мода" ардуины, качестве исполнения - это как-то не вяжется. Но факт остается фактом. После изучения документации на контроллер mega16u2 стало ясно, что вешать на землю нужно 13-ю ногу (HWB). Благо она распаяна и участвует в схеме (на ней висит емкость к ресету основного контроллера) - соседство с землей нашлось на оборотной стороне платы, в виде двух рядом расположенных переходных отверстий.

Решено было их зачистить и запаять резистор к ним.

В целом получилось имхо изящно, и главное функционирует!

По ходу дела протестировал прошивки интерфейсного контроллера из комплекта среды ардуины (\hardware\arduino\firmwares). Подготовив пути отхода, решил испытать прошивку с функцией ISP. Конечно, несколько смущало, что она под 8u2, но успокаивало, что отличий существенных быть не должно. Короче тестим. Программатор вроде как виден ... но! Куда делся DFU?  Ищем, читаем, пробуем ... По ходу дела приходит мысль: "не плохо бы пересобрать прошивку из приложенных исходников". Тут снова траблы - ничего не собирается ... Снова тестим, читаем и снова тестим. Фишка оказывается еще и в том, что используемая библиотека LUFA должна быть не самой новой версии, а конкретной - 100807. Ладно, разобрались скомпилили, работает. И тут опять возвращаемся к DFU ... Терять ради программатора ISP режим DFU не хочется...

Короче, подытоживая: для использования DFU нужно иметь не только аппаратную составляющую (подтянутую к земле через 10к ногу HWB, и кратковременно коротнуть на землю ресет) - нужно еще предварительно записать в контроллер и загрузчик (и хранить его там). Где его взять? Куда (по каким адресам) и как записать? Как это уживается с другим кодом?

В некоторых источниках видел ссылки на бутлоадеры (и даже прямые ссылки) на сайты самого Атмела, сам линков с атмеловского сайта найти не смог. Есть еще проект LUFA - реализация DFU является его составной частью (но это нада разбираться - компилить и т.п.) Но пришла в голову более простая идея: официальная прошивка интерфейсного контроллера уже содержит нужный нам бутлоадер DFU (и даже для mega16u2) - зашиваем сею прошивку в контроллер ("дудкой", через isp и внешний программатор, например usbasp) . А далее уже через режим DFU (из под "флипа") записываем (вернее переписываем) в остальную память нужный нам "основной" код - в данном случае результат собранного проекта serial+isp. Да, все-таки "срослось", собрал я его с указанием директив кантроллера 16u2 и корректировкой идентификаторов устройства (теперь все корректно - "Arduino UNO R3"). Ну а выглядит это все достаточно скромно - в виде готового hex-файлика прошивки. Т.е. повторяется все крайне просто - любым программатором и дудкой заливается прошивка. Имеем и режим DFU (при наличии аппаратной части, см. выше) и режим программатора ISP (если установить перемычку). Режим программатора от классического режима ардины в диспетчере устройств не отличается (общаемся с ком-портом).

Ура! Результат достигнут. Имеем еще один программатор, причем абсолютно бесплатно и без потери функциональности основной ардуины (или нужды по необходимости записывать соответствующий скетч и собирать провода к соответствующему щиту). Прошивать такой ардуиной можно хоть саму себя ;-))

Напоследок приведу картинку автора проекта (из пакета) с распиновкой ног обеих разъемов ISP:

Для использования интерфейсного контроллера в качестве программатора нужно ставить перемычку на PB6-2 и PB4-2. Нога RST2 не используется (это ресет самого контроллера, нужный для его прошивки или перевода его в режим DFU). Сигнал ресет в данном "программаторе" генерируется на контакте PB7-2 - его и нужно подключать в контакту ресет программируемого контроллера (его интерфейса).

В avrdude обзываться данный интерфейс будет как "stk500v1" и в общем случае обязательными (помимо прочих) будут параметры вида:
"avrdude -cstk500v1 -PCOM<x> -b19200"

Номер порта смотрим в диспетчере устройств, там это будет просто ком-порт. Кусок лога с информацией о данном интерфейсе-программаторе выглядит так:

Programmer Type : STK500
Description : Atmel STK500 Version 1.x firmware
Hardware Version: 2
Firmware Version: 1.175
Topcard : Unknown
Vtarget : 0.0 V
Varef : 0.0 V
Oscillator : Off
SCK period : 0.1 us

Стоит отметить, что скорость работы такого интерфейса в режиме записи довольно низкая, например USBasp пишет ощутимо быстрее, хотя субъективно и он не блещет скоростными показателями. Т.е. фактически программатор на базе интерфейсного контроллера ардуины - это скорее резервный вариант, чем реальный инструмент для работы.

PS. Кстати, на волне "открытий" и экспериментов обнаружил забавный факт (иначе не скажешь). Закапризничала как-то дудка с программатором usbasp, описанном тут. Дескать, что то там бла-бла-бла с синхронизацией, не плохо бы вам обновить прошивку! А че, думаю не обновить, но сначала зарезервируюсь. Сразу не понял в чем загвоздка, потом разобрался. Китайцы установили лок-биты на контроллер (mega8L), теперь не то что не прочтешь - даже не обновишь! Это ведь надо - защищать OpenSource на копеечном железе!

PPS. Сейчас, для тех кому всеже хочется разобраться и более гибко попрограммить с "двух сторон"  от интерфейса USB, не обращаясь к проекту teensy (к которому я отсылал в ходе статьи) - есть вариант ардуины под названием Leonardo. Он содержит в себе единственный контроллер mega32u4. Он же интерфейсный (соответствующий код отнимает 4кбайта памяти) и он же распаян на классические коннекторы ардуины. Покупать Leonardo лично я смысла не вижу: он дороже teensy (сопоставим Меге-2560), а смысл? Все-таки уж давайте определяться: хотим ардуину (а основная ее цель всеже создание устройства для автономной от компа работы) - берем "мегу" или "уну". Хотим создать свое устройство на шине USB - берем teensy. Кстати под teensy уже тоже пишут в среде ардуино, но это уже другая тема.

MiGeRA (октябрь 2012)