Gryphus 0 28 декабря, 2009 Опубликовано 28 декабря, 2009 (изменено) · Жалоба Я уже неоднократно писал, что у меня ATMega128 в TQFP-корпусе с заводскими фьюзами шьется только с ключом -о0, даже ReAl не верит, но это так! (ссылка) Полностью поддерживаю необходимость внешнего тактирования при прошивке. Несколько раз была аналогичная ситуация, последний раз на меге2561 при первом включении-программировании. Помог байтбластер на LPT с проводком на XTAL1 и ключ -о0,32. Причём, фузы в кристалле стояли не по заводским умолчаниям. Так что, если эту возможность нельзя реализовать на FTDI, то нужен отдельный внешний генератор. Вопрос, в том, будет ли это надёжно работать? Такт генерируется не программой и, соответственно, он несинхронный с последовательностями программатора. Изменено 28 декабря, 2009 пользователем Арк К Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ReAl 0 28 декабря, 2009 Опубликовано 28 декабря, 2009 · Жалоба Причём, фузы в кристалле стояли не по заводским умолчаниям.Это единственно возможное объяснение, тянущее за собой вопрос - "а почему так". Если бы предпрошитые производителем (и почему-то часть партии попала в продажу) - так там и программа была бы. Так что, если эту возможность нельзя реализовать на FTDI, то нужен отдельный внешний генератор. Вопрос, в том, будет ли это надёжно работать? Такт генерируется не программой и, соответственно, он несинхронный с последовательностями программатора. Эту возможность можно реализовать в режиме SynchronousBitBang (давно обещал, в ближайшее время таки сделаю) для FT232R и FT2232 (впрочем, у FT232R можно и внутренний такт вывести на свободную ножку). Асинхронность не страшна, ну может частота должна быть с небольшим запасом, не ровно в два раза выше частоты SPI, а немного больше. Кварц или внутренний RC ведь асинхронные. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
xemul 0 28 декабря, 2009 Опубликовано 28 декабря, 2009 · Жалоба Вопрос, в том, будет ли это надёжно работать? Такт генерируется не программой и, соответственно, он несинхронный с последовательностями программатора. Этот случай чем-то отличается от программирования контроллера, тактируемого внутренним генератором? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AndryG 0 28 декабря, 2009 Опубликовано 28 декабря, 2009 · Жалоба LPT повторяет судьбу динозавров ... может Real ещё больше разделит на слои свою замечательную программку и она, в один прекрасный момент, научится общаться с AVR910 (это я на программатор от Prottoss намекаю :) )? FTxxxx адаптер это здорово ... но на более простых/доступных/"крупных" чипах тоже было бы замечательно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Gryphus 0 28 декабря, 2009 Опубликовано 28 декабря, 2009 · Жалоба ... тянущее за собой вопрос - "а почему так". хто ж его знает, взятый из пакетика чип, новый. может статика какая Эту возможность можно реализовать в режиме SynchronousBitBang (давно обещал, в ближайшее время таки сделаю) для FT232R и FT2232 (впрочем, у FT232R можно и внутренний такт вывести на свободную ножку). Будет вообще супер! Только внутреннего такта FT232R может быть слишком много по частоте, как показал последний опыт (пришлось ещё делить частоту) Всё-таки этот режим чрезвычайно полезен Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
acorn 0 28 декабря, 2009 Опубликовано 28 декабря, 2009 · Жалоба внутреннего такта FT232R может быть слишком много по частоте Недавно столкнулся с проблемой: выдаваемый FT232R клок 12MHz был необходим для тактирования MCU. В плате был разведен один из CBUS выводов FT232R в надежде вывести нужный сигнал на нужную лапку с помощью переконфигурации EEPROM, как оно в доке и обещалось. По факту вывести этот клок удалось только на одном выводе (CBUS3 вроде) при любых вариантах конфигурации, т.е. либо CBUS3, либо нигде. Поделка разовая, вспомогательная, так что разбираться в причинах не стал, порезал дорожки, но запомнилось. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 140 29 декабря, 2009 Опубликовано 29 декабря, 2009 · Жалоба По факту вывести этот клок удалось только на одном выводе (CBUS3 вроде) при любых вариантах конфигурации, т.е. либо CBUS3, либо нигде.Выводил на CBUS2, работало. Но проблема была с тактированием процессора от этого сигнала. Предполагаю, что при инициализации FT232R этот сигнал генерится с более высокой частотой, чем указана в конфигурации. У меня процессор с ума сходил - пропускал некоторые команды в стартап-коде. Пришлось на процессор кварц повесить. Цифрового осциллографа не было, убедиться в правильности гипотезы не мог. Но кварц на процессоре снял проблему. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
acorn 0 29 декабря, 2009 Опубликовано 29 декабря, 2009 · Жалоба Выводил на CBUS2, работало. Но проблема была с тактированием процессора от этого сигнала. С номером CBUS могу и ошибаться, сейчас лень по плате смотреть, от которого я клок в конце концов взял, но описанной проблемы не встретил. Устройство это есть и работает (в единственном экземпляре, правда), пользуюсь постоянно, глюки, думаю, заметил-бы. Процессор там atmega162-16 с питанием от USB и клоком от FTDI, кварца нет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ReAl 0 21 января, 2010 Опубликовано 21 января, 2010 · Жалоба Вышла новая версия avreal - частично вобрала в себя не дошедшую до релиза 1.27r5, частично новое. v1.28r0 (Wed 2010-01-20) Для выдачи списка подключенных устройств FTDI по -aft2232 -p? уже не нужно указывать хоть какой-то микроконтроллер. Добавлены tiny2313A, tiny4313. Ключ -az для FT2232 оставляет микросхему в режиме MPSSE с выводами программирования, переключенными на вход. Для конфигурируемого LPT-адаптера добавлены группы сигналов led_ok, led_error. Для FT2232-адаптеров поддерживаютя все типы сигналов в конфигурационном файле, включая новые led_ok, led_error. Сигнал enable для FT2232 обрабатывается так же, как и для LPT, необходимо указывать инверсию для формирователей с активным низким входом разрешения. Выдача информации производится без буферизации и при перенаправлении вывода, чтобы при перехвате в IDE было постянное обновление. Игнорируются строки данных HEX-файла с нулевым полем длины (нашёлся компилятор, который спорадически их формирует). Убран ключ -ar, теперь для инверсии сигнала RESET нужно создать соответствующий конфигурационный файл Как уже сказано, переназначать ноги, равно как и поднять тактирование XTAL1 в режиме MPSSE нельзя - это конкретный "аппаратный" режим микросхемы и поменять ничего не получится.Ну, кроме инверсии. Инверсия допускается, т.е. указать sck=~adbus0 теперь можно, а вот sck=adbus6 нельзя. Тут бяка вылезла. Точнее, заметил я это давно и, кажется, где-то об этом уже писал. Но вот только сейчас руки дошли. Дело в том, что для конфигурирования адаптеров на LPT по умолчанию сигнал enable считется активным высоким уровнем (аналогично mosi/sck/set/power) ... А для FT2232 - указывается только нога и считается, что разрешение низким уровнем. И если вдруг кто-то поставит буферы 74HC126 с разрешением "1"-кой - придётся писать на разрешении инверсию. Что непорядок, так как поведение противоположно LPT. Поэтому и версия поменялась, не 1.27r5 а 1.28r0 - теперь надо подредактировать существующие батники/конфиги/..., поставив инверсии перед выводом для сигнала enable. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ReAl 0 31 января, 2010 Опубликовано 31 января, 2010 · Жалоба Вышла новая версия avreal. v1.28r1 (Sun 2010-01-31) Добавлено поддержку FT2232H, FT4232H с возможностью использовать для программирования оба канала с MPSSE. Добавлен ключ -k для ожидания нажатия кнопки на адаптере программирования и соответствующую конфигурационную запись key. Добавлена модификация ключа -os для задания частоты SCK, а не частоты тактирования микроконтроллера. FT2232C/L/D позволяют задать частоты от 6МГц и ниже путём деления этих 6МГц на целое число. Т.е. реально для AVR можно выставить не выше 3. FT2232H с повышенной базовой частотой вообще лапочка - позволяет получить сетку 30/N и приподнять частоту программирования для тактируемых 16..20MHz AVR-ок, а со своими двумя каналами - шить в два ручья. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_pv 78 7 февраля, 2010 Опубликовано 7 февраля, 2010 · Жалоба В 64х разрядной dlportio.dll отсутствует функция DlPortWritePortBufferUchar, есть только DlPortWritePortUchar. нельзя ли поправить так чтобы использовалась DlPortWritePortUchar если не найдена DlPortWritePortBufferUchar? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ReAl 0 7 февраля, 2010 Опубликовано 7 февраля, 2010 · Жалоба В 64х разрядной dlportio.dll отсутствует функция DlPortWritePortBufferUchar, есть только DlPortWritePortUchar. нельзя ли поправить так чтобы использовалась DlPortWritePortUchar если не найдена DlPortWritePortBufferUchar? Ткните пальцем в 64-битную dlportio, а то у авторов лежит только та старая. Поправить можно, как и прикрутить любую другую, которая работает под 64-битными ОС. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_pv 78 7 февраля, 2010 Опубликовано 7 февраля, 2010 · Жалоба Ткните пальцем в 64-битную dlportio, а то у авторов лежит только та старая. нашел здесь: http://ponyprog.sourceforge.net/phorum/read.php?2,501 Только, это похоже не dlportio, a inpout32 ( http://www.highrez.co.uk/Downloads/InpOut32/default.htm ), в который добавлены DlPortWritePort функции для совместимости с dlport, однако нет DlPortWritePortBuffer. Там, кстати, есть исходники этой дллки, я туда добавил требуемые функции, собрал, вроде всё заработало. единственная проблема в том что почему-то работает 1 раз из 10. почти всегда просто выходит ничего не сделав: >avreal32-1.28r1.exe -% -ab -p1 +mega48 -e avreal/WIN32 - AVR controllers LPT programmer by Redchuk Alexandr v1.28r1 (Jan 31 2010 16:43:36) http://real.kiev.ua/avreal bug-reports, suggestions and so on mail to [email protected] Command: -% -ab -p1 +mega48 -e % LPT port number 1 % LPT base address 0x378 % DLportIO.dll succesfully loaded, DLportIO.sys interface activated % LPT write cycle 0.000000ns % ByteBlasterMV found % ByteBlaster adapter mode и все, на этом выходит. иногда, но уж совсем редко еще добавляет Can't allocate memory. но иногда все-таки работает (правда ничего к нему в тот момент не было подключено, но все вроде нормально, ножками дергает): avreal32-1.28r1.exe -% -ab -p1 +mega48 -e avreal/WIN32 - AVR controllers LPT programmer by Redchuk Alexandr v1.28r1 (Jan 31 2010 16:43:36) http://real.kiev.ua/avreal bug-reports, suggestions and so on mail to [email protected] Command: -% -ab -p1 +mega48 -e % LPT port number 1 % LPT base address 0x378 % DLportIO.dll succesfully loaded, DLportIO.sys interface activated % LPT write cycle 2.91ns % ByteBlasterMV found % ByteBlaster adapter mode % MCU oscillator frequency = 0.80MHz % setup 2.63us, hold 2.63us % actual SCK frequency 190kHz Adapter enabled % Reset % PgmOn reply FF FF FF FF % Try 1 to resync by reset pulse % PgmOn reply FF FF FF FF % Try 2 to resync by reset pulse % PgmOn reply FF FF FF FF % Try 3 to resync by reset pulse % PgmOn reply FF FF FF FF % Try 4 to resync by reset pulse % PgmOn reply FF FF FF FF Can't resync Reset pin released Adapter disabled Да, с avreal 1.26 все работает отлично. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ReAl 0 7 февраля, 2010 Опубликовано 7 февраля, 2010 · Жалоба Отвлекли на мной же заведённое правило - в выходные вечером все вместе смотрим очередной фильм из завалов. Только, это похоже не dlportio, a inpout32Да, я тоже уже доискался до этого имени, где-то даже прозвучало, что оно не полностью совместимо с dlportio. % LPT write cycle 0.000000ns % LPT write cycle 2.91ns Да, с avreal 1.26 все работает отлично. Опаньки. Где-то знатная бага пролезла... Буду смотреть diff-ы и, наверное, всё же добавлю проверку на наличие блочной функции и эмуляцию её у себя - чтобы и с непатченной работло. А почему такой жуткий промах с определением времени цикла - непонятно абсолютно. Под XP/32 с изначальной dlportio замеряет ведь нормально. Да, с avreal 1.26 все работает отлично.Значит это всё было под 64-битной ОС (какой?) с обычным avreal-ом и с той доработанной библиотекой. "Задача-64 имеет решение" и это приятно. Пошёл смотреть. .oO Хм... А 1.26r0 или 1.26r3 ? :-) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_pv 78 7 февраля, 2010 Опубликовано 7 февраля, 2010 · Жалоба Да, я тоже уже доискался до этого имени, где-то даже прозвучало, что оно не полностью совместимо с dlportio. Благо исходники доступны и сделать её полностью совместимой с dlport вроде не сильно сложно Опаньки. Где-то знатная бага пролезла... Буду смотреть diff-ы и, наверное, всё же добавлю проверку на наличие блочной функции и эмуляцию её у себя - чтобы и с непатченной работло. А почему такой жуткий промах с определением времени цикла - непонятно абсолютно. Под XP/32 с изначальной dlportio замеряет ведь нормально. Сорри, это мой косяк. когда добавлял DlportWritePortBuffer случайно скопипастил туда DlportWritePort(ULONG port, UCHAR data). получилось DlportWritePortBuffer с параметрами (ULONG port, UCHAR data)... со всеми вытекающими отсюда последствиями. Теперь всё нормально и с 1.28 тоже. в аттаче патченная дллка с исходным inpout32 64х разрядным драйвером, и родным инсталлером от dlport. в дллку было добавлено: UCHAR _stdcall DlPortReadPortUchar (ULONG port){return Inp32(port);} void _stdcall DlPortWritePortUchar(ULONG port, UCHAR Value){Out32(port, Value);} USHORT _stdcall DlPortReadPortUshort (ULONG port){return Inp32(port);} void _stdcall DlPortWritePortUshort(ULONG port, USHORT Value){Out32(port, Value);} ULONG _stdcall DlPortReadPortUlong(ULONG port){return Inp32(port);} void _stdcall DlPortWritePortUlong(ULONG port, ULONG Value){Out32(port, Value);} void _stdcall DlPortReadPortBufferUchar (ULONG port, UCHAR* buff, ULONG cnt){while(cnt--) *buff++ = Inp32(port);} void _stdcall DlPortWritePortBufferUchar(ULONG port, UCHAR* buff, ULONG cnt){while(cnt--) Out32(port, *buff++);} void _stdcall DlPortReadPortBufferUshort (ULONG port, USHORT* buff, ULONG cnt){while(cnt--) *buff++ = Inp32(port);} void _stdcall DlPortWritePortBufferUshort(ULONG port, USHORT* buff, ULONG cnt){while(cnt--) Out32(port, *buff++);} void _stdcall DlPortReadPortBufferUlong(ULONG port, ULONG* buff, ULONG cnt){while(cnt--) *buff++ = Inp32(port);} void _stdcall DlPortWritePortBufferUlong(ULONG port, ULONG* buff, ULONG cnt){while(cnt--) Out32(port, *buff++);} еще могут быть чудеса с тем что исходные Inp32 и Out32 имеют в качестве данных всегда short. следовательно DlPortWritePortBufferUlong(ULONG port, ULONG* buff, ULONG cnt) будет работать не совсем правильно. но для avreal'a вроде не критично. Значит это всё было под 64-битной ОС (какой?) с обычным avreal-ом и с той доработанной библиотекой. "Задача-64 имеет решение" и это приятно. Пошёл смотреть. да, ОС winXP 64. судя по форумам в висте64 этот драйвер тоже работает, все остальное значит тоже должно. DlportIOx64.zip Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться