Микроконтроллеры AVR

Философские размышления над программатором :-) http://www.terraelectronica.ru/catalog_info.php?ID=844&CODE=288839&Name=AVR-USB-162&Razdel=Демонстрационные%20и%20оценочные%20платы%20для%20МК%20семейства%20AVR&TableName=class_19_2_26_1
Не пускаясь в советы, как ReAl'у делать свой программатор, отмечу вещи, заметные мне как программисту, но, возможно, не всегда видимые глазом эмбендера. Главное звено, из которого следует большинство трудностей, - это принципиальная невозможность обеспечить синхронный режим вывода данных на компьютерах современного поколения. Речь идет не о той синхронности, которая входит в обеспечение протоколов обмена, синхронизирующих передачу с несущей частотой или клок-стробом, а той синхронности, когда "дергание ножкой" (портом) центрального процессора мгновенно откликается на периферии. Когда процессоры у компьютеров были медленные (старые образцы 386 и 486) синхронный обмен с периферией отлично работал. С появлением Pentium появилась необходимость либо "прореживания" передачи, что в общем-то решалось низкой частотой шины относительно рабочей частоты ЦПУ. Но на нынешних частотах обеспечить тотальную синхронность нет никакой. Вытеснение интерфейсом USB таких портов, как LPT и (стандартный) COM, произошло не от того, что USB так уж хорош или быстр, а в первую очередь потому, что этот интерфейс асинхронный! Образно говоря, смена дня и ночи (тактовая частота) стала происходит настолько часто, что почтовая служба уже не может гарантировать доставку корреспонденции на следующий день. Да и вообще, не может заранее указать время доставки. В этой ситуации мы кидаем письмо (байт) в почтовый ящик, а дальше остается лишь молиться за то, чтобы он скорее дошел до адресата. И даже если мы опустили в почтовый ящик два письма с интервалом в один час, то это совершенно не значит, что адресат получит их с тем же интервалом. Скорее всего он получит их либо вместе сразу, или же с интервалом в сутки или более. Теперь представим себе ситуацию, что мы что-то программируем на расстоянии. Например, ... варим борщ :-) во Владивостоке, управляя процессом варки из Киева. Вот мы послали депешу почистить овощи. Потом депешу порезать их и засыпать в кипяток. Путь на этих стадиях имеются неизбежные задержки - для варки борща это не так уж страшно. Но представим себе, что команда снять варево с огня пришло с задержкой на двое суток! Что будет с борщем? - Все, нафиг, выкипит досуха и сгорит. Указанная проблема имеет прямое отношение не только к прошивке МК, то и процедурам типа записи на CD/DVD-ROM. Как же решается эта проблема по отношению к записи на диск? - А очень просто! - Наличием некоторого внутреннего буфера у записывающего устройства (это не исключает наличие еще и внешнего буфера на стороне компьютера), которое в состоянии удержать в себе информацию на полный сектор/трек диска. Прожиг сектора не начнется раньше того, пока не поступит ВСЯ информация для данного сектора. Тут дело ясное - опоздает к прожигу хотя бы один байт - вся запись будет загублена (а то и вся болванка, если диск одноразовой записи). А теперь представим, что мы уже прожигаем МК по USB-каналу, не имея всех данных для полной прошивки, и в это момент какой-нибудь антивирус входит в критическую секцию в нулевом кольце защиты (уровне драйверов системы), например, с целью проверить Кernel32.dll :-). Все другие драйверы при этом впадут в паузу, не получая процессорного времени. Интервал следования USB-пакетов затянется. Ясны последствия? Впрочем внимательные люди, вероятно, замечали переполнение внутренних буферов системы при чтении приложением данных из COM-порта, когда ... долго держится нажатой кнопка на мыши. Приведенный выше пример подобен этой ситуации. Теперь вернемся к варке борща во Владивостоке по киевскому рецепту :-). Так ли уж безнадежна ситуация? Оказывается варить борщ по удаленным рецептам вполне можно, но для этого нужно скачать весь рецепт ЦЕЛИКОМ, и уж только после этого приступать к процессу варки, не будучи более связанными внешними инструкциями. Это очень похоже на обеспечение прожига DVD-ROMа в условиях асинхронности. Рассматривая с этих позиций программатор, мы понимаем, что для идеальной работы он должен обладать уровнем САМОСТОЯТЕЛЬНОСТИ, допускающим прошивку без участия внешних синхронных инструкций. Это, однако, не значит, что программатор должен быть таким умным, чтобы знать, как прошивается тот или иной МК. Однако он все-таки должен обладать "интеллектом", достаточным для обеспечения прошивки по ранее полученным и запомненным параметрам. Например, программатору передается значение рабочей частоты + номер протокола (если таких способов несколько - например, высокий или низкий RESЕT нужно держать во время прошивки), величину пауз между шагами и т.п. А дальше программатор САМ синхронизируется с частотой кварца программируемого МК и, тупо следуя заранее полученной инструкции, его прошивает. При этом сама прошивка программатора не содержит в себе секретов прошивки конкретных МК, т.к. каждый раз получает параметры on-line. Образно говоря, программатор, чтобы варить борщи по иноземным рецептам, должен уметь выполнять основные поварские операции, особенно типа "варить втечение чч:мм времени". Тогда он не загубит борщ из-за задержки в следующей инструкции. А сами инструкции должны быть таковы, чтобы допускать их исполнение в асинхронном варианте! Т.е. задержки между инструкциями не должны приводить к порче дела. Глядючи на эти задачи, становится сомнительным, чтобы узко специализированная микруха типа FT2232D могла в полном объеме отвечать поставленным требованиям. В этом смысле leon_ прав - использование в программаторе МК общего назначения (а еще лучше - программируемого контроллера) полностью решило бы поставленную задачу. А вопрос о прошивке такого программатора решается достаточно просто - его можно прошить старым способом через LPT-порт старого компьютера. Для этих целей, скорее всего, годится демо-плата на 90USB162 (AVR-USB-162 по цене $40) - см. ссылку.