Не знаю, насколько это имеет смысл в свете имеющейся информации о будущем Атмел, но подоспела очередная версия avreal.

Добавлен наконец-то замер времени обращения к LPT для всех ОС и добавлено несколько новых кристаллов.


Кстати, о времени обращения к LPT - поднятый для экспериментов с Win98 старый пень-166 вне конкуренции. Одна и та же физически плата PCI-LPT на Q6600/ASUS M2N-SLI что под XP, что дос-версией при загрузке с дискетки даёт около 0,75мкс/обращение (программный замер достаточно хорошо совпадает с замером по осциллографу), а на том старом пне - около 0,25мкс. Одна шина PCI, никаких лишних мостов по дороге, простота...

Конечно нужно !
Люблю командную строку.
Спасибо огромное.

Конечно нужно и спасибо - лучший программатор из тех что пользуюсь.

А насчёт Atmel-а я тоже особо не волнуюсь. Заплатить 2.4 млрд $ чтобы просто убрать конкурента - бред сивой кобылы. Платят, так как есть деньги и пусто насчёт куда их деть. Нет идей. Таких примеров масса. А сейчас очень удобная ситуация на рынке для тех у кого есть бабки. Масса фирм торгуются ниже уровня своей стоимости.

Ни одно из разработанных изделий не будет уничтожено. Я уверен. Это просто бессмысленно. В цикле производства - разработка - самая затратная часть. Другое дело, что возможно развитие пойдёт другим путём. Возможно какая-то интеграция будет. Так это уже совсем другое дело.

Спасибо!

Спасибо огромное!

> Не знаю, насколько это имеет смысл в свете имеющейся информации о будущем Атмел...

Если у меня и были сомнения по поводу выживания АВР'ок после продажи Атмеля, то теперь они рассеялись. Раз вышла новая версия АвРеала - уже ничто и никто не сможет уничтожить не только меги, но и Хмеги. А вдруг Реал выпустит новую версию и для этих легкодоступных и пользующихся заслуженной славой у профлюбителей камней?

Спасибо, Реал, авреал несколько раз спасал меня в критические дни (это я о сдаче заказов:-)

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

Спасибо. Хоть и непонятно будущее Атмел, но на данный момент avreal востребован.

Хорошпя штука. Только у меня вопросик к Real_у.
Чтобы не потерять логи работы программатора, я написал батничек с таким содержимым:
avreal32 +TINY2313 -aa -p1 -e -w -v -%% -c diffigniter.hex >>prog
Знаю, что cmd_шник идеологически будет правильнее, но с ним та же проблема.

Пока пользовался версией 125r5, выходная информация писалась в файлик prog.
Как только установил 126r0, файлик prog перестал писаться. С версией 126r2 опять все нормально. В описаниях History версий программатора по этому поводу ничего не упоминается.
Хочу выяснить для себя. Это недокументированный глюк версии 126r0 или проблема пошита в нетрях моей XPSP2_rus?
Батничек запускаю из-под FAR_а.

Немного не в тему, а что с Atmel? Дайте ссылку на инфу, можно в личку, чтобы форум не засорять.

Ой, это я просто забыл отметить.
Дело в том, что возникла мысль освободить stdout для каких-то скриптовых автоматизаций (например, добавить ключи, которые заставляют на stdout выдать значение OSCCAL подключенного кристалла или ещё что-нибудь), а всю информацию, предназанченную для человека, а не для скриптов, выдавать, как это и принято в определённых местах на stderr.
Для XP (да и для Win2000) это не создаёт особых неудобств.
Во-первых, можно добавить в командную строку

и всё, что направлялось на stderr, пойдёт на stdout
Во вторых, можно так:

