[kv_addr 0]

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

[Agr0n0m 0]

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

[Сергей Борщ 140]

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

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

[ReAl 0]

Я как раз выплыл из кусочка отпуска, грибочки пособирал на высоте до 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 на подходе...

[ReAl 0]

Ещё вопрос к использующим 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 должна в четыре ручья без задержек отрабатывать

[Сергей Борщ 140]

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

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

[ReAl 0]

Я за перевод в третье состояние.

Т.е. просто переделать так, чтобы оставлять в режиме MPSSE?

Просто не рассчитывать на то, что кому-то этот канал может понадобиться как UART, так как само оно врядли назад вернётся.

В turtelizer или у olimex UART вообще на другом канале.

 

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

Если в конфиге есть enable, то он тоже останется выходом и будет отрабатывать как обычно.

[ZiB 0]

Всем, привет.

Я раньше то же пользовался AVReal в связке с IAR-ом.

1) В папке с проектом создавал конфигурационный файл "programmer.cfg". У каждого проекта был свой файл конфигурации.

2) В отдельной папке хранил AVReal и батник обрабатывающий должным образом мои запросы.

3) В IAR-е прописывал на горячие клавиши команды: запись, чтение и т.д.

Было очень удобно пользоваться. Не "выходя" из IAR-а можно было прошить (проверить и т.д.) контроллер и получить соотв. диагностические сообщения.

Ни чего особо сложного.

 

Файлы прилагаю.

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

 

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

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

AVReal CMD Shell. Версия 2.3.0

- Конфигурация ---------------------------------------

AVReal: "C:\Program Files\MCU\AVReal\avreal32.exe".
Конфигурация: "D:\Test\programmer.cfg".
Команда: "check" - проверка присутсвия МК.

- Ошибка ---------------------------------------------

МК для программирования не найден.

ZiB.zip

[ReAl 0]

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

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

[ZiB 0]

Да, работает без проблем.

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

[Dx! 0]

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

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

[ReAl 0]

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

Ну вот я же просил четыреста капель пару раз тут и на электрониксе - ткните носом в драйвер, который в висте работает (ну нет у меня висты под рукой и пробовать всё, что шевелится - тоже нет времени).

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

 

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

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

Непонятно где живёт и куда ссылаться.

 

 

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

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

 

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

[ZiB 0]

Проверил

Vista 32 bit, Seven 32 bit - работает.

Vista 64 bit, Seven 64 bit - не работает.

Сам пытался найти от куда ноги растут, но пока не нашел. Так же известен как icprog.sys и tvtool.sys

На сколько я понял его написал Dale Roberts.

[ReAl 0]

Vista 32 bit, Seven 32 bit - работает.

Vista 64 bit, Seven 64 bit - не работает.

Зараза.

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

 

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

[ReAl 0]

Однако, у Альтеры для 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-битными оно ходит?