[Dimonira 0]

STK500 может хранить настройки наряжений таргета и Aref. Также вероятно должен хранить последнюю установленную скорость SPI. Насколько помню эти параметры не сбрасываются при вкл/откл питания. (уточню вечером).

А как можно это проверить? Я когда смотрел лог обмена, так софт вроде устанавливает кучу параметров, потом читает проверяет. Разве есть там возможность только прочитать "состояние"?

Из отрицательных сторон (так сказать доп. хлопоты) - лишний пин на разъеме, плюс некоторые программаторы могут блокировать работу когда видять Vtaget 0. (программаторы всмысле soft работающий с STK).

Какой лишний пин? Напряжение target заводится на разъём ISP и на 10-пиновый и на 6-пиновый.

А напряжение то я как раз измерять буду, т.е. как раз буду давать результат измерения на запрос. Или я не очень понял о чём речь?

Я бы порекомендовал не заморачиваться программным SPI в первой реализации. Официальные прошивки AVRISP и те их не особо жаловали (по крайней мере версии 1.02-1.04 точно, на них пробовал) - установить давали, а на деле работало минимум 28.8k.

Т.е. получается, что частоты ниже "не востребованы"? А как вообще определяется что надо софту выставить? Это ручная настройка оператором или там какая-то автоматика в зависимости от чего-то?

 

Ну, ADuM - понятно, дороговато только. Про ADG330x тут что-то нехорошее писали, применяли их раньше? Из собственных воспоминаний по даташиту - питание с одной стороны должно быть всегда больше чем с другой. А наличие вторичного источника многое объясняет, спасибо.

Возвращаясь к ценам. Прошлый раз наврал малость, на самом деле дешевле. Сегодня как раз ездил в Элтех забирать кое-какие деталюшки. Так вот ADuM1201 ~73р, ADG3304 ~57р, DC/DC-шка типа AM1DR-0505SH30Z (на 3kV оказалась существенно дешевле чем на 1kV) ~110р, а типа P6CG-0505ELF ~143р. Так что имхо не дорого.

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

[defunct 0]

Какой лишний пин? Напряжение target заводится на разъём ISP и на 10-пиновый и на 6-пиновый.

Стандартного разъема. Но в реальных устройствах бывает нежелательно либо некуда прилепить VTarget.

 

А напряжение то я как раз измерять буду, т.е. как раз буду давать результат измерения на запрос. Или я не очень понял о чём речь?

Речь о том, что например я редко где вывожу Vtarget и меня очень напрягает когда студия или какой-то другой программатор / отладчик начинает кривляться, мол шить ничего не буду т.к. у вас Vtarget 0. Свое неудобство устраняю так - вешаю вход Vtarget адаптера на его Vcc через резистор 510om и все остаются довольны. Кто сталкивался с подобным меня поймет.

 

Т.е. получается, что частоты ниже "не востребованы"?

В стандартных применениях - internal osc с заводскими настройками / шустрый кварц - да - не востребованы.

 

А как вообще определяется что надо софту выставить? Это ручная настройка оператором или там какая-то автоматика в зависимости от чего-то?

Ручная (если программатор не может связаться с МК он выдает сообщение чтобы проверили частоту).

[Dimonira 0]

Мда. Вчера поздним вечером был пробный запуск. Коммуникация со студией заработала на ура, программатор увиделся и опознался.

А вот когда попытался считать фузы с AT90S2313 (его взял как подопытного), то не входилось в режим программирования - ошибка, по которой ясно, что пробежав все циклы так ничего и не получилось. Буду разбираться...

Правда у меня AT90S2313 на выносной платке от ПониПрога, с навесным колхозным монтажом, кварц сантиметрах в 5 от кристалла. Может из-за этого, т.к. программатор Prottossa (в исполнении МастерКита) тоже как-то нестабильно считывал биты.

[defunct 0]

А вот когда попытался считать фузы с AT90S2313 (его взял как подопытного), то не входилось в режим программирования - ошибка, по которой ясно, что пробежав все циклы так ничего и не получилось. Буду разбираться...

