Наваял тут программатор USB, совместимый по командам с AVR910 ISP Programmer. Довольно шустро работает и не надо драйверов, т.к CDC-класс... Если кто повторит, интересно почитать мнение

главный и жирный плюс любого программатора - поддержка производителем. у AVR910 этот плюс превратился в минус. имхо если что-то и ваять для авров то лучше клона STK500 на сегодняшний день нет . а юсб к нему прикрутить как два пальца.

Будет время, сделаю и STK500 на той же основе. Это мое первое знакомство с AVR910. Все время, пока я знаком с микроконтроллерами AVR, прошивал их с помощью самодельного STK200 на 555АП5, так как все (2) СОМ-заняты. Тут, в отпуске, решил повозиться с ПЛИС, а ей нужен байтбластер через ЛПТ, вот и решил сваять AVR910 ака USB - для дома пойдет. Правда, пришлось повозится с ассемблерным исходником AVR910 и перевести немного на Си, да полопатить даташиты на старые контроллеры , кстати 90S1200 пока мой программатор не поддерживает.На днях доделаю. Кстати, у STK500 схожий набор команд?

Если Вы собрали байтбластер, то зачем тогда какой-либо другой программатор АВРок? =) AVReal прекрасно шьёт AVR как через STK200 так и через ByteBluster'ы. Надеюсь труд будет ненапрасным =)

Так ить, мил человек, я не сказал, что я собрал байтбластер, я сказал что у мя есть собраный мною же STK200, а схема то немного разная. А поскоку припоя что на байтбластер, что на чудо техники, корое я собрал, уйдет ровно одинаково, я решил остановится на последнем, ибо оно современнее, чем вышеупомянутый STK200.

ЛПТ у мя один, вот и решил STK200 переделать в байтбластер, а вместо оного применить собственный вышеупомянутый девайс на USB. Хотя теперь уже возникла идея и байтбластер на USB перекинуть...

Таки Вы и не поняли мою мысль. Если переделаете stk200 в bytebluster, переделанный девайс не потеряет возможность программировать AVR!

Вот вам и USB программатор на протоколе stk500.
http://www.tuxgraphics.org/electronics/200...icle05101.shtml

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

Да все я понял....Ну не нравится мне командная строка AVReal...Это одно. Я в отпуске, и захотелось посмотреть, что такое программный USB на AVR, это другое.

Сейчас появилась идея извратится и с LPT по тому же принципу

Он сделан на чипе от FTDI. Ничего не имею против данной конторы, но меня более интересует программный USB на AVR. К тому же, ИМХО, производительность оного чипа сомнительна (только давайте не будем опять разжигать в этом топике межнациональный спор, что лучше), и дрова под него ставить надо...Сдесь же все прозрачно и просто.

По поводу программаторов как грязи - согласен....Я же не предлагаю Вам его купить. Я просто показал то, что сделал, всего лишь.

Я ожидал, конечно, что будут более интересные вопросы, но, похоже я ошибся...

а вот это здраво! ибо ЛПТ потихоньку отмирает, а с ЛПТ эмбеддерам прощаться очень уж не хочется... может действительно сделать USB->LPT, и соответствующий драйвер dlportio для этой приблуды...

А зачем драйвер? Я, правда, еще не вдавался в подробности CDC USB, но, по идее, он должен поддерживать и LPT через Win32 API

Нет, не будет. Он и COM поддерживает почти случайно.

ЖАль, еще есть Printer Class, может с ним что сварганить можно?

И с ним нельзя. Слишком далек он от "железа".

А всевозможные переходники USB-LPT получается со своими дровами идут?

Угу. И всякий программаторный софт с ними не очень дружит.

ИМХО, LPT, в отличие от COM'а умрет достаточно быстро и безболезненно, и
создавать такие переходники нецелесообразно.

Я бы хотел выразить благодарность автору. Использую 910 на ком порт - на ноутбуке один ком порт и постоянно приходится перетыкать шнурок. С USB будет удобно. И вопрос работает ли Ваш USB AVR910 с Codevision программой для программатора и с программой avrdude.

Спасибо за благодарность!))) Моя девайсина работает со всеми программами, которые видят AVR910 ISP, так как протокол один в один. Единственно - AVRProg, когда я его мониторил, обращался только к портам COM1 и COM2, а так как в моем компе оба СОМ-а заняты, и под модемы и всякие другие шелезяки зарезервированно СОМ портов аж до 9, естественно AVRProg его не увидел. Пришлось в ручную одному физическому порту присвоить имя СОМ10, а моему программатору соответсвенно СОМ2, после этого все пошло как по маслу