и именно stderr пойдёт добавляться в лог-файл.
А вот с W98 проблема. У неё командная строка недоделанная, такие вещи не работают.
Кажется, можно вызывать батник из батника, где-то по дороге W98 сама сольёт stderr и stdout в один поток. Короче, дурдом.
Я пока не решил - толи при определении ОС специально для W98 направлять на stdout, а для всех остальных stderr, толи добавить ключик, по которому лог валить на stderr, а по умолчанию оставить как было, на stdout, толи ещё как-то это решить.
И пока вернул как было.
Если таки поменяю - обязательно опишу.



http://electronix.ru/forum/index.php?showtopic=53417&hl=


Ну, пока у меня просто нет под рукой кристалла. Интенсивно и не искал, так как пока нет и времени
Что могу сказать более-менее уверенно - с программным ногодрыгом через LPT туда можно и не соваться, а вот какая-нибудь FT2232 может и пройти.

Кроме критических дней есть ещё такая штука, как МАНИпауза у начальства - оно становится раздражительным, подозрительным, ревнивым... И тут, боюсь, avreal не поможет.

Вы сделали удобную и практичную весчь. А доработки это подтверждение отличного продукта. А Атмель как то переинкарнируется и т. д. кароче не умреть.

Спасибо, давно пользуюсь и, надеюсь, и дальше буду!

Спасибо большое.

Большое спасибо! Самый надёжный и компактный программатор.
Жаль только, что LPT-порт отмирает, на ноутбуках уже умер

Здравствуйте
Вопрос к Real.
Если Вы автор, то предлагаю совместно решить один животрепыхающий трабл - прикрутить AVReal к usb интерфейсу. Проблема что у меня уже ни на одной машинке нет LPT

предлагается оформить LPT чтение-запись в пакет и передать моему коду - "USB-трубе" . я его транслирую на другой конец и формирую провода SCK MISO MOSI XTAL1 (если требуетса) RESET +5v (от шины USB если требуется) GND

USB-трубу можно сделать в двух вариантах (предлагается как мне кажется самые простын и доступные решения):
1. FTDI FT2232/232 в режиме GPIO для формирования интерфейса программирования по SPI
2. теже яйца FTDI FT2232/232 как UART -> ATmega -> таргет, в таком случае программатор может станет умнее если это нада.

все что протребуется от AVReala это перенаправить IO из интерфейса драйвера LPT в мою USB-труба библиотеку.

просто писать самому AVReal - это глупо, я тоже считаю что это лучший программатор.

еще вопрос - скоро XMega попроет - там другой протокол программирования -я читал чето мутно очень написано..... AVReal будет допиливатся?

... или добавить в avreal поддержку stk500v2. И тогда огромное количество COM и USB наработок будут поддержаны "авреалом".

Это уже смешно звучит (я глянул в архив почты, как давно я эти слова Вам уже писал ), но я "медленно топчусь в этом направлении".
Но наконец-то уже топчусь, а не примеряюсь.
1.26r0, 1.26r2 - кроме видимых в истории изменений происходит некоторая внутренняя перестройка программы, разделяющая её на слои, которые можно более-менее независимо заменять (первой ласточкой была возможность под W98 работать без dlportio а под линуксом - и напрямую на порты, и через ioctl на /dev/parport ).
Отдельно в уголочке через появившуюся у меня плату с FT2232 в режиме её аппаратного SPI сделан кусок, успешно читающий DEV ID из AVR-ок. Пока только win-версия через родные DLL-ки от FTDI, но с добавлением очередного слоя в avreal прикручивание FT2232 для win-версии будет довольно простым. Как работать с FT2232 под linux/freebsd придётся ещё разбираться.

По xmega первые прочтения документации не напугали, FT2232, как я уже писал выше, должна потянуть. Но сначала надо её прикрутить для обычных AVR, а потом уж начинать пробовать xmega.

p.s. Мне очень неловко, что я так долго всех кормлю завтраками... Особенно учитывая, что пара FT2232 появилась у меня с небольшой задержкой после того, как через пару недель после того, как filur electric в Киеве анонсировал её на своём сайте... Т.е. очень давно. Тьху-тьху-тьху, вроде бы и проблем особых в жизни нет, но руки постоянно не доходят.