Не начинайте с AT90!!

У них отличается алгоритм прошивки!

Стартуйте с любой Mega/Tiny - у всех одинаковый алгоритм!

[Dimonira 0]

Хорошо, попробую. У меня просто нет готовой платки с контроллером, только эта фигня от ПониПрога. Попробую на неё пристроить тиню.

[Dimonira 0]

Байда какая-то. Не входит в режим программирования и всё тут. Посмотрел осциллографом, все сигналы на программируемый контроллер (Тини85) приходят, но на его линии MISO железно стоит единица и всё. Ноль реакции.

Спаял по-быстрому второй программатор (подумал мало ли что с железом), - те же яйца.

Кстати, второй программатор почему-то не захотел программироваться программатором Prottoss-а, тоже не мог войти в режим программирования. Зато AvReal-ом (байт-бластер с параллельного порта настольного компьютера) зашился влёт без проблем.

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

И, кстати, ещё такой вопрос: пока не наступила синхронизация (не вошёл в режим программирования), контроллер будет выдавать хотябы что-то с MISO или нет?

[defunct 0]

И, кстати, ещё такой вопрос: пока не наступила синхронизация (не вошёл в режим программирования), контроллер будет выдавать хотябы что-то с MISO или нет?

Что значит пока не наступила синхронизация?

алгоритм программирования следующий:

1. Установить резет в 1 и 100ms подождать.

2. Установить резет в 0 и 20ms подождать.

3. послать последовательность 0xAC 0x53 0x00 0x00 (вход в режим программирования).

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

0x000: 0x1E (indicates manufactured by Atmel).

 

пункт 4 можно оформить например так:

 

long readSignature( char len )
{
    long signature = 0;
    len &= 0x3;

    do
        spiTransfer( 0x30 );
        spiTransfer( 0x00 );
        spiTransfer( len );
        signature <<= 8;
        signature |= spiTransfer( 0x00); // <-- read signature (здесь гарантировано на MISO должен меняться сигнал).
    while(len--);
    return signature;
}

 

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

[Dimonira 0]

Заработало! Пока читаю сигнатуры, фузы. Остальное не пробовал.

Как иногда бывает, сказалось одновременное наличие нескольких факторов, поэтому и возник клинч:

1. Я пытался работать с новой Тини85 на максимальной скорости SPI для AVRISP = 960кГц. А она, когда новая, настроена на внутренний RC-генератор 8МГц, но и ещё с делителем на 8, т.е. итого на 1 МГц. Так что работать надо было на 230кГц или ниже.

2. Я ошибочно полагал или скорее не доглядел (и в чужих исходниках), что номер байта, который надо запомнить при обмене по SPI нумеруется не с нуля, как обычно подразумевается в Си, а (в протоколе STK500) нумеруется начиная с единицы. Отловил программно. Это было и для команды CMD_ENTER_PROGMODE_ISP (pollIndex), и для команд чтения битов (параметр RetAddr).

3. Оказалось, что при использовании преобразователя уровней (у меня ADG3304) надо сделать подтяжку MISO на "наружной" стороне, т.е. на стороне программируемого контроллера. Возможно, подтяжку на том же выводе контроллера программатора тогда делать не обязательно (имеется в виду программно). Потом проверю.

 

Возникли новые вопросы:

Что значит пока не наступила синхронизация?

алгоритм программирования следующий:

1. Установить резет в 1 и 100ms подождать.

Зачем так долго ждать? В даташитах вроде пишется о более чем двух клоках тактовой частоты (если мне не изменяет память). У себя я сделал 10 мс.

Тут ещё вот какая завязка. При своих экспериментах с процедурой входа в режим программирования, я обнаружил, что Студия довольно-таки жёстко следит за временем исполнения своих команд. А времена она задаёт в параметрах этих команд. Я в цикле попыток синхронизации вставил задержку cmdexeDelay между 4-х байтными посылками (хотя может я и не так понял протокол, у других я видел вставление этой задержки в цикл только у одного, да и вообще с задержками у разных вариантов полный раздрай, видимо, из-за того, что протокол написан нечётко и не подробно). И когда для пробы увеличил количество циклов попыток с 32 до 64, то тут же после этого Студия "потеряла контроль" с программатором, видимо не получив ответ вовремя. Так что с "лошадиными" задержками надо тоже быть осторожным.

 