Полностью присоединяюсь по той-же причине - наиполезнейшая весчь! Спасибо автору!

Возможно, не совсем в тему, но меня интересует вариант USB boot loader'а (а не программатора). Есть несколько вариантов, но вариант STK500 и CDC поверх USB был бы очень приятен. Свой USB boot я сделал, но он - HID со своим протоколом, что выглядит неинтересным. Я выложил тот проект в свободный доступ на сайте AVR-USB, но развивать его бросил, так как нужда писать нестандартный софт со стороны PC меня напрягает (я не люблю писать под PC).

Вопрос же такой: а что со стороны Windows поддерживает этот протокол (STK500)? Хотелось бы иметь ПО, позволяющее как красиво ставить галочки на фьюзы и пр., так и использовать полностью пакетный режим. Я просто с STK500 не сталкивался, потому не в курсе дела, какой софт поддерживает этот протокол.

Нельзя ли тут ткнуть пальцем в минимальный список (AVR Studio, думаю, будет первым, но я его не исталлировал даже, так как пользую IAR). Есть еще что-то?

А какая связь между STK500 и bootloader'ом?

Делал я в свое время клон STK500 + PICSTART+ на ATmega16 и PDIUSBD12. Прошивка обновлялась как раз при помощи своего USB CDC bootloader'а. К сожалению, проект пришлось забросить по причине острого недостатка времени...

Я сейчас мучаю бутлоадер именно в таком плане, но пока напряг с размером бутблока в меге8, а хочется именно на ней сделать свой программатор, так как мега 32 уже дорого выходит. Можно и на ХИД-классе сделать, а под девайс написать свой драйвер, благо опыт небольшой есть, но хочется, чтоб без разных дров все работало. Так что пока безутешно занимаюсь запихиванием в 1 килослово AVR910 и USB obdev

Всего лишь такая, что любой bootloader работает по определенному протоколу. И если этот протокол - один из стандартных de-facto, то шить такой девайс можно оболочкой (командной строкой) от программатора, а не собственной утилитой под собственный протокол.

В принципе, AVR910 протокол тоже имеет право на существование. К нему есть (для старых девайсов) оболочка AVRPROG (не поддерживающая ни командной строки, ни новых устройств), а также AVRISP, поддерживающий все, что угодно, но не имеющий GUI. И на этом всё. Предполагается, что более популярные протоколы дают больший выбор.


Были такие идеи и у меня, но до реализации ход не дошел. Вероятно, можно попробовать просто переписать кусок драйвера на ассемблере, и на нем же - все остальное. Тогда должно поместиться. Работа, правда, будет серьезная, хотя и в значительной степени механическая. А бут в меге8 - это ведь не только в меге8 - это, например, в AT90PWM3, где такой интерфейс был бы очень полезен для определенных применений. Потому мне тоже интересна эта тема, но кроме асма я пока не вижу альтернативы. Есть, конечно, готовый бут для всех мег (в т.ч. 8-й) на том же сайте, но он требует установки драйвера. Это существенный минус. Так что удачи!

В том то и дело, что хочется именно на Си реализовать, так как (и я в этом не раз убеждался), на Си проект получается совсем-совсем на чуть-чуть больше, а то и меньше чем оный же на ассемблере, за то выйгрыш в скорости написания проекта неоспоримый. Да и встроить такой код в другой проект плевое дело. Даже взять пример с моим проектом программатора. Сначала я взял код от Igor Cesko где ВСЕ регистры заняты под сам USB драйвер + код AVR910 где ВСЕ регистры заняты под программатор... ужас...подумал я и взял драйвер от Objective Developvent - благое дело, проект задышал на макетке спустя пару часов (час на разборку USB джойстика, дабы поиметь с него шнурок, и на паяние схемы)

Вообще пути решения есть, как протащить верблюда через игольное ушко, но пока скромно промолчу

Это точно что благое дело. Самое удивительное, что автор продолжает активно развивать сей проект. Скажу по секрету, что уже готова версия драйвера с полностью конфигурируемыми USB дескрипторами, каждый из которых может быть во FLASH, в RAM или запрашиваться в run-time вызовом функции. Это дает возможность делать комбинированные устройства, чего мне очень не хватало бы в одном из потенциальных применений. Сам я этот код еще не пробовал (руки не доходят), но по утверждению автора, использованы дополнительные возможности оптимизации компилятора (путем соответствующего написания кода), что эта версия может получаться еще более компактной, чем предыдущие, несмотря на расширение функций. Как только версия пройдет stress testing, я полагаю, она появится и на сайте автора.

