Здравствуйте
Вопрос к Real.
Если Вы автор, то предлагаю совместно решить один животрепыхающий трабл - прикрутить AVReal к usb интерфейсу. Проблема что у меня уже ни на одной машинке нет LPT

предлагается оформить LPT чтение-запись в пакет и передать моему коду - "USB-трубе" . я его транслирую на другой конец и формирую провода SCK MISO MOSI XTAL1 (если требуетса) RESET +5v (от шины USB если требуется) GND

USB-трубу можно сделать в двух вариантах (предлагается как мне кажется самые простын и доступные решения):
1. FTDI FT2232/232 в режиме GPIO для формирования интерфейса программирования по SPI
2. теже яйца FTDI FT2232/232 как UART -> ATmega -> таргет, в таком случае программатор может станет умнее если это нада.

все что протребуется от AVReala это перенаправить IO из интерфейса драйвера LPT в мою USB-труба библиотеку.

просто писать самому AVReal - это глупо, я тоже считаю что это лучший программатор.

еще вопрос - скоро XMega попроет - там другой протокол программирования -я читал чето мутно очень написано..... AVReal будет допиливатся?

... или добавить в avreal поддержку stk500v2. И тогда огромное количество COM и USB наработок будут поддержаны "авреалом".

Это уже смешно звучит (я глянул в архив почты, как давно я эти слова Вам уже писал ), но я "медленно топчусь в этом направлении".
Но наконец-то уже топчусь, а не примеряюсь.
1.26r0, 1.26r2 - кроме видимых в истории изменений происходит некоторая внутренняя перестройка программы, разделяющая её на слои, которые можно более-менее независимо заменять (первой ласточкой была возможность под W98 работать без dlportio а под линуксом - и напрямую на порты, и через ioctl на /dev/parport ).
Отдельно в уголочке через появившуюся у меня плату с FT2232 в режиме её аппаратного SPI сделан кусок, успешно читающий DEV ID из AVR-ок. Пока только win-версия через родные DLL-ки от FTDI, но с добавлением очередного слоя в avreal прикручивание FT2232 для win-версии будет довольно простым. Как работать с FT2232 под linux/freebsd придётся ещё разбираться.

По xmega первые прочтения документации не напугали, FT2232, как я уже писал выше, должна потянуть. Но сначала надо её прикрутить для обычных AVR, а потом уж начинать пробовать xmega.

p.s. Мне очень неловко, что я так долго всех кормлю завтраками... Особенно учитывая, что пара FT2232 появилась у меня с небольшой задержкой после того, как через пару недель после того, как filur electric в Киеве анонсировал её на своём сайте... Т.е. очень давно. Тьху-тьху-тьху, вроде бы и проблем особых в жизни нет, но руки постоянно не доходят.

что мешает освоить AVRDUDE? работает из командной строки, поддерживает кучу протоколов, в том числе и с USB, есть версия под Windows и Linux.

я тогда просто ответа от Вас не получил, поэтому подумал что это Вам не интересно.

прикрутить к Linux ft2232 я думаю не проблема, я могу обеспечит прозрачность USB-трубы независимо от платформы на уровне IO интерфейса чтоб чтоб Вам с этим не морочится.

ну так я не понял - будем кошку жарить или нет?

ReAL, не собираетесь прикрутить поддержку AT45 микросхем памяти?
И может вынести работу с портом в отдельный модуль со стандартным интерфейсом (dll), чтобы любой желающий мог подключить avreal к специфическому железу.

Типа он вроде как работает, но в случае USB девайсов (по крайней мере под Win) далеко не всегда. Давно правда уже не пробовал, но с год назад как не стучал в бубен кроме разнообразных эффектов ничего рабочего не получил .
При смешной цене всяких оригинальных Atmel-овских USB девайсов и убогих интерфейсов оригинальных-же утилит командной строки, не отказался-бы иметь их поддержку AVReal-ом.

Да интересно, только эти два года как-то странно прошли...


Для вин-версии уже многое готово, говорю же, SPI-процедуры написаны и проверены отдельно, прослойка SPI в avreal дописывается.
Не знаю, что имеется ввиду под IO-интерфейсом, у ft2232 много разных режимов и хотелось бы иметь доступ ко всем её возможностям в чистом виде, а не ограничиваться какой-то моделью.
Поэтому мне кажется лучше под win (по крайней мере начать) работать через родную DLL производителя, потом под линуксом разобраться (с libusb ?).
Мне кажется, что чем "роднее" будет сделана работа для каждой ОС, тем больше возможностей и меньше ошибок.
Ну и хочется самому с этим всем разобраться.

"собираюсь", так как там проблем особых нет. Опять таки, отдельно на коленке по конкретному случаю (для прошивки какого-то информатора на тини26) - только вин-вресия, только байт-бластер, ещё какие-то ограничения - оно уже работало. Причесать и добавить в avreal (как, кстати, и по просьбе одного человека написанный подобным грубым образом программатор at89s51/at89s52) всё руки не доходили.

