avreal, новая версия (если кому-то это ещё нужно) Опции

[ReAl]

Не знаю, насколько это имеет смысл в свете имеющейся информации о будущем Атмел, но подоспела очередная версия avreal.

Добавлен наконец-то замер времени обращения к LPT для всех ОС и добавлено несколько новых кристаллов.


Кстати, о времени обращения к LPT - поднятый для экспериментов с Win98 старый пень-166 вне конкуренции. Одна и та же физически плата PCI-LPT на Q6600/ASUS M2N-SLI что под XP, что дос-версией при загрузке с дискетки даёт около 0,75мкс/обращение (программный замер достаточно хорошо совпадает с замером по осциллографу), а на том старом пне - около 0,25мкс. Одна шина PCI, никаких лишних мостов по дороге, простота...

[Itch]

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

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

[ReAl]

и логику интерфейса программирования (тот самый SPI + дополнительные выводы). Делить лучше в этом месте, т.к. тогда можно хорошо оптимизировать работу с аппаратурой в рамках своего модуля.

Вообще говоря да. Только модель работы с 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 годах не рассчитанной на расширения программы до сих пор дают о себе знать.
Так что "ешьте колбасу пока не знаете, как она сделана"

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