что мешает освоить AVRDUDE? работает из командной строки, поддерживает кучу протоколов, в том числе и с USB, есть версия под Windows и Linux.

я тогда просто ответа от Вас не получил, поэтому подумал что это Вам не интересно.

прикрутить к Linux ft2232 я думаю не проблема, я могу обеспечит прозрачность USB-трубы независимо от платформы на уровне IO интерфейса чтоб чтоб Вам с этим не морочится.

ну так я не понял - будем кошку жарить или нет?

ReAL, не собираетесь прикрутить поддержку AT45 микросхем памяти?
И может вынести работу с портом в отдельный модуль со стандартным интерфейсом (dll), чтобы любой желающий мог подключить avreal к специфическому железу.

Типа он вроде как работает, но в случае USB девайсов (по крайней мере под Win) далеко не всегда. Давно правда уже не пробовал, но с год назад как не стучал в бубен кроме разнообразных эффектов ничего рабочего не получил .
При смешной цене всяких оригинальных Atmel-овских USB девайсов и убогих интерфейсов оригинальных-же утилит командной строки, не отказался-бы иметь их поддержку AVReal-ом.

Да интересно, только эти два года как-то странно прошли...


Для вин-версии уже многое готово, говорю же, SPI-процедуры написаны и проверены отдельно, прослойка SPI в avreal дописывается.
Не знаю, что имеется ввиду под IO-интерфейсом, у ft2232 много разных режимов и хотелось бы иметь доступ ко всем её возможностям в чистом виде, а не ограничиваться какой-то моделью.
Поэтому мне кажется лучше под win (по крайней мере начать) работать через родную DLL производителя, потом под линуксом разобраться (с libusb ?).
Мне кажется, что чем "роднее" будет сделана работа для каждой ОС, тем больше возможностей и меньше ошибок.
Ну и хочется самому с этим всем разобраться.

"собираюсь", так как там проблем особых нет. Опять таки, отдельно на коленке по конкретному случаю (для прошивки какого-то информатора на тини26) - только вин-вресия, только байт-бластер, ещё какие-то ограничения - оно уже работало. Причесать и добавить в avreal (как, кстати, и по просьбе одного человека написанный подобным грубым образом программатор at89s51/at89s52) всё руки не доходили.

Стандартные интерфейсы внутри программы, кроме естественного интерфейса к прямому доступу к портам, только сейчас начали вырисовываться.
Но мне кажется, что кандидатами на вынос во внешний модуль могут быть
* Довольно низкого уровня процедуры прямого доступа к портам (чтобы подменить доступ через dlportio на что-то другое), но не совсем понятно, хачем решать эту win-специфическую проблему уходящей в небытие аппаратуры
* Довольно высокого уровня абстракции "SPI-адаптера с расширенными возможностями управления", но тут я сам ещё не решил толком, чего я хочу. И, опять таки, это возможно решит вопрос замены FT2232 на какой-нибудь AlteraUSB-blaster, но никак не поможет прикручиванию выводка USB-программаторов от совместимых с AVR910 и до более навороченных.
Оно надо?
Не знаю, есть ли смысл, позже подумаю.

Да-да-да, но это следующий шаг (только бы не выдохнуться на текущем, как это уже не раз за 10 лет бывало - замирания в работе над avreal на год-два).
Речь о FT2232 идёт потому, что это мало затрагивает построение программы, ориентированной на прямую работу с кристаллом AVR по SPI (при этом слепленной за много лет эпизодическими правками "из того, что было под рукой"), поэтому проще в реализации.

Поддержка железа, которое банально можно купить, несомненнно, даже при российских самоделкинских реалиях, более перспективна, чем:


Нет.