Стандартные интерфейсы внутри программы, кроме естественного интерфейса к прямому доступу к портам, только сейчас начали вырисовываться.
Но мне кажется, что кандидатами на вынос во внешний модуль могут быть
* Довольно низкого уровня процедуры прямого доступа к портам (чтобы подменить доступ через dlportio на что-то другое), но не совсем понятно, хачем решать эту win-специфическую проблему уходящей в небытие аппаратуры
* Довольно высокого уровня абстракции "SPI-адаптера с расширенными возможностями управления", но тут я сам ещё не решил толком, чего я хочу. И, опять таки, это возможно решит вопрос замены FT2232 на какой-нибудь AlteraUSB-blaster, но никак не поможет прикручиванию выводка USB-программаторов от совместимых с AVR910 и до более навороченных.
Оно надо?
Не знаю, есть ли смысл, позже подумаю.

Да-да-да, но это следующий шаг (только бы не выдохнуться на текущем, как это уже не раз за 10 лет бывало - замирания в работе над avreal на год-два).
Речь о FT2232 идёт потому, что это мало затрагивает построение программы, ориентированной на прямую работу с кристаллом AVR по SPI (при этом слепленной за много лет эпизодическими правками "из того, что было под рукой"), поэтому проще в реализации.

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


Нет.

Т.к. основное программирование проходит через своеобразный SPI и плюс несколько линий на RESET, CS и т.п., то имеет смысл разделить отдельно логику самого программатора (разбор hex файла, карта памяти конкретного устройства) и логику интерфейса программирования (тот самый SPI + дополнительные выводы). Делить лучше в этом месте, т.к. тогда можно хорошо оптимизировать работу с аппаратурой в рамках своего модуля. А аппаратура, в принципе, может быть любая. Хоть простой STK200, может быть что-то по COM-порту (JTAG-ICE), что-то по USB (FT2232 или бюджетный IgorPlug).

Кстати, нет желания открыть исходники?

Вообще говоря да. Только модель работы с LPT soft SPI ( spi_out() spi_out() spi_out() spi_in() для команды чтения байта из AVR) мягко говоря плохо подходит для работы с FT2232 hardware SPI, скорость падает на полтора-два порядка относительно возможной. А модель spi_io(длииииииинный_буфер), более полезная для FT2232, в полтора раза садит скорость при работе с LPT. Поэтому среднему уровню программы, забрасывающему разобранный верхним уровнем HEX в нижний уровень обмена с микроконтроллером, надо кое-что знать и про детали реализации SPI-адаптера (хотя бы на уровне bool block_mode_is_faster() ) и менять подходы в работе с SPI. Чем сейчас и занимаюсь. По LPT-модели (чтобы просто "прокачать канал") FT2232 @ win32 вчера заработала. Но 33-34 секунды на чтение кода из mega168 врядли кого-то устроит.
Ну и фенечек типа переназначения ноги reset и назначения ног для открытия буферов на выходах (по аналогии с mapped adapter для LPT) пока нет, поэтому работа только с "голой" FT2232, без буферов.
Ну и для -o0 нужен будет совсем другой режим работы FT2232, это ещё позже будет.

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

Первый - интерент и так завален паршивыми исходниками. А они паршивые, чесслово. "я бы себя к себе на работу не взял". Время на это выделялось по остаточному принципу и никогда не хватало на большее, чем по быстрячку добавить наболевшее. И начиналась программа тоже как "на коленке слепить нечто для себя для более быстрого и комфортного выполнения пары халтурок", я тогда не собирался застрявать на AVR-ках, внимательно смотрел на 16-битники и поглядывал на ARM-ы (с тех пор валяются так и не впаянные MB90F497 и платка з запущенным на уровне "помахать на асме ножкой осциллографу" S3F441. Но потом и задачи изменились, и оказалось, что 90s4433+90s8515+mega103 и их более новые замены перекрыли чудесно весь спектр задач. Но плохое начало в 98-99 годах не рассчитанной на расширения программы до сих пор дают о себе знать.
Так что "ешьте колбасу пока не знаете, как она сделана"

Второй - не скажу.

Кстати ваши аргументы мне, к примеру, кажутся очень убедительными и .... весьма близкими.

Кроме всего, это ведь простая риторика... Ведь даже если вы выложите в инете исходники, никто ведь не кинется поддерживать ваш программатор. Развивать его. Ведь это труд.

Ну что такое разбор HEX файла? - Два десятка операторов. Если у кого есть есть желание написать - это полтора часа от силы. Разбор командной строки поболее, но тоже не бог весть какя работа. А всё вместе - с обработкой, отладкой, тестированием, вылизыванием, совместимостью - достаточно длительный процесс.

Так что это всё отмазка. Если вы, Itch, захотите, то напишите свой. Что мешает? И что изменят исходники от ReAl?

Кстати, это рядом с третьим аргументом, но он не так важен, как первые два, поэтому я его и упустил.

Был такой UISP (не знаю, может ещё и есть). Появился, судя по прочитанным когда-то логам в его исходниках, где-то в то же время, что и avreal, и Pony - 1998 год. Но тогда был только под линукс, я про него ничего не слышал (если бы слышал, то может и не стал бы писать свой).
С самого начала по линуксовой привычке он был с открытыми исходниками. "Ну и это ему помогло?" В какой-то момент его развитие было, видать, признано не имеющим особого смысла и с нуля был сделан avrdude.

avreal того же возраста и, учитывая сказанное ранее, его пора бы переписать с нуля и по возможности не заглядывая в старые исходники :-) Я честно пытался сделать это в 2002 и 2006 годах. Но отпуск так короток... А после него дела наваливаются с новой силой...

а чем прлох avrdude ?

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