Ну что за расстройство - стоит только что-то захотеть, а кто-то это уже сделал
Завтра на сайте obdev появится новый проект - программатор для AVR с поддержкой STK500. Поддержан высоковольтный режим программирования, питание от USB, встроенный USB-to-serial конвертор...

Громозека: "Опять я опоздал..."

Да не расстраивайтесь, всегда можно сделать лучше, чем есть...

Что-то не видать его...

http://www.obdev.at/products/avrusb/avrdoper.html

Однако немного схитрили ребята, я еще пока разбираюсь, но что то там с HIDом завязано, а это похоже, что дрова надо ставить, или я не прав?

1) HID хорош как раз тем, что это стандартный класс, для которого свои драйверы не нужны.


Думал, что это опечатка (и имелся в виду не драйвер, а свой софт уровня приложения), но похоже, что это другое.

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

Альтернативно можно сделать устройство CDC, представленное как стандартный COM порт, например. Для него тоже существует системный стандартный драйвер (к нему необходим уже .inf файл, хотя сам драйвер от Microsoft), но потом с ним может работать любая утилита, например, программатор, понимающая COM порт API.

А свой драйвер надо писать, если устройство не относится ни к какому стандартному классу.

2) Говоря про конкретно AVR-Doper. Стандартным для него является CDC интерфейс, и программатор представлен COM-портом, с которым непосредственно работает весь софт, понимающий STK500 протокол. Драйвер порта при этом используется стандартный.

Альтернативно можно скомпилировать прошивку, поддерживающую собственный протокол через HID. При этом никаких .inf не надо, но пока нет утилиты управления программатором, работающей через HID. Поэтому смысл этого больше теоретический, что понятно, так как проект является образцом (reference) для написания подобных приложений.

Если не затруднит просветите в чем разница между 910 и STK 500

2 prottoss а когдаже будут светодиоды, уже так хочется собрать в корпус.

Посмотрел на схему и вижу: Mega8-16, напряжение питания 3,5 В, частота 12 МГц... Как я понял, при таком питании максимальная гарантированная частота 8 Мгц, или я не прав?

До конца недели будут точно. Блочный режим уже написан, что подняло скорость программирования примерно раза в 1,5 - 2 (оценивал визуально). SPI работает на четырех фиксированных частотах, в зависимости от тактовой частоты МК - clock/8 ../16.. /32.. /64 в - это для AVR. Для 89S частота будет clock/128

даташит ATmega8 Complete, Раздел ATMega8 Typical Characteristics ->Active Supply Current (Page 247 Figure 119 Active Supply Current vs Frequency (1 - 20 MHz))

Имелось в виду драйвер, который бы выступал в качестве виртуального СОМ-порта, и передавал данные на HID-устройство. Дело в том, что изначально устройство задумывалось, как совместимое со стандартным атмеловским софтом, который и ведать то не ведает про HID, да и из СОМ-портов то только всего два видит...

Значит, в тот раз я понял правильно.
А в этот раз вопрос про драйвер для HID меня сбил с толку. Впрочем, CDC в данном случае выглядит интереснее. Беда лишь одна - он жрет процессорное время AVR (см. описание драйвера). Так что для простых вещей, завязанных на USB, это приемлемо. А вот как побочный интерфейс наряду с основной сложной функциональностью - увы...

А может есть уже прикидки на каких ножках они будут стоять, а то я уже плату развел.

Наверное, немного энтузиастов возьмутся делать на подобном драйвере виртуальный жесткий диск или еще что, требующее большой перекачки данных, но для малых устройств, ИМХО, отличное решение, тем паче на Си. Решающее значение имеет то, что в одном флаконе (корпусе) можно объединить USB и собственно функцию

Мне вот интересно, насколько реально транслировать, этот драйвер под CODEVISIONAVR ?

Спэшл фо ю: т.к. порт В безнадежно занят под ИСП, и как раз на нем два свободных ВВ, то РВ0(запись) и РВ1(чтение)

Решение-то отличное, но я же не об этом. А о том (см. документацию на драйвер), что при реализации CDC (и вообще bulk transfer) драйвер будет проводить внутри USB прерываний 90% процессорного времени AVR независимо от того, что он делает, так как хост будет поллить его до посинения. В итоге на собственно функцию останется только 10% времени CPU.

Имея требование обеспечить приоритет USB int0, мы ничего не сможем с этим сделать. Так что про time-critical функции можно легко забыть. Программатору это не критично, как и boot-loader'у, а вот другим применениям - даже очень. Единственным вариантом я вижу или отключать USB устройство, когда оно не нужно (использовать только для конфигурирования или сливания данных, а в остальном - работать автономно). Или не использовать такие интерфейсы, что обидно.