Т.к. основное программирование проходит через своеобразный SPI и плюс несколько линий на RESET, CS и т.п., то имеет смысл разделить отдельно логику самого программатора (разбор hex файла, карта памяти конкретного устройства) и логику интерфейса программирования (тот самый SPI + дополнительные выводы). Делить лучше в этом месте, т.к. тогда можно хорошо оптимизировать работу с аппаратурой в рамках своего модуля. А аппаратура, в принципе, может быть любая. Хоть простой STK200, может быть что-то по COM-порту (JTAG-ICE), что-то по USB (FT2232 или бюджетный IgorPlug).

Кстати, нет желания открыть исходники?

Вообще говоря да. Только модель работы с LPT soft SPI ( spi_out() spi_out() spi_out() spi_in() для команды чтения байта из AVR) мягко говоря плохо подходит для работы с FT2232 hardware SPI, скорость падает на полтора-два порядка относительно возможной. А модель spi_io(длииииииинный_буфер), более полезная для FT2232, в полтора раза садит скорость при работе с LPT. Поэтому среднему уровню программы, забрасывающему разобранный верхним уровнем HEX в нижний уровень обмена с микроконтроллером, надо кое-что знать и про детали реализации SPI-адаптера (хотя бы на уровне bool block_mode_is_faster() ) и менять подходы в работе с SPI. Чем сейчас и занимаюсь. По LPT-модели (чтобы просто "прокачать канал") FT2232 @ win32 вчера заработала. Но 33-34 секунды на чтение кода из mega168 врядли кого-то устроит.
Ну и фенечек типа переназначения ноги reset и назначения ног для открытия буферов на выходах (по аналогии с mapped adapter для LPT) пока нет, поэтому работа только с "голой" FT2232, без буферов.
Ну и для -o0 нужен будет совсем другой режим работы FT2232, это ещё позже будет.

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

Первый - интерент и так завален паршивыми исходниками. А они паршивые, чесслово. "я бы себя к себе на работу не взял". Время на это выделялось по остаточному принципу и никогда не хватало на большее, чем по быстрячку добавить наболевшее. И начиналась программа тоже как "на коленке слепить нечто для себя для более быстрого и комфортного выполнения пары халтурок", я тогда не собирался застрявать на AVR-ках, внимательно смотрел на 16-битники и поглядывал на ARM-ы (с тех пор валяются так и не впаянные MB90F497 и платка з запущенным на уровне "помахать на асме ножкой осциллографу" S3F441. Но потом и задачи изменились, и оказалось, что 90s4433+90s8515+mega103 и их более новые замены перекрыли чудесно весь спектр задач. Но плохое начало в 98-99 годах не рассчитанной на расширения программы до сих пор дают о себе знать.
Так что "ешьте колбасу пока не знаете, как она сделана"

Второй - не скажу.

Кстати ваши аргументы мне, к примеру, кажутся очень убедительными и .... весьма близкими.

Кроме всего, это ведь простая риторика... Ведь даже если вы выложите в инете исходники, никто ведь не кинется поддерживать ваш программатор. Развивать его. Ведь это труд.

Ну что такое разбор HEX файла? - Два десятка операторов. Если у кого есть есть желание написать - это полтора часа от силы. Разбор командной строки поболее, но тоже не бог весть какя работа. А всё вместе - с обработкой, отладкой, тестированием, вылизыванием, совместимостью - достаточно длительный процесс.

Так что это всё отмазка. Если вы, Itch, захотите, то напишите свой. Что мешает? И что изменят исходники от ReAl?

Кстати, это рядом с третьим аргументом, но он не так важен, как первые два, поэтому я его и упустил.

Был такой UISP (не знаю, может ещё и есть). Появился, судя по прочитанным когда-то логам в его исходниках, где-то в то же время, что и avreal, и Pony - 1998 год. Но тогда был только под линукс, я про него ничего не слышал (если бы слышал, то может и не стал бы писать свой).
С самого начала по линуксовой привычке он был с открытыми исходниками. "Ну и это ему помогло?" В какой-то момент его развитие было, видать, признано не имеющим особого смысла и с нуля был сделан avrdude.

avreal того же возраста и, учитывая сказанное ранее, его пора бы переписать с нуля и по возможности не заглядывая в старые исходники :-) Я честно пытался сделать это в 2002 и 2006 годах. Но отпуск так короток... А после него дела наваливаются с новой силой...

