Форум РадиоКот

В связи с тем что новая версия MEGA48 с индексом PA последний байт сигнатуры 0А в отличие от старой 05
программы отказываюся работать через STK200 с MEGA48PA

Может есть программы в которых конфиг можно написать руцами для STK200?

STK500/600/700 не предлагать

avreal - отменить проверку сигнатуры http://www.proavr.narod.ru/07.htm или за 150 рублей купить FT232RL (почта обычным письмом 50 рублей) и через нее дудом прошивать.

По поводу avreal (http://www.proavr.narod.ru/07.htm) ссылки там битые на avreal - ( Возможно, эта страница была удалена, переименована, или она временно недоступна )


ЕСТЬ переходник USB на сом PL2303HL

FUZZY_ писал(а):ссылки там битые на avreal - ( Возможно, эта страница была удалена, переименована, или она временно недоступна )

Там на свалке редко убираются... время на другое много уходит...

К автору лучше - avreal, у него в подписи есть не битый адрес...

Спс-бо!

FUZZY_ писал(а): ссылки там битые на avreal

и в гугле битые ?

Нашел c STK200 работает c avrsp.exe архив с исходниками китайского програмиста с сайта http://elm-chan.org/works/avrx/report_e.html

Вот SPI BRIGE прошивкой (FT232 + tiny2313)

radio-kot писал(а):avreal - отменить проверку сигнатуры.

И зачем эта отмена, если avreal уже больше года знает atmega48pa в лицо? Кстати, сигнатура отличаеется от atmega48/atmega48a, но не отличается от atmega48p, с точки зрения программатора atmega48p и atmega48pa идентичны. Так что можно было шить как atmega48p с ещё более ранних времён. Синоним atmega48pa добавлен в avreal только для того, чтобы меньше вопросов возникало.

Спасибо.

Может я неправильно думал для работы программы необходимы драйвера , а нельзя было использовать IODeviceControl .

( Windows XP, Windows 7 принадлежат другому семейству — Windows NT. Для них необходим драйвер DLPortIO)


В общем буду разбираться с ключами

FUZZY_ писал(а):Может я неправильно думал для работы программы необходимы драйвера , а нельзя было использовать IODeviceControl .

Ну вот не зню почему, но:

В линуксе при указании адреса идёт работа напрямую на порты (как в Win98, но тольо после запроса привилегий и только если программе это разрешено) -- у меня на компе обращение около 0.75 микросекунды.

В линуксе же при указании /dev/parport идёт через IOCTL. На том же компе и на той же плате LPT -- около 1.25 микросекунды.

В XP через DLPortIO -- не помню точно, но что-то в духе 1 микросекуды.

XP через DeviceIOControl -- во-первых, больше 10 микросекунд. Во-вторых, может, я плохо искал, но не до всех ножек смог достучаться.
Да ну его...

Ну если заморачиваться нехотся, то понипрог прошивает 48РА, только игнорируешь все ругательства. Прошивал не однократно.

Отчет об использовании 2 програм : avrxsp32 (Chan) avreal( ver 1.28 Redchuk Alexandr)

1. avrxsp32 написана на VC5 использует GIVIO.sys - тоже написано на VC
2. Чтение доки - 10 мин
3. прога автоматом определила тип адаптера и тип проца и сосчитала код


1. avreal использует DLPORTIO.sys, DLPORTIO.dll
2. Чтение доки и разбирательства с ключами - 30 мин это только чтобы сосчитать код с процессора
3 прога явно запросила тип процессора при чтении кода - что на мой взгляд является неудобством - если имеется не закрытый девайс и хочется узнать тип проца
4 Удобно расписаны фюзы в десятичной системе, и другие удобства

Для этой проги неплохо бы написать конфигуратор для создания bat файла - чтобы по меньше времени тратить на читку доки

По поводу HEX

avrxsp32:

:200B60006500790062006F00610072006400FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA1
:00000001FF


avreal

:100B60006500790062006F00610072006400FFFFA1

:100B7000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF85 - с этими строками непонятка фирмовые программы так не пишут (FF)
...
:100FF000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF01
:00000001FF

FUZZY_ писал(а):3 прога явно запросила тип процессора при чтении кода - что на мой взгляд является неудобством - если имеется не закрытый девайс и хочется узнать тип проца

Рецидив с тех времён, когда AT90S1200 не имела процедуры пересинхронизации и попытка её провести как для at90s2313 и прочих с достаточно большой вероятностью приводила к стиранию сигнатуры. Соответственно, опрос для +90s1200 и для всех остальных производится по разному. А без ключа непонятно как опрашивать.
С тех пор меня эпизодически пинают на тему «забудь о том страшном сне». Пока не допинали

FUZZY_ писал(а):Для этой проги неплохо бы написать конфигуратор для создания bat файла - чтобы по меньше времени тратить на читку доки

avrealshell умеет генерировать батники. Кажется, даже с моей подачи. Но я давно в ту сторону не смотрел и с автором не общался, о состоянии проекта ничего не знаю.

FUZZY_ писал(а)::100B60006500790062006F00610072006400FFFFA1

:100B7000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF85 - с этими строками непонятка фирмовые программы так не пишут (FF)

«Это не баг, это фича». Не знаю, все ли «фирмовые программы» понимают отличие между «в HEX-файле сидят FF» и «в HEX-файле в этом месте пусто».
Те программаторы ПЗУ, с которыми приходилось работать, при зачитке HEX-а всё пустое от своих щедрот считали прописанным FF-ами. В результте дописывание куска сопровождалсь руганью на то, что дописать его невозможно, так как «вот по такому-то адресу надо записать FF (да не надо, я ведь в HEX этот адрес не указал!!!), а в ПЗУ-шке там уже AA». И это дико раздражало, так как приходилось искать в окнах нужное место, выделять его и говорить «запиши только это».
Если рассматривать чтение кристалла как часть операции по получению полной копии, то avreal поступает правильно, записывая в HEX всё, в кристалле-то реально были FF и последующая запись-верификация с этим файлом проконтролирует, чтобы так и было. Он ведь не знает -- те FF просто так или это массив такой, в контрольной сумме прошивки они участвуют или нет. А вдруг записываемый кристалл недотёрся где-то там?

А поскольку я сам считываю редко, то мне эти FFFF-ы и не нудят Так что спасибо за пинок, в TODO заносится что-то в духе «изменить функционльность -r: по умолчанию в выходной файл не писать строки, состоящие из одних FF, старое поведение посадить на -r+»

avreal писал(а)::Рецидив с тех времён, когда AT90S1200 не имела процедуры пересинхронизации и попытка её провести как для at90s2313 и прочих с достаточно большой вероятностью приводила к стиранию сигнатуры. Соответственно, опрос для +90s1200 и для всех остальных производится по разному.
»

Еще один маленький вопросик - у меня насобиралось несколько tiny15 с измененной сигнатурой
(что-то типа 02-01-12, FE-FD-0F )

Можно ли восстановить ихнюю сигнатуру c помощю вашей проги ?

avreal писал(а):Он ведь не знает -- те FF просто так или это массив такой, в контрольной сумме прошивки они участвуют или нет. А вдруг записываемый кристалл недотёрся где-то там?

А EEPROM-то может вообще не стираться, у avreal есть ключ -e-, позже и у AVR добавился фьюз EESAVE...
Для EEPROM различие «FF» и «не задано» ещё существеннее.

FUZZY_ писал(а):Еще один маленький вопросик - у меня насобиралось несколько tiny15 с измененной сигнатурой (что-то типа 02-01-12, FE-FD-0F )
Можно ли восстановить ихнюю сигнатуру c помощю вашей проги ?

Tiny15 ? С ними таких фокусов не видел. Впрочем, через меня их мало прошло.
Нет, я сам не исследовал вопрос о том, какими командами перезаписывается сигнатура и такой информации не видел.
Их можно шить с ключиком -!, битая сигнатура проигнорируется.

Спс-бо.

С сигнатурой дело темное. На китайских сатах есть полные аналоги атмел но сигнатура там другая иможет меняться (и бозначение другое ) цена значительно меньше. В руках вертел некоторые китайские девайсы. Они даже код не закрывают.

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

Я не думаю что они сами чтото разрабатывали - просто сделали копию атмела и раскрутили алгоритмы измения сигнатуры.
Сам Атмел по этому делу молчит как рыба.

Где посмотреть список сигнатур на чипы атмела?