AVRdragon против CKDIV8 & DWEN :), Кто кого? Опции

[ReAl]

На внутреннем 128кГц с CKDIV8 дракон не входит в обмен и не может блокировать DW

Подробности про две новости, плохую и хорошую

[SasaVitebsk]

Только что писал прогу. Микруха м48. В прошивке вывел частоту 10кГц на OC2 (совмещён с MOSI). После этого AVREAL и JTAG ICE MK2 в режиме ISP микруху не берут.
AVREALом проблему победить не смог, а вот JTAGом взял таким образом. Выставляешь частоту 100 Гц и выполняешь только операцию ERASE. После этого, естественно, всё работает.

[ReAl]

Только что писал прогу. Микруха м48. В прошивке вывел частоту 10кГц на OC2 (совмещён с MOSI). После этого AVREAL и JTAG ICE MK2 в режиме ISP микруху не берут. AVREALом проблему победить не смог

Мега48, внутренний RC 8MHz

Код

#include <avr/io.h>

#include "pin_macros.h"

#define SCK    B,5,H
#define MISO    B,4,H
#define MOSI    B,3,H


void main(void)
{
    PORTC = 0xFF;
    PORTB = 0xFF;
    DDRB = MASK(SCK) | MASK(MISO) | MASK(MOSI);
    PORTD = 0xFF;

    TCCR2A = (1 << COM2A1) | (1 << WGM20);
    TCCR2B = (1 << CS20);
    OCR2A = 0x7F;

    for(;;) {
        TOGGLE(SCK);
        TOGGLE(MISO);
    }
}

ШИМ, правда, 16кГц получается. Но и так, и без ШИМ - с внесением TOGGLE(MOSI) в цикл, и все ножки по одной, и в разных комбинациях - всё нормально перешивается на нормальной тактовой SPIЮ без занижения.
"Ну не знаю я".

Первый раз, когда прошивал из CodeVision. Поднял фьюзы на внутренний RC-генератор на 128 кГц и сразу "потерял" кристал.

А там разве нет возможности изменить частоту SPI при программировании?

Второй раз на грабли встал, когда установил предделитель частоты ядра на максимум (на 256) при частоте внутреннего RC-гернератора 4.8 МГц. При тактовой 4.8 МГц и предделителе на 8 все работало нормально. Стоило только увеличить коэфиициент предделителя, программатор потерял чип. Вылечил кристалл аналогично.

Аналогично - достаточно изменить частоту SPI.
4.8MHz / 256 ~ 19kHz
avreal32 с ключиком -o15khz и всё перешивается.
Надо снизить нижнюю границу допустимого значения ниже 1кГц, а то 32768/256 = 128Гц :-)

Гораздо интереснее - "а какого".
Даже из-за "безударного" переключения частот (в документации задержка переключения T1 + (1..2)*T2, где T1 - период до переключения) должно было бы успеть, период при 19кГц немогим больше 50мкс, по документации выдержка от сброса до подачи команды входа в программирование 20мс, в avreal все 100мс.
Значит сброс CLKPR производится после снятия сброса в те 14 тактов дополнительной задержки, которые есть даже при 0-вом SUT.
Вероятно, так же и у всех регистров, кроме связанных с IO-портами - не зря там постоянно повторяется, что у портов асинхронный сброс непосредственно по поступлению какого-либо сигнала reset.
Т.е. при подаче сброса только переводятся в hi-z все выводы, но CLKPR не сбрасывается, по снятию сброса отрабатывает SUT, потом в 14 тактов происходит сброс всех регистров, включая CLKPR.
Поэтому при программировании действует оставшееся от программы состояние предделителя.

Из PowerDown АВР выходит больно долго и энергию при этом потребляет. Не считая режима IDLE конечно.

Если работа от кварца - то кто угодно будет выходить долго и печально, так как надо раскачаться кварцу в генераторе и дождаться стабилизации его амплитуды. А от внутреннего RC - по документации старт за 6 тактов и я не замечал отклонений. Мерять время старта я не мерял, но у меня в одном месте контроллер просыпается из POWER DOWN по WDT interrupt с интервалом 250мс приблизительно на сотню тактов - ток укладывается в оценку по скважности исходя из потребления в непрерывном режиме и в POWER DOWN.

[galjoen]

