А я не о новичках. Я хотел предложить другую идеологию программатора.
см. выше

Хи...
А для профи - AVR910,STK500, AVRISP и пр., пр.
А, например, AVRDUDE куда отнесете? Он ведь все эти железяки видит и понимает
Так за что боремся?
Народ достаточно крут, что STK200/300 & AvReal уже не устраивает, но недостаточно крут, чтобы купить STK500 или AVRISP (или что там сейчас мощнее)???
[ничего личного]
Просто не совсем понятна цель этих мнээ....экзерсайсов...
Что на выходе должно получиться?

З.Ы.
Что касаемо параллельного программатора - http://elm-chan.org/works/avrx/report_e.html - это очень утяжеленный вариант?

Столько обсуждать ... а где результат? Похоже на пдсознательно спланированную битву теоретиков ....

Да не будет результата!!! Тема ИЗНАЧАЛЬНО мертворожденная. Где-то в начале топика об этом уже говорили. Здесь хотят создать что-то типа LabTool-48 при стоимости в стакан семечек. Есть AVReal, AS-2(3), AVR910 с массой модификаций, есть AVRISP и всевозможные Пони с Дуди. Люди успешно ими пользуются и довольны их функциональностью. Сколько времени отлаживался(отлаживается) тот же Реал? А он поддерживает только AVRки. Здесь же шить хотят чуть ли не ВСЁ последовательное. Сколько это будет отлаживаться? Правильно. Через неделю эксплуатации снова вернемся к старому другу, который, как известно, лучше новых двух.

У меня между прочим есть результаты и девайс рано или поздно оформлю. Между прочим, память программ и память данных ATmega16 я уже программировал. А для бит конфигурации ещё не добраля потому, что нужно оживлять графический интерфейс для них в GTKmm (т.е. разбираться с классами графической библиотеки, на что требуется время.) Сразу ещё хочу ввести поддержку I2C и SPI - интерфейсов (опять же всё дело в GUI). Так что, возможно весной что-то вывешу. Торопиться некуда: мою идеологию не поддержали...

Зачем изобретать то, что уже давно есть и поддерживается самим Atmel'ом?
http://gandalf.arubi.uni-kl.de/avr_project...tool/index.html
проект совмещающий JTAGICE и AVRISP на одной плате.

Если Вам просто интересно сделать именно свой программатор, то посоветую предельно упростить аппаратную часть устройства, вплоть до того чтобы протокол общения со стороны компьютера сводился к паре команд например R-чтение, W-запись, и передаче в Hex формате тех данных которые надо выдать через ISP или JTAG. Далее просто создать базу известных MK с возможность произвольного ее нарашивания и возложить всю основную часть работы на ПО программатора, который

Зачем изобретать то, что уже давно есть и поддерживается самим Atmel'ом?
http://gandalf.arubi.uni-kl.de/avr_project...tool/index.html
проект совмещающий JTAGICE и AVRISP на одной плате.

Если Вам просто интересно сделать именно свой программатор, то посоветую предельно упростить аппаратную часть устройства, вплоть до того чтобы протокол общения со стороны компьютера сводился к паре команд например R-чтение, W-запись, и передаче в Hex формате тех данных, которые надо выдать через ISP или JTAG. Далее, просто создать базу известных MK с возможностью произвольного ее нарашивания и возложить всю основную часть работы на ПО программатора, которое будет выполняться на компьютере. В присоединенных картинках мой вариант, GUI программатора и редактора базы. Само же устроство получилось по схеме почти идентичным с AVRProg, MAX+AT90S2313.

А кто сказал, что я зацикливаюсь на атмеле. И делаю девайс только для программирования в последовательном режиме. И вроде бы речь шла о разработке программатора с открытым исходным кодом.
И почему-бы не сделать поддержку мастеров для SPI и I2C - устройств. Почему- бы не попытаться расширить функции программатора до программирования Cygnal- процессоров через JTAG (благо силикон- лаб распространяет программу для программирования своих процов в исходных кодах опятьже под консоль). Между прочим PIC - процессоры тоже неплохая вещь. Между прочим процы от разных фирм- производителей трудновато подвести под одну гребёнку т.к. разные среды разработки, разный формат выходных файлов.
Насчёт предельного упрощения аппаратной части устройства: PonyProg : ни путёвого источника программирующих напряжений, ни понятия о таймингах временных диаграмм.

