Логично. Учту. 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-битными оно ходит?