Если работа от кварца - то кто угодно будет выходить долго и печально, так как надо раскачаться кварцу в генераторе и дождаться стабилизации его амплитуды. А от внутреннего RC - по документации старт за 6 тактов и я не замечал отклонений. Мерять время старта я не мерял, но у меня в одном месте контроллер просыпается из POWER DOWN по WDT interrupt с интервалом 250мс приблизительно на сотню тактов - ток укладывается в оценку по скважности исходя из потребления в непрерывном режиме и в POWER DOWN.

При выходе из sleep происходит то-же, что и при запуске процессора. Т.е. если у вас SUT1..0=00, то действительно будет за 6 тактов просыпаться. А в других случаях добавляется 4 или 64 мс. Кстати 6 тактов это уже после делителя CLKPR. Если делитель = 128, то 768 тактов процессор будет просыпаться. А лишний ток при старте конечно только при работе от кварца потребляется.

[ReAl]

250 мс -- это очень редко. Мне нужно эдак разов в 250 чаще щелкать.

Да я видел, что нужно 1мс. WDT меньше 16мс не умеет.
Это я о другом - если бы AVR просыпался из power down так, как об этом говорит galjoen, то при периоде 250мс и задержке просыпания с полноценной жрачкой 64мс потребление очень отличалось бы от того, которое выходит по рассчёту 100 циклов работа, 250мс сон. А оно не отличалось.

При выходе из sleep происходит то-же, что и при запуске процессора. Т.е. если у вас SUT1..0=00, то действительно будет за 6 тактов просыпаться. А в других случаях добавляется 4 или 64 мс.

Это Вы где-то в документации прочли или личный опыт?

У меня стоит SUT=10, т.е. 64мс, так как BOD выключен из-за того, что жрёт, зараза, а питание нарастает не слишком быстро (по осциллографу - где-то за 30-40мс). И при этом процессор потребляет полный ток отнюдь не 64мс из 250мс.

В документации (мега48-168, tiny13, mega128) написано
Для RC-генератора и внешнего тактирования:
Start-up Time from Powerdown and Power-save - 6CK
Additional Delay from Reset (VCC = 5.0V) - 14CK / 14CK + 4.1 ms / 14CK + 65 ms в зависимости от SUT
Т.е. из power down стартует за 6 циклов. После сброса - дополнительная задержка.
Для кварца и кермаического резонатора там другие задержки, нужные для разгона. Дополнительная задержка по SUT та же, она не зависит от источника тактирования.

Кстати 6 тактов это уже после делителя CLKPR. Если делитель = 128, то 768 тактов процессор будет просыпаться.

Меня до сих пор не интересовал предделитель, но считаю, что это не страшно. Он будет просыпаться шесть тех времён, на которые мы уже согласились как на длительность одного машинного цикла, длительность выполнения простой команды. Потом ещё четыре 128-тактовых таких цикла идёт на вход в прерывание, два - на rjmp с вектора на первую команду обработчика, ...
В любом случае это не те "SUT-овые" 64 мс, о которых Вы говорите.

Хотя странно.
У тини13 вообще на блок-схеме делитель не нарисован отдельно.
У меги48 - после мультиплексора тактирования сигнал идёт отдельно на логику сброса, отдельно на предделитель, с которого на clock control unit.
У тини25 - после мультиплексора сначала на предделитель, с него на логику сброса и clock control unit.

Интересно, из этих шести циклов четыре - те же самые, что и при выходе из IDLE (которые тоже отдельные, ещё четыре на вход в прерывание потом само собой), или "аж ещё" дополнительные?
Надо проверить.

[galjoen]

WDT меньше 16мс не умеет.

Проверял, WDT вообще вместо типовых 2.1 секунды при максимальном делителе - от 1.5 до 1.8 имел. Нельзя к нему привязываться если хоть какая-то точность нужна.

Это я о другом - если бы AVR просыпался из power down так, как об этом говорит galjoen, то при периоде 250мс и задержке просыпания с полноценной жрачкой 64мс потребление очень отличалось бы от того, которое выходит по рассчёту 100 циклов работа, 250мс сон. А оно не отличалось.

Это Вы где-то в документации прочли или личный опыт?

Я эксперементировал с кварцем. У меня при SUT-овых 64mc потребление повышалось, но не так сильно, как в рабочем режиме. При работе от внутреннего генератора думаю, что потребление вообще не повысится.

У меня стоит SUT=10, т.е. 64мс, так как BOD выключен из-за того, что жрёт, зараза, а питание нарастает не слишком быстро (по осциллографу - где-то за 30-40мс). И при этом процессор потребляет полный ток отнюдь не 64мс из 250мс.

Я об этом и не писал. Я имел ввиду, что при просыпании расходуется лишняя энергия (это уже из личного опыта). И если ЧАСТО просыпаться, то лучше вообще не засыпать, а использовать CLKPR. То, что время просыпания зависит от CLKPR это точно - проверял. И у меня получилось, что по потреблению энергии выгоднее использовать максимальный CLKPR, чем на 5 мс засыпать. Хотя это для кварца. Для внутреннего генератора времена видимо другие, но на 1 мс думаю засыпать и в этом случае не стоит.

[ReAl]

Я эксперементировал с кварцем. У меня при SUT-овых 64mc потребление повышалось, но не так сильно, как в рабочем режиме. При работе от внутреннего генератора думаю, что потребление вообще не повысится.

А нельзя ли точно сказать - какой был контроллер, какие CKSEL/SUT?
А то мало ли что... Вдруг не туда глянули... Вы говорили о SUT=00, а при каких остальных битах они были?
Вон у меги64/128, меги32, меги 48//168 для кварца/керамического резонатора
при CKSEL0=0
SUT=00 - 258 CK - 4.1ms - Ceramic resonator, fast rising power
при CKSEL0=1
SUT=00 - 1K CK - 65ms - Ceramic resonator, slowly rising power
SUT=11 - 16K CK - 65ms - Crystal Oscillator, slowly rising power
Т.е. разница между SUT=00 и SUT=11 при CKSEL0=1 совсем не во времени дополнительной задержки при сбросе. А разница времени просыпания в 15К периодов резонатора (около двух милисекунд на 7,37МГц), достаточна, чтобы заметить.

Ещё раз:

Из PowerDown АВР выходит больно долго и энергию при этом потребляет. Не считая режима IDLE конечно.

При выходе из sleep происходит то-же, что и при запуске процессора. Т.е. если у вас SUT1..0=00, то действительно будет за 6 тактов просыпаться. А в других случаях добавляется 4 или 64 мс.

Нет. При выходе из power down происходит только задержка на раскачку генератора. Для RC-генератора она установлена в 6 тактов, для керамических/кварцевых гораздо длиннее. Никаких 4 или 65 мс при выходе из power down не добавляется.
Проверьте сами.
Устанавливаем WDT на прерывания, минимальный период - около 2мс.
Перед командой sleep поднимаем ножку, в начале обработчика прерывания опускаем.

Код

MCU = attiny13
FUSES = wdton=1,bodlevel=2,sut=2,ckdiv=1,cksel=2

Для тини13 SUT=2 (0b10) - это 65мс от сброса, 6 циклов от побудки.

Код

#define PDOWN    B,0    // power down indicator
#define REQ    B,1    // interrupt request pin

#define TICK_PERIOD    WDTO_15MS
#define WD_MODE (1 << WDTIE) | (1 << WDTIF)
//#define WD_MODE (1 << WDE)

    .text
    .global main
main:
    outi    ACSR, (1 << ACD)
    outi    PORTB, MASK(REQ)
    outi    DDRB, ~MASK(REQ)
    out    MCUSR, __zero_reg__
    wdr
    outi    MCUCR, (1 << SE) | SLEEP_MODE_PWR_DOWN

    outi    WDTCR, (1 << WDCE) | (1 << WDE)
    outi    WDTCR, WD_MODE | TICK_PERIOD
    sei
1:    sbi    PORTBIT(PDOWN)
    sleep
    rjmp 1b

    .global WDT_vect
WDT_vect:
    cbi    PORTBIT(PDOWN)
    reti

Если бы по прерыванию от WDT выход из SLEEP_MODE_PWR_DOWN зависел от SUT, то у нас при данных FUSES никак на ножке PDOWN не получились бы импульсы с периодом около 2мс. Тогда должно было бы быть около 67мс.
А вот если сделать WD_MODE (1 << WDE), то на ножке PDOWN держится "1" окол 2мс, потом плавно падает в 0 (так как по сбросу нога переходит в hi-Z и к земле тянет входное сопротивления осциллографа), потом около 65мс низкий уровень и опять поднимается на 2мс. Заметьте - при этом фьюзы не менялись, только константа для записи в WDTCR.

[galjoen]

А нельзя ли точно сказать - какой был контроллер, какие CKSEL/SUT?
А то мало ли что... Вдруг не туда глянули... Вы говорили о SUT=00, а при каких остальных битах они были?

