Возможно кому-то будит интересно:
Скоростной AVR USB программатор на FT232RL без вспомогательного контроллера:
http://easyelectronics.ru/skorostnoj-avr-u...a.html#more-268

Здесь некоторое продолжение: http://reddylab.eu/rclab/

Да, такой способ и применяется в "AvrUsb500 by Petka" для первоначальной заливки контроллера. Однако этот процесс оооочень медленный и совсем несовместимый с stk500.
ИМХО более перспективны "программаторы" не на FT232RL, а на FT2232. (смотрите сайт AvReal).

Да, кстати, спасибо - взял в субботу с Вашего сайта пропатченный avrdude, потыкался осциллографом и успокоился
Я уже давно ("очень давно") ткнулся в FT232RL, но мне не понравилась рваная форма SCK - (полу)-периоды скачут по длительности в разы, если не на порядок. Не паузы в пачках, что было бы логично при довольно высокой частоте sync bitbang (надо же и когда-то отправлять данные назад в PC), а чудненький хаос, иногда выстраивающийся в что-то в духе
Поскольку непонятно, не бывают ли они при такой каше изредка короче, что будет приводить к сбою программирования, я не рискнул добавлять поддержку.
Времени мало, ещё пару раз с интервалом в несколько месяцев ткнулся, перепроверил свою тестовую программу, опять потыкался - результут тот же.
Ну а тут взял готовый avrdude, посмотрел осфиллографом - да та же самая каша
Так что чёрт с ней, с кашей. Зря я боялся.

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

зы. Сам пока пользуюсь Вашим, спасибо за разработку.



Автор на своём сайте пишет:


Вроде не сильно медленно.

Тогда снимаю возражение.
Остаётся вопрос по надёжности и совместимости.

Нет-нет, это совсем другой метод.
Там - асинхронный ногодрыг, я его попробовал на FT245 году так в 2002-2003 и плюнул - слишком медленно.
Нет, я ещё подёргался, попробовал из вала поиском выбирать свой "служебный" сигнал синхронизации, передаваемый перемычкой из выходной ноги на входную, но постоянно срывалась синхронизация, так как в этом режиме если включить ввод "валом", то постоянно переполнялись буфера, где-то терялись байты и т.п. А в режиме только вывода с опросом текщего состояния входов каждый бит занимал две транзакции на USB (вывод двух байтов с MOSI и SCK=0, SCK=1 - одна, ввод MISO - вторая).

FT232R/FT245R имеют тот же режим synchronous bit-bang, который есть и у FT2232C+, при нём данные вводятся только вместе с выводом и можно обмениваться длинными пакетами.
Я попробовал почти год назад, сразу после того, как добавил FT2232C, но нарвался на странное поведение, о котором написал тут выше. Ещё тогда я оценил достижимую скорость приблизительно в половину нормального LPT, я на сахаре об этом писал.

Режим будет сделан и будет добавлен также в FT2232, как вспомогательный режим для случая, когда заказана генерация XTAL (-o0).

Только сейчас я застрял на драйверах для win/x64, для win7 и т.п. - см. тему avreal.

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

Привет всем!
Кто-нибудь собрал девайс? Есть баги? Я один вроде нашел...

ЗЫ: Хозяин сайта "радиокот" тут не причём. Я разместил схемы на разных форумах, а мой ник совпал по смыслу с "радиокотом")))))

_На_радиокоте_ (т.е. на том форуме) поблагодарю _хозяина_сайта_ (на котором avrdude взял)
Что-то не так?

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

Рекомендую не большое дополнение к схеме!!! - Для уменьшения паразитных помех на лини приёма UART (COM Port) можно подключить резистор сопротивлением 10К между массой и контактом №15 микросхемы U2 (74HC241). Проверяется просто, включаем любую терминальную программу, выбираем и открываем КОМ-Порт USBBit'a, и трогаем контакты ISP разъёма пальцем. Без этого резистора в порт будет приходить "мусор".
http://www.reddylab.eu/rclab/#ahtung3

Уверен что не ошибся. Или я что-то недопонимаю?

Висячие входа КМОП-микросхем вообще являются дурным тоном. Только в данном случае, учитывая что это сигнал UART'а, тянуть желательно к питанию.

Недавно собрал себе программатор USBBit и тоже обнаружил эту проблему. Хочется попытаться её решить или хотя бы точно понять причины и границы надёжной работы.
Хочу узнать у вас, как у человека, который разрабатывал программу для управления этой FT232R в режиме Sync Bitbang.
1. Верно ли я понял, что рваная форма SCK присуща самой связке драйвер FTDI D2xx - FT232R и вообще не корректируется средствами вызывающей программы (Будь это AVReal, avrdude или элюбая другая)?
2. Чем это может быть вызвано? И кстати, по-моему это противоречит самой идее битбанга, когда мы можем ОДНОЗНАЧНО управлять заданной ножкой порта, и наша задача только успевать её дёргать. Другими словами получается ситуация, когда выводы порта в течение некоторого времени неизбежно выдают мусор, но очень немногие протоколы, думаю выдержат такие сбои в работе. И следовательно, битбанг в FTDI 232r реализовать не смогли (тогда как же они это проморгали?).
3. Почему такая проблема возникает только (а может и не только???) на SCK? За счёт чего тогда этот программатор всё-таки работает?
4. Пробовали ли вы использовать libusb, которая является альтернативой FTDI D2xx?
5. И главное, как надёжно определить скорость программатора для заданной частоты МК (кроме эксперимента)), если в SCK проскакивают эти очень короткие периоды?
6. Правильно я думаю, что именно из-за этой особенности вы не стали поддерживать 232r в AVReal-е? Если удастся найти решение, добавите ли вы поддержку USBbita и прочих программаторов на FT232R?

Про Synchro Bitbang - у FTDI есть особенность в этом режиме, почему то иногда возникают паузы (причем довольно часто) причем не важно в одном пакете по USB данные ушли или нет. Поэтому протокол чуствительный к задержкам в этом режиме не реализовать! Когда только появилась RL серия хотел сделать Silabs C2, но из-за этой особенности не получалось, т.к. в данном интерфейсе клоки объеденены с ресетом.

Но вот протоколы типа SPI прекрасно работают! И AVR программируется и ARM SWD работает и JTAG именно на FT232RL в режиме синхро битанг, т.к. все происходит по фронтам клоков и не должно быть чувствительно к их неравномерности. По край ней мере у меня никаких проблем не возникало.

Собирал исходный вариант, что на изиэлектроникс.
Не пошло в работу, разбираться было недосуг. Дудка ругается... грешил на фт232, но в другом устройстве (интерфейсная схема в DSS-31) заработала безупречно...
КМК сильно недоработанная схема, автору нереспект.