а чем прлох avrdude ?

Не уничтожить а поглотить. У атмела не плохой рынок сбыта и уже использующиеся модели будут несомненно производится - в микрочипе же не идиоты сидят. Вот только насчет новых разработок видимо они далеко не все будут внедрятся, одна компания не может себе позволить тратить деньги на развитие нескольких конкурирующих линеек продуктов.

Точнее те, которые слишком затратны (иными словами на начальной стадии развития), те будут прибиты. А изделия с раскрученным брендом будут выпускаться, и думаю даже развиваться. Возможно с учётом слияния компании. Например переферия совместная или что ещё.

Какой смысл гадать. Всё узнаем.

Первый вариант сделан так - для работы используются TCK (SCK) / TDI (MOSI) / TDO (MISO) / TMS (RESET), на все остальные выводы канала А подаются нули и если какие-то шинники есть, то они открываются.
-o0 не работает, для него нужен не аппаратный SPI, а sync bit-bang, что сразу ощутимо садит максимальную скорость получившегося SPI и для начала отлодено.
Модели работы различны, поэтому и LPT не замедлился, и FT2232 близка к теоретическому максимуму скорости прошивки.
Если бы нашлось несколько человек на тестирование, было бы неплохо, обращайтесь в почту.

Кроме нормальных механизмов управления шинниками, стоящими на некоторых адаптерах, надо ещё доделывать открытие микросхемы по заданному серийному номеру или описанию, утрясать ключи, поэтому на сайт пока выкладываться не будет.

С amontec jtagkey буду разбираться позже, Если у кого-то есть копия EEPROM этого адаптетра - пришлите, чтобы я мог зашить в имеющуюся платку и попробовать работать.

Да, забыл совсем - win32 / linux (ftd2xx.dll / libftd2xx.so), что там с FTDI под FreeBSD - пока не смотрел (на сайте производителя драйверов под BSD нет, гугл відаёт кучу ссылок, но я пока не вчитывался).

У нас работает под BSD начиня с 4....

На счёт avreal:
Вас не затруднит немного доработать программу
Хочется видеть прогресс выполнения задачи примерно в таком виде:
[________] 0%
[###____] 50%
[######] 100%

А то неудержимо растущее количество точек...........................................................................
................................................................................
.
......
немного пугает

Основная проблема при работе с любыми микросхемами FTDI - безобразно плохие драйвера под Винды. Вместе с багами родных виндовых USB драйверов приводят к периодическим зависам, особенно в условиях импульсных помех. С другими деталями этого не наблюдается.

С какими?
У меня тоже есть неприятный осадок от FTDI
и я тоже склонен грешить на драйвера (с последней версией вроде стало лучше).

Если это поддержка только на уровне того, что дают виндовые VCP-драйвера, т.е. только виртуальный ком-порт, то это не поможет. Если оно для FT232BM даёт bit-bang, то тогда должно пойти.
Там ведь специальные команды для работы через MPSSE и простая модель ком-порта не годится.

Под линукс кроме "родных FTDI-ных" libftd2xx.so, являющихся практически полным аналогом ftd2xx.dll,
есть ещё libftdi, тоже работающая через libusb. Там другое API, но разобраться можно.
Если бы что-то такое было...

И это ещё нет atmega512 :-)
Хорошо, постараюсь в ближайшее время взяться за чистку исходников (ft2232 тоже не самым красивым образом добавлена), тогда и "прогресс" переделаю.

Мы пользовали ISP1581. Драйвера сначала взяли готовые (уж не помню откуда), потом подкорректировали под себя.

На старых дровах регулярно зависали Пролифики. На новых такого нет, а может заземление помогает...

Ну, эта...
Кому надо, кому не надо, это уж разбирайтесь сами.
Пару человек таки подключились к проверке, несколько бякостей мне уже помогли выловить, кое что исправлено, можно пробовать.
На сайте теперь лежит и экспериментальная версия с поддержкой FT2232 1.27rev0.

Вот за это ОГРОМНОЕ ВАМ СПАСИБО!!!
На следующей неделе попробую изготовить программатор на FT2232 + HC244 (пока только идея). Кстати может быть у кого есть готовая схемка? Может сразу его и под JTAG для шитья ARM'ов заточить можно? Выслушаю любые советы по этому поводу.

Для ARM-ов и, насколько я понимаю, блекфинов FT2232 давно заточена, поддерживается OpenOCD.
Я обновил страничку - добавил схему своей макетки и ссылки на готовые изделия на FT2232, с которыми avreal должен бы работать, если я накосячил не слишком много :-)