Ещё вопрос по команде CMD_SPI_MULTI. У неё тоже в параметрах есть стартовый адрес байта (RxStartAddr), с которого надо начать запоминание считываемых байтов для выдачи в хост. Так вот он с нуля или с единицы отсчитывается? Если принять аналогию с тем, что я описал выше (п.2), то тоже наверное с единицы. Тем более, что параметры количества передаваемых (NumTx) и принимаемых (NumRx) байт задаются в диапазоне 0-255. Т.е. 256 никак не может быть, а параметр RxStartAddr имеет размерность в байт. Правильно?

[defunct 0]

Зачем так долго ждать? В даташитах вроде пишется о более чем двух клоках тактовой частоты (если мне не изменяет память). У себя я сделал 10 мс.

Дык мы же не знаем какой клок у тагет процессора. Студия ждет достаточно долго ~500ms.

 

Я в цикле попыток синхронизации вставил задержку cmdexeDelay между 4-х байтными посылками

стоп, тут не задержка должна быть, а:

Whether the echo

is correct or not, all four bytes of the instruction must be transmitted. If the 0x53

did not echo back, give RESET a positive pulse and issue a new Programming

Enable command. понятно что "1" пульс должен обладать некой длительностью, и ее можно сокращать либо увеличивать по вкусу (если второе тогда сократить изначальные 100ms до 1ms и увеличивать с шагом 20ms).

 

И когда для пробы увеличил количество циклов попыток с 32 до 64, то тут же после этого Студия "потеряла контроль" с программатором, видимо не получив ответ вовремя. Так что с "лошадиными" задержками надо тоже быть осторожным.

Это сильно много. Достаточно 3-4 попытки. Не зачем мучить чип. Если все Ок то синхронизируется сразу.

[Dimonira 0]

Дык мы же не знаем какой клок у тагет процессора. Студия ждет достаточно долго ~500ms.

Не знаем, но как-то сомнительно, что целевой контроллер работает на 20 Гц тактовой. Я посчитал, что хотябы раз в 10 то уж побыстрее должен.

 

стоп, тут не задержка должна быть, а:

Whether the echo

is correct or not, all four bytes of the instruction must be transmitted. If the 0x53

did not echo back, give RESET a positive pulse and issue a new Programming

Enable command. понятно что "1" пульс должен обладать некой длительностью, и ее можно сокращать либо увеличивать по вкусу (если второе тогда сократить изначальные 100ms до 1ms и увеличивать с шагом 20ms).

Да я не про это. Кстати, импульс не RESET делается, а SCK.

Я про паузу между попытками синхронизации. Т.е. один раз попытался, не вышло, подождал и снова пробуешь. А время это задаётся Студией (протоколом). И задаётся оно равным 25 мс.

Это сильно много. Достаточно 3-4 попытки. Не зачем мучить чип. Если все Ок то синхронизируется сразу.

Это количество задаётся протоколом, - параметр synchLoops команды CMD_ENTER_PROGMODE_ISP. А он передаётся равным 32. Так что я не придумываю, а просто следую протоколу, т.е. беру то значение, которое шлёт Студия. Я пробовал 64 только потому, что не мог понять почему не работает.

-------------------------

Блин, с подтяжкой 10к по MISO с внешней стороны преобразователя уровней, программатор Prottoss-а и с этим экземпляром стал глючить - при верификации зашитого даёт ошибку по нулевому адресу. Пришлось подтяжку пока вынести на панельку с испытуемым контроллером Тини85, поскольку я её отключаю, когда шью сам программатор.

 

----------------------

Нет, всё-таки параметр RxStartAddr в команде CMD_SPI_MULTI стартует с нуля. Так реализовано и у Dopera, и у Tuxgraphics (Petka аналогично).