и передает и принимает. Ессно надо заранее данные готовить. В моей версии программатора для АТ89С2051 (https://radiokot.ru/forum/viewtopic.php ... 1#p3472041) только режим возврата дампа в ПК не реализован за ненадобностью/великой ленью тот хекс кодировать для обратной пересылки... А для связи с компом именно terminal и используется. Хош на ХР, хош на 7-10ках.
USB-COM от старых телефонов раньше на базаре у торговцев телефонными аксессуарами были за рубль или за так отдавали в придачу к чему ни будь. Прошивал таким раньше и LPC2103, и внутрь коробочки помещается мега8 в дип и превращается коробочка в программатор AVR STK500v2... RealTerm бинарные данные вроде читал и писал в виде файла https://sourceforge.net/projects/realterm/
ДЫК... Афтор то хочет ГОТОВЫЙ КОПИРОВЩИК или еще похлеще - транслятор дампа в ПК для реверс-инжиниринга получить... Да с ГОТОВЫМ КОМПЛЕКТОМ СОПРОВОЖДАЮЩЕГО ПО.... А не просто набор блочков и подсказки как с ними работать. Тем более, что хош на чем соорудить - анализ все равно для I8080/8085 делать придется. А это или по бинарнику (что черевато контролем CRC16 как минимум) или предкодирование дампа в intel hex8 перед отсылкой в ПК. Причем все это должна приставка САМОСТОЯТЕЛЬНО делать. Задача прожки в ПК только в приеме готовых данных и их записи в файл на диске, пригодный для последующей обработки и обратной отсылки в приставку для последующей обработки средствами приставки (запись скорректированного дампа в ПЗУ). На основе чего ту приставку делать - совершенно без разницы. Ежли уж АВР - предпочтение кристаллам, имеющим аппаратный интерфейс с внешним ОЗУ - мега 8515, мега162, мега128... Программаторы для АВРок со "сторонними" кристаллами непосредственно не работают. Посему также какая-то доработка потребуется, а это в свою очередь проблемы с дополнительным изучением матчасти потянет... Проще всего таки у СОСЕДА-КОТАНА готовый программатор испросить - считать один раз тот дамп и работать с оным. Да и имитатор ПЗУ для отладки в макете можно соорудить - тогда все пробы исключительно с участием имитатора и ПК делаются, пока отладку прожки не завершиш...
ДЫК... Афтор то хочет ГОТОВЫЙ КОПИРОВЩИК или еще похлеще - транслятор дампа в ПК для реверс-инжиниринга получить...
Ну автор хотел пока прочитать - "дык" в теме все для этого есть: 1)схема считывателя исходником на мега8 2)указано место где взять USB-COM 3)проверил - RealTerm действительно захватывает бинарные файлы (пробовал с другого терминала передачу): передавал чисто бинарные данные - получил в готовом файле 4)осталось ерунда - прошивальщик на базе считывателя сделать, если понадобится...
Осталось дождаться решения от топикстартера У мня для этого антиквариата ПОКА еще старый программатор с винь98 лежить, чего делать "по современнее" просто ВЛООМууушкии... Можно и адуринку прикошачить...
пробовал PUTTY, считывет ,в отличие от терминал 1.9 все правильно, но что-то не нашел, как сохранить данные с порта
з.ы. мало ли у кого чего в загашнике - у меня который год Тритон в коробочке лежит (еще по дешевке давно покупался за 200 с лишним $) - 27Cxx ему на раз плюнуть. Там внутри USB-COM на FTDI, и железный COM есть
Одной меги (тем более весьма неудобной в данном приложении меги8 - там байтовых полных 8 битных портов нету) будет явно недостаточно. Надо и минимум три сдвиговых регистра прикошмарить и блок подачи высокого напряжения в соответствии с даташитом... Вобщем... "ГОРОДУШКА" довольно немалая... Стоит ли из-за единичного случая заморачиваться-то??...
1)добавить одну К561ИЕ10 2)или мега328PB или тини48 (у нас в ларьке есть не очень дорого) в относительно новых аврах портов добавили з.ы. в 90 годы был у нас типа программатор К573РФxx (те же 27Cxx) на базе самодельного ПК на К580ИК80. ПЗУ стояла в адресном пространстве процессора, всякие CE OE и напряжение VPP подавались тумблерами. А время программирования задавалось одновибратором - К580ИК80 имел ногу ожидания и мог ждать вечность.
это понятно ,просто я думаю ,что наверняка уже где-то есть такая прога...
Если не умеете программировать и лень изучать и надо один раз, то возьмите простых тумблеров по числу адресных линий + числу линий данных + также тумблеры/кнопки на нужные сигналы управления. Тумблерами адреса выставляете адрес очередной ячейки, тумблерами данных - байт данных, затем подаёте кнопкой (с формирователем длительности) импульс программирования. И так все ячейки. И никаких LPT не надо. Нужны только усидчивость и внимательность.
В общем, в протеусе сделал такую штуку (см. схему в приложенном файле), там все нормально работает и считывает из ПЗУ в файл через COM Port Toolkit 4.0 с использованием виртуального СОМ порта. Логика проги простая - я через СОМ посылаю сигнал - 1 (цифру один) и по этому сигналу схема мне у ответ шлет содержимое ПЗУ.
думал осталось сделать согласование СОМ с ТТЛ (нашёл простые схемы) - и все, т.к. помнил,что СОМ должен был быть на компе, но как оказалось, в итоге - есть только разъем СОМ на материнке, а переходника на ружу корпуса нет. Как контакты разъёма расположены - не знаю, потому и стал интересоваться, как можно вместо СОМ по UART использовать USB, потому и стал спрашивать про дравйвер к УСБ ,позволяющий работать как с СОМ, а подумал так, из-за того, что есть у меня программатор для АВР на УСБ, значит есть и ещё какое-то ПО, позволяющее работать с УСБ.
Просто я до этого не интересовался ни СОМ, ни УСБ, ну не приходилось сталкиваться... тут у меня мало знаний, может что не так понимаю, потому и написал сейчас этот опус, может подскажете, как проще исходя из этих данных согласовать мою схему с USB, а далее я планировал доработать схему и прогу, чтобы можно было и прошить ПЗУ. Скажу сразу, что стирать УФ ПЗУ есть чем.
Т.е. я хотел сделать без переходника, чисто на ПО... Спасибо.
это понятно ,просто я думаю ,что наверняка уже где-то есть такая прога...
Если не умеете программировать и лень изучать и надо один раз, то возьмите простых тумблеров по числу адресных линий + числу линий данных + также тумблеры/кнопки на нужные сигналы управления. Тумблерами адреса выставляете адрес очередной ячейки, тумблерами данных - байт данных, затем подаёте кнопкой (с формирователем длительности) импульс программирования. И так все ячейки. И никаких LPT не надо. Нужны только усидчивость и внимательность.
Я такой вариант уже намякивал - у КОТУИНКО всего-то меняется "прожигающий модуль" (вместо того, что длч АТ89С2051 используется) и соответственно корректировка/доработка программы под заданные мелкосхемы. Однако - ЭТО ДОВОЛЬНО БОЛЬШОЙ ПРОЕКТ, который топикстартеру излишние заботы доставить может, так же как и на 8й меге. Ежли б речь шла хотя-бы о мега8515 и/или АТ89S5x подобных - там хоть какая-то экономия ресурсов за счет аппаратного интерфейса связи с параллельным ОЗУ... Программатор для 32к*8/64к*8 пусть даже с неспешным интерфейсом с ПК и установленный на прожигалке накопитель в виде ОЗУ 64к*8. Когда-то подобные делал... МК "жгучей головы" там задает общий для ячейки адрес и раздельно управляет сигналами чтения/записи для ОЗУ и ПЗУ/целевого МК. НО ... КАЖДЫЙ ИДЕТ СВОИМ ПУТЕМ (особо ежли избрана "темнящая сторона")
Одной меги (тем более весьма неудобной в данном приложении меги8 - там байтовых полных 8 битных портов нету) будет явно недостаточно. Надо и минимум три сдвиговых регистра прикошмарить и блок подачи высокого напряжения в соответствии с даташитом... Вобщем... "ГОРОДУШКА" довольно немалая... Стоит ли из-за единичного случая заморачиваться-то??...
ну это - тоже опыт и знания, я вот до этого ни разу ничего под СОМ и УСБ не делал ) и я не стал делать ток по портам, для адреса - просто счетчики прикрутил, все одно все последовательно считывать надо...
Я такой вариант уже намякивал - у КОТУИНКО всего-то меняется "прожигающий модуль" (вместо того, что длч АТ89С2051 используется) и соответственно корректировка/доработка программы под заданные мелкосхемы. Однако - ЭТО ДОВОЛЬНО БОЛЬШОЙ ПРОЕКТ, который топикстартеру излишние заботы доставить может, так же как и на 8й меге. Ежли б речь шла хотя-бы о мега8515 и/или АТ89S5x подобных - там хоть какая-то экономия ресурсов за счет аппаратного интерфейса связи с параллельным ОЗУ... Программатор для 32к*8/64к*8 пусть даже с неспешным интерфейсом с ПК и установленный на прожигалке накопитель в виде ОЗУ 64к*8. Когда-то подобные делал... МК "жгучей головы" там задает общий для ячейки адрес и раздельно управляет сигналами чтения/записи для ОЗУ и ПЗУ/целевого МК. НО ... КАЖДЫЙ ИДЕТ СВОИМ ПУТЕМ (особо ежли избрана "темнящая сторона")
Т.е. ничего более, чем - купить схему эмулятора СОМ для УСБ - вариантов нет? а если вообще стандартные проги для отправки данных по УСБ, с известным протоколом, чтобы под это можно было ее использовать, конечно при этом погу длдя МК придется писать другую...
пробовал PUTTY, считывет ,в отличие от терминал 1.9 все правильно, но что-то не нашел, как сохранить данные с порта
з.ы. мало ли у кого чего в загашнике - у меня который год Тритон в коробочке лежит (еще по дешевке давно покупался за 200 с лишним $) - 27Cxx ему на раз плюнуть. Там внутри USB-COM на FTDI, и железный COM есть
ну это - тоже опыт и знания, я вот до этого ни разу ничего под СОМ и УСБ не делал )
Никак не могу понять: о каких COM/USB всё время твердите? Зачем они??? Вы ведь говорили, что вам нужно прошить ППЗУ. Прошить, а не прочитать. Зачем для этого COM/USB??? Для этого нужны только много параллельных ног на МК с формирователями высокого напряжения. И ВСЁ! Это если делать на МК.
мне нужно считать прошивку РПЗУ в файл, я не знаю, как это сделать по другому, кроме как через СОМ или УСБ, но СОМ отсутствует -нет переходника с материнки, остается УСБ...
Уже ж повторялось выше - платка адаптера USB-COM отображается в ПК как стандартный СОМ порт. Прожка терминал спокойненько пересылает туда-сюда текстовые и/или бинарные файлы. Задача адаптера собственно преобразование интерфейса (делается за счет прилагаемых к тому адаптеру драйверов). Выход адаптера USB-TTL подключается к соответствующим выводам МК программатора (соответственно rx адаптера к Tx программатора и rx программатора к txадаптера). Никаких там 9-штыревых вилок не требуется. Адаптеры для адуринок выполнены как USB-TTL преобразователи последовательного асинхронного интерфейса. Касательно схемки... Некаврцованую мегу (для удобства интерфейса порта) применять рискованно - большой поток бинарных данных без какой-либо контрольной защиты по асинхронному каналу это весьма .... некорректное занятие. Раскладка разъема СОМ порта на материнке указана в юзерс гвиде на материнку. Помимо прочего его еще и в биос нужно будет активировать. А во внешней платке программатора тогда ставится не USB-COM, а COM-TTL чего-то из st232 или max232 подобных мелкосхем.
Последний раз редактировалось BOB51 Вс фев 10, 2019 12:39:02, всего редактировалось 1 раз.
мне нужно считать прошивку РПЗУ в файл, я не знаю, как это сделать по другому, кроме как через СОМ или УСБ, но СОМ отсутствует -нет переходника с материнки, остается УСБ...
А в исходном сообщении писали о программаторе..... Купите на али простой USB переходник COM-UART, подключите его к любому МК (UART-концом), к этому же МК подключите ППЗУ. Считайте её программно, а содержимое - через UART в комп. Конечно нужно уметь программировать. Но делается за один вечер.
Некаврцованую мегу (для удобства интерфейса порта) применять рискованно - большой поток бинарных данных без какой-либо контрольной защиты по асинхронному каналу это весьма .... некорректное занятие.
Можно применять что угодно. Кварц тоже - не обязателен. Точности RC-генератора за глаза хватает для UART. Какие то "контрольные защиты" - тоже не обязательны. Нет никаких проблем несколько раз считать с ППЗУ и затем сравнить результаты чтений в компе как файлы.
А если в МК достаточно ОЗУ, то и вообще USB-COM не нужен: читаем ППЗУ в ОЗУ МК, а потом оттуда читаем отладчиком в комп через отладочный интерфейс. Даже если недостаточно - можно по частям так считать.
Мне потом нужно будет, после корректировки программа из ПЗУ зашить ее обратно...
В итоге ,я прихожу к выводу, что нужно делать еще одно устройство - USB переходник COM-UART, а думал - обойдется, посмотрел, что нужно для создания хотя бы на дельфях проги под УСБ - будет явно дольше... так что итог - USB переходник COM-UART...
подскажите еще, я пока видел варианты схем переходника только с 12-и мегагерцовым кварцем, и еще - я сделал считыватель ПЗУ без кварца - большая ли вероятность получить неверные данные? имеет ли смысл поставить кварц?
если я потом захочу эти МК перепрошить - то какой кварц нужна будет ему ставить при перепрошивке?
На USB-COM /USB-TTL ПЕРЕХОДНИКЕ СВОЙ КВАРЦ УСТАНОВЛЕН. Этот переходник В ГОТОВОМ ВИДЕ ПОКУПАЕТСЯ. (https://vk.com/market-79970674?section=album_22 к примеру) Речь может идти только о кварце для МК. Ежли есть желание поэкспериментировать - кварц у МК можно не ставить - работать в зоне допустимых погрешностей RC генератора. Стандартная "кроватка"- безнажимка для понипрога/дудки в случае с мегами оснащается кварцем 4 МГц.
ну а все же, на сколько критично считывать данные без кварца? ведь кварц - не та штуку, на которой стоит экономить, тут больше сомнений из-за лени снова в МК фьюзы перепрошивать... если есть шанс получить кривые данные, то конечно кварц поставлю, а если никто обычно кривых данных не получал, это только теретически м.б. - то тогда нет смысла, да и на будущее буду знать, как правильно...
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 66
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