На следующей неделе проверю работу с Olimex ARM-JTAG-OCD.

2Real: Все же почему бы не сделать свой вариант программатора например на AT90USB16 ? И поддержать в нем заодно HV режим для младших кристаллов. Или если уж так приглянулась FT2232, то сделать совместимым исторически с Альтеровскими. А то на столе не напасешься адаптеров.

У альтеры не FT2232 (или появился какой-то новый "альтера usb-бластер?), а FT245+PLD.
В принципе решаемо и даже стимул появился - опять пошла работа с альтерой и опять на столе появился usb-blaster, но поддержка altera usb-blaster не первоочередная задача по моим внутренним приоритетам.
Тем более, что всё равно часто два адаптера и валются - в одной плате и альтерина, и AVR. В двух разных адапетрах меньше путаницы, чем в двух одинаковых

Наверно, имелось в виду, что в десяти разных адаптерах больше путаницы, чем в десяти одинаковых.

Как сказать
Когда они разные, то "вот этот для плис, вот этот для AVR" решается спинным мозгом, а когда одинаковые, то надо таблички на них вешать или постоянно указывать нужный соответствующей программе, тому же квартусу - какой из усб-бластеров использовать. Впрочем, у меня они выглядят по-разному и представляются по-разному, один как "Altera USB Blaster" (Володя, спасибо, с EP1C3 работает), другой как "Nios development kit" (Костя, спасибо, ну попробовало бы оно с циклоном не работать ).

Как и обещал попробовал новый avreal "Экспериментальная версия с поддержкой FT2232 - v1.27rev0".

Командная строка: "avreal32.exe -aft2232 +mega128 -r flash.hex"
Железо: "Olimex ARM-USB-OCD".
Target: mega128
Время чтения всей flash: 21 сек!
Заработало сразу. Конфигурационный файл не пришлось использовать.
Надо что-нибудь ещё проверить?

Ну какой-нибудь приличный ключик по частоте... Скажем, -o12MHz (если сам кристалл тактируется от 12 и выше, причём даже если там 16МГц, выгоднее ключ -o12MHz давать :-) ) ...
А то 21 секунда это как-то аж стыдно для USB...

По конфиг-файлу:
Там у олимекса есть ещё входные сигналы - SRST зачитывается назад и RTCK, а без конфига на всё выдаются нули.
Поэтому лучше всё же с конфигом
reset=adbus3
enable=adbus4


Ну да, глянул вот свои записи.
На PCI-LPT плате новый навороченный комп под XP - чтение всго флеша 128 меги - около 8 секунд.
Та же PCI-LPT плата, но на старючем пне-166 под 98-ой - около 5 секунд (но там эта PCI-LPT карта даёт не 0,75мкс обращение, а 0,24).

-aFT2232 -o12MHz у меня давали чтение всего флеша меги128 под XP менее чем за две секунды.

-o7300 (до того как кварц на 14,7456 нашёл)
XP - 3сек
W2K - 3.3сек
openSUSE 10.3/64bit - 3.2 сек
ubuntu 7.1 - 3.7сек
(это всё только чтение, полное время с входом в программирование, зачиткой ID и фьюзов, ... - на пол секунды больше).

распиновку дать можете?