[Gryphus 0]

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

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

Так что, если эту возможность нельзя реализовать на FTDI, то нужен отдельный внешний генератор.

Вопрос, в том, будет ли это надёжно работать? Такт генерируется не программой и, соответственно, он несинхронный с последовательностями программатора.

Edited December 28, 2009 by Арк К

[ReAl 0]

Причём, фузы в кристалле стояли не по заводским умолчаниям.

Это единственно возможное объяснение, тянущее за собой вопрос - "а почему так".

Если бы предпрошитые производителем (и почему-то часть партии попала в продажу) - так там и программа была бы.

 

Так что, если эту возможность нельзя реализовать на FTDI, то нужен отдельный внешний генератор.

Вопрос, в том, будет ли это надёжно работать? Такт генерируется не программой и, соответственно, он несинхронный с последовательностями программатора.

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

Асинхронность не страшна, ну может частота должна быть с небольшим запасом, не ровно в два раза выше частоты SPI, а немного больше. Кварц или внутренний RC ведь асинхронные.

[xemul 0]

Вопрос, в том, будет ли это надёжно работать? Такт генерируется не программой и, соответственно, он несинхронный с последовательностями программатора.

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

[AndryG 0]

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

FTxxxx адаптер это здорово ... но на более простых/доступных/"крупных" чипах тоже было бы замечательно.

[Gryphus 0]

... тянущее за собой вопрос - "а почему так".

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

 

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

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

Всё-таки этот режим чрезвычайно полезен

[acorn 0]

внутреннего такта FT232R может быть слишком много по частоте

Недавно столкнулся с проблемой: выдаваемый FT232R клок 12MHz был необходим для тактирования MCU. В плате был разведен один из CBUS выводов FT232R в надежде вывести нужный сигнал на нужную лапку с помощью переконфигурации EEPROM, как оно в доке и обещалось.

По факту вывести этот клок удалось только на одном выводе (CBUS3 вроде) при любых вариантах конфигурации, т.е. либо CBUS3, либо нигде.

Поделка разовая, вспомогательная, так что разбираться в причинах не стал, порезал дорожки, но запомнилось.

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

По факту вывести этот клок удалось только на одном выводе (CBUS3 вроде) при любых вариантах конфигурации, т.е. либо CBUS3, либо нигде.

Выводил на CBUS2, работало. Но проблема была с тактированием процессора от этого сигнала. Предполагаю, что при инициализации FT232R этот сигнал генерится с более высокой частотой, чем указана в конфигурации. У меня процессор с ума сходил - пропускал некоторые команды в стартап-коде. Пришлось на процессор кварц повесить. Цифрового осциллографа не было, убедиться в правильности гипотезы не мог. Но кварц на процессоре снял проблему.

[acorn 0]

Выводил на CBUS2, работало. Но проблема была с тактированием процессора от этого сигнала.

С номером CBUS могу и ошибаться, сейчас лень по плате смотреть, от которого я клок в конце концов взял, но описанной проблемы не встретил. Устройство это есть и работает (в единственном экземпляре, правда), пользуюсь постоянно, глюки, думаю, заметил-бы. Процессор там atmega162-16 с питанием от USB и клоком от FTDI, кварца нет.

[ReAl 0]

Вышла новая версия 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]

Вышла новая версия 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 100]

В 64х разрядной dlportio.dll отсутствует функция DlPortWritePortBufferUchar, есть только DlPortWritePortUchar.

нельзя ли поправить так чтобы использовалась DlPortWritePortUchar если не найдена DlPortWritePortBufferUchar?

[ReAl 0]

В 64х разрядной dlportio.dll отсутствует функция DlPortWritePortBufferUchar, есть только DlPortWritePortUchar.

нельзя ли поправить так чтобы использовалась DlPortWritePortUchar если не найдена DlPortWritePortBufferUchar?

Ткните пальцем в 64-битную dlportio, а то у авторов лежит только та старая.

 

Поправить можно, как и прикрутить любую другую, которая работает под 64-битными ОС.

[_pv 100]

Ткните пальцем в 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]

Отвлекли на мной же заведённое правило - в выходные вечером все вместе смотрим очередной фильм из завалов.

 

Только, это похоже не 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 100]

Да, я тоже уже доискался до этого имени, где-то даже прозвучало, что оно не полностью совместимо с 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