ещё раз, если у меня AVReal лежит в одном месте, а .hex в другом. Я создал .bat в той папке где .hex мой. Мне надо было в файле конфига записать следующее: enable=adbus4,acbus2

Если в батнике создам строку
d:\works\programs\avw-1.27r4\avreal32-1.27r4.exe +MEGA8 -aft2232 : enable=adbus4,acbus2 -o0.1MHZ -ew -v h_alarm.hex

или ещё указать надо путь до .hex моего?

ругается на синтаксическую ошибку в имени файла, папке...

Для 1.27r3 конифг только рядом с bat и hex. Точнее, в той папке, в которой производится запуск батника, так как сам батник тоже может лежать где угодно.

Не должно быть пробелов между ft2232, двоеточием и enable.

Command:
+mega8 -aft2232:enable=adbus4,acbus2
Start address record in HEX file ignor
Adapter enabled
Device connected, mega8 detected
Chip not locked
Device erased
Device connected, mega8 detected
Fuses
OSCCALs = C9 C8 C2 C1
_LOCK = 0xFF
BLB1 = 3
BLB0 = 3
_LOW = 0x3
BODLEVEL = 0
BODEN = 0
SUT = 0
CKSEL = 3
_HIGH = 0xD9
RSTDISBL = 1
WDTON = 1
CKOPT = 1
EESAVE = 1
BOOTSZ = 0
BOOTRST = 1
Programming CODE memory
... done (2.62s)
Verifying CODE memory
... passed
done (2.40s)
Total time 5.5s
Reset pin released
Adapter disabled

Всё, заработало! Ура! Т.е. он мне и показал фьюзы какие выставлены заодно. Т.е. если мне надо теперь любой изменить, конкретно его и меняю? -fCKSEL=f например так. А почему f? 1 не могу?
Т.е. содержимое .cfg enable=adbus4,acbus2 записываю через двоеточие без пробелов как у меня было?
Ещё, как в ИАР кнопочку сделать, чтобы запускался этот батник? Или лучше каждый раз его вручную из файлов запускать?

И, спасибо за отличный программатор!!!

всё, разобрался с ним.
Один вопрос- кто как шьет? просто запускать батник, или можно в ИАР встроить кнопку?

цель program в gnu makefile.

НУЖНО встроить, для того он таким и делался. Только я не пользуюсь IAR-ом, поэтому не знаю, как в него.

Tools->Configure Tools -> New

Да, подключил тул. Спасибо. Только он теперь виден всегда, когда ИАР запускаю. А если другой проект открываю, мне соответственно нужен другой файл для прошивки, а не из прошлого проекта. Как сделать чтобы на разные проекты разные данные можно было в тул добавить?

.bat файлы могут принимать параметры (переменные окружения %1, %2 и т.д). Оболочка ИАРа может передавать имена директорий, файлов проекта и т.д. как аргументы при вызове .bat. Поищите раздел "Argument variables summary" в EWAVR_UserGuide.pdf (Reference information->IDE reference->Menus->Project menu).

Вопрос следующий, возможна ли передача типа контроллера и тактовой частоты из проекта?

Например, создаем программатор в окне Tools->Configure Tools.
В Menu Text: указываем название - AVReal.
В Command: расположение пакетного файла - C:\Program Files\IAR Systems\AVReal32\avreal32.cmd
В Argument: имя программируемого файла, тип контроллера и тактовую частоту - $TARGET_BNAME$.a90 mega8 8000
В Initial Directory: директорию, в которой расположен программируемый файл - $EXE_DIR$

Пакетный файл avreal32.cmd имеет такой вид:

path = C:\Program Files\IAR Systems\AVReal32\
SET NAME=%1
SET CHIP=%2
SET FREQ=%3
avreal32.exe -p1 -ab +%CHIP% -o%FREQ% -e -w -v -c%NAME%
pause

Все выполняется нормально.

Но при явно указаных типе контроллера и частоте это годится только для проектов, в которых использованы именно этот тип и эта частота. Иначе нужно в Argument: менять их значения.

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

Нет, напрямую нельзя. Даже если можно было бы, универсализма все равно не будет - фузы в проектах тоже отличаются. А что вам мешает из этого .bat вызывать другой, который будет в Initial Directory и который будет делать

Пока фьюзы не трогаем, они тут ни при чем. Будет возможность передавать параметры из проекта - будет возможность управлять фьюзами.