Наздоровье, я ведь не пытаюсь запретить Вам делать то, что Вам интересно.
электрически названные Вами МК и МП имеют если не одинаковый, то очень схожий набор сигнальных линий. Поэтому еще раз обращаю Ваше внимание на то, что устроство программатора должно быть по возможности максимально "тупым" и прозрачным для ПО, исполняемого на ПК.




Неправда, практически все известные мне среды разработки позволяют генерировать bin или hex форматы. Так что со стороны сред разработки проблем с совместимостью нет.



PonyProg это подобие программатора, да и вообще все, что через LPT порт - от лукавого. Говоря о пределно простой аппаратной части, я имел ввиду немного не это. Я имел ввиду простоту и универсальность протокола общения с устройством программатора. Поясню. Аппаратная часть должна обеспечивать поддержку интерфесов JTAG, ISP, ICSP, I2C и других, которые Вы хотите в него заложить, на физическом и канальном уровне, т.е. - электрическую совместимость и сигнальную совместимость (задержки между сигналами и т.п.). Со стороны же связи с компьютером должен быть предельно простой и универсальный протокол. К примеру, если на устройство подать команду $R300000CR то соответственно по выбранному интерфейсу программатор пошлет байты 0x30, 0x00, 0x00 и прочитает байт ответа. Байт ответа потом перешлет на компьютер. А уж что с этим байтом будет делать ПО программатора, это дело ПО.


PS: лучше бы направили Ваши усилия на разработку отладчика способного работать по debugWire.

Сообщение отредактировал defunct - Jan 31 2006, 20:17

Здравая мысль на мой взгляд, хоть и немного не в тему.

А что касается УНИВЕРСАЛЬНОГО программатора, т. е. под если не под все, то, по крайней мере под большое количество контроллеров и интерфейсов, то у меня мнение следующее (и судя по ответам в этой и других ветках оно популярно):
- набор специальных инструментов удобнее, проще, дешевле, надёжнее и т. д. и т. п., нежели одно универсальное;
- всегда найдётся случай, когда универсальное средство его не перекрывает имея явную избыточность для других случаев, которые, возможно, никогда не наступят;
- в случае поломки универсального инструмента вы лишаетесь ВСЕГО, а не части;
- ...

Простейшие примеры из жизни подтверждают моё мнение, хотя возможны и противоположные случаи.

Думаю, что стоит поддерживать именно стк500, все-таки это стандарт, на него ориентируется куча софта, и это очень удобно во всех отношениях
Меньше меги8 брать нет смысла, делал этот протокол, там нужен буфер в 256 байт, меньше его не сделать, команду вывели из поддержки
Оставаться лучше именно на FT245, только если взять новый FT245R
Но тогда возникает вопрос - а что делать-то, ведь проект уже есть
P.S.
Нужна помощь с немецким - спрашивайте, переведу без проблем

Как ни есть в точку .
Фактически нужен выносной LPT порт (или его обрубок), т.е без всякого нижнего софта.
А веревками должен дергать верхний софт с компа, где и будет зашит весь алгоритм программирования всех девайсов, которые хотелось бы поддержать и для добавление новых девайсов нужно будет обновлять только верхнее ПО.

Да нет, в таком софте особого смысла нет, если только не написать универсальный драйвер виртуального порта, который будет отлавливать обращения всяких "родных" систем разработки вроде AVRStudio, MPLAB IDE и того же IAR и выдавать себя за "родной" же программатор. Вот тогда будет вам и СТК500, и джитаг однопроводной, и вообще все что угодно

Для примера: результатом работы AVRstudio является *.hex - файл для памяти программ, *.eep (тотже хекс) - для памяти EEPROM и какой- то ещё один для бит конфигурации. MPLAB - гененрит один *.hex - файл (по крайней мере для PIC16), где зашиты по определённым адресам и сегмент кода и EEPROM и биты
конфигурвции.
Мелочь - а неприятно.

Сообщение отредактировал Yra - Feb 1 2006, 17:06

Насколько мне изветно, AVR-Studio не генерирует никакого файла для "бит конфигурации" по причине полного отсутствия в этом надобности. Не знаю как Вы, но Locks и Fuses я предпочитаю устанавливать самостоятельно, поэтому даже если бы что-то там и генерировалось, то его можно было бы просто игнорировать. MPLAB генерирует стандартный hex, и он по принципу "как есть" заливается в PIC, PIC сам "разруливает" по адресам, что и куда класть (в FLASH/ROM или в EEPROM), иначе можны было бы запутаться с его организацией памяти (14-бит на слово).
Поэтому не вижу никаких неприятностей.

Сообщение отредактировал defunct - Feb 2 2006, 04:25