Проверял на ATmega64 с кварцем 14.7456.
Фузы были такие:
CKSEL0..3=1111
1й вариант SUT01=11 - 16K CK - 64ms
2й вариант SUT01=10 - 16K CK - 0ms
BOD включена, а остальные фузы значения думаю не имеют.
Пробуждалось от таймера, работающего в ассинхронном режиме от часового кварца, а так-же от WDR.
Пробовал разные варианты с делением тактовой частоты (у ATmega64 регистр XDIV).

При пробуждении от таймера пришёл к следующим выводам:
1. SUT01 =11 или 10 на время пробуждения в этом режиме не влияет
2. При делении тактовой время пробуждения пропорционально увеличивается. В смысле время на эти 16K. Т.е проснутся, с поделённой на 4 тактовой, быстрее чем за 5 мс невозможно.
3. Потребление во время пробуждения, с пониженной за счёт XDIV тактовой, растёт за счёт увеличения времени этого самого пробуждения.
4. Наиболее экономично по потреблению просыпаться без деления тактовой.
5. Но ещё экономичнее вообще не засыпать на 5 мс, а просто делить тактовую на 128 и отключать всё что возможно (компаратор, АЦП, порты и т.д.). Видимо это происходит из-за дополнительных затрат при раскачке кварца. А м.б. что-то другое влияет - не выяснил.
6. М.б. есть смысл в IDLE уходить, но разницы в потреблении я не заметил поэтому так делать не стал

При пробуждении от WDR (а у ATmega64 это эквивалентно сбросу) таймера пришёл к следующим выводам:
1. SUT01 =11 или 10 на время пробуждения в этом режиме влияет (т.е. происходит полноценный сброс)
2. XDIV при этом сбрасывается
3. По потреблению (и точности по времени) этот способ явно хуже, чем пробуждение от часов, поэтому с ним особо не эксперементировал

С процессорами у которых WDR свой адрес в таблице переходов имеет не эксперементировал. Поэтому м.б. мы о разных вещах говорим. Я-то говорил о тех, у которых WDR эквивалентен сбросу. А задержка в 1 мс на пониженной в 256 раз тактовой это не более 40 тактов. Поэтому я писал, что нет смысла в слип уходить особенно если из него по WDR выходить придётся.

[ReAl]

При пробуждении от таймера пришёл к следующим выводам:
1. SUT01 =11 или 10 на время пробуждения в этом режиме не влияет
....
При пробуждении от WDR (а у ATmega64 это эквивалентно сбросу)

С асинхронным таймером, как я понимаю, уход в power save был, который power down + работает асинхронный таймер?
И SUT ведь не влиял?
Так почему Вы говорите, что SUT влияет на время просыпания?

А про WDT у меги - сами же говорите, что это сброс а не побудка, там и должен SUT отработать.

Поэтому м.б. мы о разных вещах говорим. Я-то говорил о тех, у которых WDR эквивалентен сбросу.

Я, конечно, зануда, но Вы говорили о том, что "при выходе из sleep происходит то же, что и при запуске процессора", а не "при сбросе по WDT происходит то же, что и при внешнем сбросе процессора". Со вторым я бы и не спорил.

[galjoen]

1. С асинхронным таймером, как я понимаю, уход в power save был, который power down + работает асинхронный таймер?

2. И SUT ведь не влиял?

3. Так почему Вы говорите, что SUT влияет на время просыпания?

4. А про WDT у меги - сами же говорите, что это сброс а не побудка, там и должен SUT отработать.

5. Я, конечно, зануда,
6. но Вы говорили о том, что "при выходе из sleep происходит то же, что и при запуске процессора", а не "при сбросе по WDT происходит то же, что и при внешнем сбросе процессора". Со вторым я бы и не спорил.

1. Совершенно верно.
2. Я пробовал SUT=00 ставить (1K тактов на раскачку). Просыпался быстро, но некорректно т.к. этот режим для керамического резонатора.
3. От SUT кол-во тактов раскачки зависит. Т.е. время просыпания. Когда я это писал, о работе от встроенного генератора, как и о t13, речи ещё не было. Обсуждались АВР вообще.
4. Совершенно верно, но WDR можно использовать для побудки, если в ОЗУ достаточно длинный ключ писать, а при пробуждении проверять, что от WDR проснулись и этот ключ.
5. Видимо мы с вами одной крови.
6. Был неправ. Надо было написать "при выходе из sleep происходит то же, что и при запуске процессора, за исключением задержки Tr, если таковая имеется".