Вопрос был о возможности передачи параметров из проекта.


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

Скорее всего нет. Я в каждом проекте держу батник, не напрягает.

Попробовал с дополнительным батником в EXE-директории. Вобщем, вполне терпимо.

Логичнее его держать в директории исходников. EXE можно стереть при перетаскивании проекта. Или можно создать еще одну конфигурацию и придется батник копировать туда тоже.

Логично. Учту. TNX.

Здраствуйте. Вопрос: можно ли в конфигурационном файле менять выводы ft2232 для сигналов MOSI, MISO и SCK?

Нет, нельзя. Потому что эти сигналы прибиты гвоздями к конкретным ногам производителем ft2232.

Я как раз выплыл из кусочка отпуска, грибочки пособирал на высоте до 6 метров над землёй (выше не достал), то-сё, по прибытию полез в avreal

Как уже сказано, переназначать ноги, равно как и поднять тактирование XTAL1 в режиме MPSSE нельзя - это конкретный "аппаратный" режим микросхемы и поменять ничего не получится.

Тут бяка вылезла. Точнее, заметил я это давно и, кажется, где-то об этом уже писал. Но вот только сейчас руки дошли.
Дело в том, что для конфигурирования адаптеров на LPT по умлочанию сигнал enable считется активным высоким уровнем (аналогично mosi/sck/set/power)
К примеру, для байт-бластера указывать надо было бы
enable=~ALF

(для reset и для байт-бластера инверсия ~ не указывается, но тут логика была другая - программатор сам знает, какой уровень активный у программируемого микроконтроллера, у 89s8252, "если бы", уровень сброса высокий, так что ~ говорит только о наличии инвертора между LPT и ножкой контроллера)

А для FT2232 - указывается только нога и считается, что разрешение низким уровнем.
И если вдруг кто-то поставит буферы 74HC126 с разрешением "1"-кой - придётся писать на разрешении инверсию.

Несоответствие, которое хотелось бы убить пока не поздно.
Но всем придётся поменять батники/конфиги/makefile, у кого там где прописано. Нехорошо так на ходу менять умолчания, "см. рис.1" "не наш метод", но...

заодно -aft2232 на -aftdi-mpsse поменять, чтоли... тут ft2232h/ft4232h на подходе...

Ещё вопрос к использующим FT2232
Сейчас FT2232 по окончанию программирования выводится из режима MPSSE и при этом автоматически возвращается
в режим, который был до этого. Как правило, это UART (т.е. если иное не прописано в EEPROM).
Соответствено выводы становятся "UART-ными" - где вход (с внутренней подтяжкой около 200к на питание),
а где и выход.
Буферизованному адаптеру всё равно, небуферизованный будет конфликтовать со схемой.
Если по окончании программирования не выводить FT2232 из битового режима, то можно просто перевести все ноги на вход и таким образом отключить программатор от схемы.
Но ведь при первом включении питания вплоть до запуска avreal FT2232 всё равно будет в режиме UART. Хотя при этом он в некотором смысле и не мешает.

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

"шо делать будем?"

p.s. ft2232H чудненько работает обеими портами, в том числе одновремённо (две копии avreal в разных окнах) не мешая друг другу в смысле времени считывания кристалла. При -o7.37MHz мега128 зачитывается за те же 2.95сек, что и в один поток (на FT2232C - 3.1сек, можно считать, что разницы нет), мега168 - за те же 0.37сек. Ну при 1.5МГц SPI запас по скорости такой, что FT4232H должна в четыре ручья без задержек отрабатывать

Я за перевод в третье состояние. Пока программатор не нужен - и шлейф не воткнут. А вот после программирования выдергивать каждый раз шлейф неудобно.

Т.е. просто переделать так, чтобы оставлять в режиме MPSSE?
Просто не рассчитывать на то, что кому-то этот канал может понадобиться как UART, так как само оно врядли назад вернётся.
В turtelizer или у olimex UART вообще на другом канале.

Хотя... я просто про ключик -az вспомню, пусть работает. При его наличии - не делается возврат в "основной" режим и все выводы "для контроллера" переводятся на входы, светодиоды остаются выходами.
Если в конфиге есть enable, то он тоже останется выходом и будет отрабатывать как обычно.

