Кроме 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. Схема с диодами и прошива скорее всего (но не факт)будет сегодня. Напрягает больше всего то, что я уже вышел на работу((( и свободного времени резко поубавилось(((((((((( Но эксперименты с проектом я в ближайшее время забрасывать не собираюсьи есть еще кое какие задумки, но об этом пока говорить рано...

ATtiny26 (ATtiny2313 кроме fuse!!!)

а что с фузами ?

Fuse bits у tiny26 и tiny2313 не совпадают побитно, за исключением самого младшего байта. Однако AVRProg не пишет fuse побайтно, а скидывает все в МК после нажатия кнопки Write, соответсвтенно я бы не рисковал менять fuse bits. Между тем размер страницы памяти программ у tiny26 и tiny2313 совпадает, поэтому производить запись/чтение FLASH&EEPROM можно безболезненно, так как AVRProg НЕ АВТОДЕТЕКТИРУЕТ ЧИП!!! Ребята из ATMEL придумывают хорошие кремниевые штучки, но вот бригаду программистов, которая отвечает за soft support я бы послал к той самой матери...

Да забудьте вы про AVRProg - возьмите AVROSP (AVR911). Там нет этих проблем, все читается и пишется, описания чипов берутся из XML от самой свежей AVRStudio.


Если говорить о соответствии стандартам, то со стороны хоста не должно быть напряжения выше напряжения стабилизации диодов Зенера. Потому проблема есть только со стороны МК, и она действительно решается.

С другой стороны, USB устройство (как хост, так и device) обязаны выдерживать замыкание любых ног разъема в любых сочетаниях произвольное время. Как плюс на минус, так и сигнальных ног на любую из ног питания. Этому соответствуют очень далеко не все хосты (хабы и особенно материнки), которые горят по перегрузке по току.

Так что всё очень относительно, и если оно работает - можно не париться особо сильно, тем более, если устройство питается от самого USB.

Вы сами себе противоречите по поводу диодов, раз говорите что "... Этому соответствуют очень далеко не все хосты (хабы и особенно материнки), которые горят по перегрузке по току ...", К тому же ИМХО диоды Зенера, или попросту стабилитроны, все-таки имеют емкость, и ставить их параллельно линиям данных я бы не стал, тем паче что в AVRProg нет никакого контроля данных, а если к этому прибавить то, что в драйвере USB нет контроля достоверности данных (CRC), так вообще поле чудес может получиться, хотя у меня вся девайс уже скоро месяц, как нормально работает, при том что рядом куча заводов, фабрик и пароходов)))



По поводу AVRProg, как морально устарелого продукта, я с Вами согласен, но это был просто небольшой эксперимент c драйвером от Obdev, к тому же это мой первый (и скорее всего последний) опыт работы с AVR910... Переделать же все это в STK500ISP нет проблем ни каких, и я, со временем, переделаю, конечно, свое детище под STK500. Все же, ИМХО, изначально, что AVRProg, что STK500, принципиально "не правильные" продукты с точки зрения пользователя. Команды обоих изначально ориентированны только на использование с AVR. А мне видилосьчто то похожее на PONIPROG, который ориентирован на работу со всеми девайсами, имеющими хоть что то похожее на SPI. По идее так и должно быть - Чапай должен знать, как одолеть противника, а Петька просто пулеметчик. Сдесь же немного другая картина - и хост НЕМНОГО интелектуальный, и программатор тоже что то там свое соображает, хотя думать должна только программа, и она же должна знать и диктовать алгоритм программирования, а программатор только выполнять примитивные команды.

В ломы, конечно, писать универсальную программу схожую с PONIPROG, но можно попробовать...Хотя опять кто нибудь скажет, что этого [email="го@на"]го@на[/email] полным полно в сети...

Я не противоречу, а утверждаю, что у нас уже более чем достаточно несоответствий стандартам как программной, так и аппаратной части. Одним больше или меньше... Поэтому пытаться сделать максимально корректно любительскую конструкцию не слишком частого применения, как минимум, не всегда имеет смысл. Я предпочитаю зашить один раз boot loader, а потом работать через него. Это удобно во всех отношениях, в том числе, не нужен больше программатор. А в качестве интерфейса использую либо USB (если оный есть на устройстве), либо UART, для которого имею USB-to-UART конвертор, собранный в USB разъеме на CP2101.


Опять же, мы работаем на уровне "должно вроде бы работать". Устройство low speed, потому сильно мешать не должно.


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


Мне почему-то кажется, что тем, кому нужна максимальная универсальность, могут купить готовый программатор. Или собрать PonyProg. Потому лично меня этот топик больше интересует с точки зрения boot loader'ов и их интерфейсов, а в этом смысле универсальность программатора не имеет смысла.

Кстати, по поводу бутлоадера. Так и не смог я втиснуть в одно килослово USB драйвер и хотя бы малую толику программатора. В связи с этим есть идея - если, допустим, загрузчик держать в верхних адресах, но его код будет, к примеру, два килослова. Смогу ли я таким кодом прошивать нижние два килослова памяти программ МК? Конечно, функции записи-чтения памяти программ будут находится в области boot памяти программ МК.

По поводу бутлоадера... идею кину... установить на плате программатора еепром 24ХХ и заливать новую прошивку через USB в эту еепром, а затем каким либо способом запустить бутлоадер, который зашъет контроллер из еепром - таким образом не надо будет делать бутлоадер на USB который не помещается в 1к памяти, а надо сделать бутлоадер для I2C который поместится и в 512, я думаю. И еще одно преимущество при таком способе прошивки - можно менять код самого драйвера USB от obdev

Идея понятна, но дело в том, что USB постоянно должен обслуживать прерывания. На время записи их нужно запрещать, но на минимальное время. Не запрещать их нельзя, так как во время записи область приложения блокирована даже на чтение. Возможно, реально-таки так скомпоновать все, чтобы вынести интерфейс программатора в apps область, и не пользовать его во время записи (а USB драйвер пусть себе прерывается, лишь бы не попасть на интерфейсный запрос).

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

Проще тогда уж использовать реализацию загрузчика через usblib, и написать интерфейс между ним и программатором в виде драйвера виртуального COM-порта. Или писать свой лоадер со стороны PC. Криво все это.

Ага, а во время заливки драйвера дадим РС отмашку релюшкой - обождите дяденька - я писаю...

Если бы все было так просто... После чтения по USB кода в EEPROM элементарно или запретить прерывания по USB (устройство потеряется), или, что куда лучше, использовать usbDeviceDisconnect() для такой цели (цена вопроса - один пин ввода-вывода). Последний использую я (с моей подачи он и появился в драйвере), отключая устройство, а потом вновь включая. В этом случае можно и код USB переписать.

Но проблема-то в другом: даже если исключить проблемы с RWW/NRWW областями, загрузчик обязан вмещаться в защищенную область памяти. Иначе это не загрузчик, и совершенно случайно будет стерта та часть, без которой реанимировать девайс можно будет только программатором. Это не серьезно.