Workaround'а автор пока найти не смог, если это вообще возможно.

Дословно из переписки:

И, что ни каких путей управления управляющим потоком (извините за каламбур) нет?

И еще вопрос: bulk transfers могут быть 8, 16, 32, 64 байта..., для низкоскоростных устройств, и для драйвера, в частности, это тоже имеет место?

Я не смотрел новый драйвер в этом плане. Но если автор пока путей не видит, то боюсь, что действительно есть проблема. Можно, конечно, просто отвечать на все NAK, но работать при этом мы с USB не сможем.


Не смотрел, надо смотреть код. Или спросить автора драйвера. Я спрашивать пока не готов, так как не "въезжал" в эту тему пока. Времени нет.

Как они должны быть подключены, анодом к мк через резюк или иначе.
Планируется индецировать соединение девайса с USB ?
И как заиметь свежую прошиву, насайте от 15.07.2006

IMHO, лучше не тратить время на AVR910 программатор когда уже есть STK500 совместимый на полностью аналогичной схеме. AVRProg (AVR910) практически не обновляется, между вер1.37 и вер1.40 несколько лет прошло и будет ли следующая версия не известно.

Светодиоды будут подключаться, скорее всего, анодом к МК, катодом через резистор 220 ... 330 Ом на "землю" . Кроме этого, планируется поставить опторазвязку, подключение оптронов по точно такому же принципу. Прошивка будет доступна так же на страничке.

Кроме AVRProg есть и другие программы, поддерживающие AVR910, кроме того, пока, в пакет AVRStudio программа AVRProg входит. Встроить же в AVR910 высоковольтное программирование плевое дело (но нужно оно, мне, ИМХО для программирования тех чипов, которые нельзя программировать обычным последовательным способом).

Дело каждого, собирать AVR910, STK500, или еще чего

Известно - не будет. Поскольку AVRProg давно уже заменен на AVROSP - Open-Source Programmer (AVR911). Последний выполнен с открытым исходным текстом и поддерживает работу только из командной строки. Зато он не содержит описания кристаллов, а использует вместо этого XML файлы из AVRStudio. В результате любой новый чип можно шить, скопировав указанные файлы или просто поместив их в PATH. Кстати, у него нет этого ограничения в COM1 или COM2. Можно указывать и другие порты.

Я нашел только одну беду: у него никак не задается скорость в порту. В результате на моих машинах он не видит железа, если перед этим порт не был настроен на требуемую скорость (например, из панели управления или путем запуска AVRProg или любой терминашки).

Если он OpenSource - это не беда, легко ведь добавить нужные ключи, а настройка последовательных портов из Win32 - 10 строк кода...

2 prottoss ну когдаже будет новая прошива, чтоб светики моргали.

Подскажите посмотрев на организацию схемы USB_STK500, переделал схемку проттоса, но вот вопрпос, будет так работать ?

Может быть в меня счас полетят тапки от матерых электронщиков, но мне не очень нравится схема со стабилитронами. Объясню, почему:

1. Я считаю, что стабилитроны включены правильно только по отношению к МК, т.к. только с его стороны стоят токоограничительные резисторы, это и понятно - для того, чтобы ограничить напряжение сос тороны МК. Со стороны же USB таких резисторов нет, так что, если на шине USB напряжение будет превышать напряжение стабилизации стабилитронов (3,6 вольт), через них может потечь относительно большой ток. Может быть, проблему можно решить включив и со стороны USB резисторы номиналом 22...47 Ом. (???)

2. Стабилитроны имеют емкость, хотя и относительно небольшую, и возможно искажение формы сигнала как со стороны USB, так и со стороны МК.



Хотя, конечно, решение простое, и, так сказать, в лоб, но, ИМХО, не факт что красивое. Опторазвязки в схеме AVRDOPERа тоже нет, что не есть хорошо. Сами понимаете, что в некоторых случаях вы рискуете потерять не только USB порт, но и мамку вашего кремниевого друга. Я же, все таки, остановлюсь, на своей схеме. Правда в место стабилизатора поставлю впослед два диода средней мощности, а разъема ISP развяжу с МК через четыре оптрона, подешевле и побыстрее. Прошива с блочным режимом уже протестированна, скорость, как и ожидалось, возрасла - при записи примерно раза в 1,5 -2, при чтении примерно раз в 5. Схема с диодами и прошива скорее всего (но не факт)будет сегодня. Напрягает больше всего то, что я уже вышел на работу((( и свободного времени резко поубавилось(((((((((( Но эксперименты с проектом я в ближайшее время забрасывать не собираюсьи есть еще кое какие задумки, но об этом пока говорить рано...