Всем, привет.
Я раньше то же пользовался AVReal в связке с IAR-ом.
1) В папке с проектом создавал конфигурационный файл "programmer.cfg". У каждого проекта был свой файл конфигурации.
2) В отдельной папке хранил AVReal и батник обрабатывающий должным образом мои запросы.
3) В IAR-е прописывал на горячие клавиши команды: запись, чтение и т.д.
Было очень удобно пользоваться. Не "выходя" из IAR-а можно было прошить (проверить и т.д.) контроллер и получить соотв. диагностические сообщения.
Ни чего особо сложного.

Файлы прилагаю.
В файле IarIdePm.ini в разделе Tools мои команды для IAR.

К сожалению в висте и в семерке, замучился с дровами поэтому перешел на avrdude.
вот пример вывода диагностического сообщения, (дров нет так бы показал что будет после прошивки).

giveio.sys работает в висте и в семёрке? Я где-то натыкался на разговор о том, что под 64-битными giveio.sys тоже не работает.

Да, работает без проблем.
На 64 бита, попытаюсь на выходных проверить.

Подписываюсь 8) Первым делом спрятал от системы лишний COM в еепроме...

Ну вот ™ я же просил четыреста капель пару раз тут и на электрониксе - ткните носом в драйвер, который в висте работает (ну нет у меня висты под рукой и пробовать всё, что шевелится - тоже нет времени).
Да и без этих просьб - неужели тяжело черкнуть пару строк "а вот то под вистой работает" на слишком известную почту (на домен до полугигабайта спама в месяц, судя по адресам - спасибо в основном сайтам, обеспечивавшим он-лайн чтение эх fido7 всем желающим без упрятывания заголовков прогейтованных писем, на два основных адреса - real@ avreal@ - 500..700 спамописем в месяц).

Про giveio - что-то я так и не смог понять, откуда растёт, где прописан. Используется давно в куче мест ещё до появления самих AVR, не говоря уже про avrdude.
Но какого-то "домашнего" сайта я так и не нагуглил, только куча мест для скачивания готового архва с драйвером 1996 года, который побайтово совпадает с тем, что идёт в комплекте WinAVR для avrdude.
Непонятно где живёт и куда ссылаться.


Ну уже решил с -az, добраться осталось.

Кстати, если в eeprom переключить на какой-то fifo-режим, то выходы сами будт в 3-е состояние преводиться при выходе из MPSE, главное чтобы ввод входа RD не использовался в программаторе и был подвязан.

Проверил
Vista 32 bit, Seven 32 bit - работает.
Vista 64 bit, Seven 64 bit - не работает.
Сам пытался найти от куда ноги растут, но пока не нашел. Так же известен как icprog.sys и tvtool.sys
На сколько я понял его написал Dale Roberts.

Зараза.
Ну даже ради 32-битных, под которыми dlportio не работает - имеет смысл. Поставлю в очередь, там работы немного.

А 64 бита остаются под вопросом.

Однако, у Альтеры для LPT тоже грустно
Altera Programming Cable Driver Information
в колонке Windows "Vista (32/64-Bit)" линк на страничку
ByteBlaster II, ByteBlasterMV, and ByteBlaster Driver for Windows Vista 32-Bit
XP-шная колонка тоже имеет в названии "64"
Кто заодно и альтерой мается, но до сих пор про LPT-овский байт-бластер не забыл - под 64-битными оно ходит?

Сегодня протестил dlportio на Vista 32 bit и Seven 32 bit - работает отлично.
Чуть позже попробую на 64 битах.

Программатор ByteBlaster

Ну если на 32 работает и dlportio, а на 64 giveio не работает, то тогда особого смысла в giveio нет. Он есть, не непринципиальный для работы avreal - просто чтобы держать один драйвер тем, у кого giveio и так в работе.

ReAl, хотел спросить, а влияет как-нибудь настройка LPT порта в bios (EPP, ECP, SPP) на работу avreal через dlportio?
Если да, то какие рекомендации?

Я разницы не заметил. Когда-то специально поставил ECP.
Такое впечатление, что появление проблем больше зависит от того, как сложатся звёзды лягут драйвера (причём не только dlportio).

Да, это точно
Хотя последний тест который делал, все встало без проблем, нужно было только перегрузится, причем giveio всегда ставился без всяких проблем и без перезагрузки.
Да и от LPT я уже буду отказываться так как остался только на работе, дома обновил маму на ней уже нет LPT, в понедельник знакомый преподаватель просил USBasp заваять, т.к. то же купили комп для лаб, а LPT порта тю тю.
На 64 бита не завелся dlportio, хотя писали что дрова скомпилированы под 64 бита, на вид не знаю как отличить только размер файлов больше примерно в два раза.

Совсем нет? У меня тоже новый комп на работе на AMD Phenom-II-X3-720, но на мамке оказались штыревые разъёмы и для LPT и для COM,
так я нашёл в закромах выкидыши от старенькой материнки от певого пенька и всё работает замечательно.
Ну и ещё как вариант есть платки рублей по ~300 на PCI с LPT...
И последнее, если решитесь сами ваять программматор, то с avreal замечательно и очень быстро работает
USB программатор на FT2232 (стоит на нём поработать денёк - так обратно на LPT-шный совсем не хочется возвращаться).
С FTDI-шным ведь никаких затруднений не наблюдается ни под одной из версий win. Ведь это правда, ReAl?

Ага, вот только ключ -о не работает, а иногда без него ну никак!!!

Что-то я не понял о чём речь.
Если об этом:
то расскажите подробнее как не работает и что конкретно.

Об этом. В режиме MPSSE нечем этот такт сгенерировать.
В режиме synchronous bit-bang можно (подобно LPT всё вручную формировать), "но всё как-то руки не доходят".

Да, совсем нет на материнке только 1 ком порт, его вывел через разъем. Мультикарту не так просто купить, пару раз проскакивала купил на работу две, домой не хватило
Вот собственно говоря на него глаз и положен сейчас, есть пара ATxmega128A1, а программатора нет.
Есть мысль собрать все в кучу: ARM-JTAG + AVReal-AVR + "что-то свое"-xmega.
Пока обмысливаем что, да как...

А можете дать ссылку или приаттачить архив с установкой для dlportio, который работает в Windows Seven 32 bit?

Нашел решение:

А тонкости установки описаны здесь: DriverLynx DLPORTIO and Windows 7

Если он так нужен - что мешает повесить в программатор дискретный генератор нужной частоты и перемычку на его включение?

И какая-же частота будет для ключа -o0 ?

Частота или будет или не будет вне зависимости от ключа и в соответствии с генератором. -o0 мне пригодилась лишь однажды за пять лет, из-за криво зашитых фьюзов. Я даже эту ножку не развожу с порта программирования, больно нештатный режим 8)
Впрочем, я видимо чего то не понимаю.

Я уже неоднократно писал, что у меня ATMega128 в TQFP-корпусе с заводскими фьюзами шьется только с ключом -о0, даже ReAl не верит, но это так! (ссылка)

Полностью поддерживаю необходимость внешнего тактирования при прошивке. Несколько раз была аналогичная ситуация, последний раз на меге2561 при первом включении-программировании. Помог байтбластер на LPT с проводком на XTAL1 и ключ -о0,32. Причём, фузы в кристалле стояли не по заводским умолчаниям.
Так что, если эту возможность нельзя реализовать на FTDI, то нужен отдельный внешний генератор.
Вопрос, в том, будет ли это надёжно работать? Такт генерируется не программой и, соответственно, он несинхронный с последовательностями программатора.

Это единственно возможное объяснение, тянущее за собой вопрос - "а почему так".
Если бы предпрошитые производителем (и почему-то часть партии попала в продажу) - так там и программа была бы.

Эту возможность можно реализовать в режиме SynchronousBitBang (давно обещал, в ближайшее время таки сделаю) для FT232R и FT2232 (впрочем, у FT232R можно и внутренний такт вывести на свободную ножку).
Асинхронность не страшна, ну может частота должна быть с небольшим запасом, не ровно в два раза выше частоты SPI, а немного больше. Кварц или внутренний RC ведь асинхронные.

Этот случай чем-то отличается от программирования контроллера, тактируемого внутренним генератором?

LPT повторяет судьбу динозавров ... может Real ещё больше разделит на слои свою замечательную программку и она, в один прекрасный момент, научится общаться с AVR910 (это я на программатор от Prottoss намекаю )?
FTxxxx адаптер это здорово ... но на более простых/доступных/"крупных" чипах тоже было бы замечательно.

хто ж его знает, взятый из пакетика чип, новый. может статика какая


Будет вообще супер! Только внутреннего такта FT232R может быть слишком много по частоте, как показал последний опыт (пришлось ещё делить частоту)
Всё-таки этот режим чрезвычайно полезен