Ну аот, пока раскурил даташит - ты уже готовый пример дал. Разобрался я. CTC работает только по совпадению А, а прерывания по обеим. Так что ставим A=2B и получаем меандр!

Всё верно. Удачи в обучениях.

Спасибо.
Проверил, всё нормально. Вставить только коррекцию на 4 такта на прерывание и возврат из него.

Да. Тут это надо учесть. Иначе он из прерываний не будет вылезать. Если в твоём проекте таймер работает без деления частоты, то в принципе всё готово. Ну а если используется деление тактов через прескаллер, то можно и его сбрасывать СТС режимом, если есть критичность к точности начала первого меандра генерируемой частоты. Ведь подделитель по сути является счётчиком. В даташите должно быть описано, каким битом и в каком регистре это делается или настраивается.

Нет, тут точность не нужна. Посчитал. Предел - 20 тактов (число 20 в регистре A, 10 в B), при этом между прерываниями он выполняет 1 команду основного цикла.
Для опроса кнопок больше и не надо. Соответственно и частота на выходе = csk/20. Если взять кварц на 20 - имеем чистый мегагерц меандра + немного полезной работы
Так же имеем настройку частоты на выходе в плоть до csk/254

Считается кстати просто: 4+4 (вход-выход в прерывание) +1 (команда внутри) + столько-же второе прерывание + команда основного цикла = (8+1) + (8+1) + 1 = 19. Пополам не делится, берём 20.

Намотаю себе на ус. К стати, мы входим в прерывание. Сначала попадаем на вектор, а от туда, через rjmp в сам обработчик. У нас случайно не больше тактов уйдёт на вход в прерывание?
RJMP помоему больше 1го такта съедает + 1 такт на попадание в вектор прерывания ещё до rjmp.

rjmp - два
вход в прерывание - 4
выход - 4
(там операции со стеком)
Точно... Про вектор я и забыл. Но ситуация такая: reti всегда возвращает на следующую команду, которая выполнится, и только потом сработает следующее прерывание.
Во всяком случае при меньших цифрах всё равно по одной команде выполняется внутри цикла (я их даже пометил, чтоб не ошибиться)

Возможно, где-то я и затупил, но у меня вышло следующее, если верить счётчику тактов студии:
4 такта - попадание в вектор.
2 такта - прыжок с него в обработчик.
1 такт - команда внутри обработчика.
4 такта - выход из прерывания.
Итог - 11 тактов на обработку одного прерывания.
22 такта на обработку обоих прерываний.
4 такта в основной программе(4 NOPа) + 2 такта на прыжок (RJMP LOOP) Всего 6 тактов.

Наверное можно включить ещё один такт к обработчику прерывания. Когда в регистре TCNT число становится равным регистру OCR, то флаг прерывания выставляется моментально, но только при следующем такте начинается процесс входа в вектор. Хотя нет. Всё правильно.

Ну да, всё правильно.
В коде у меня стоят цифры 5 и 10, что явно меньше 22х. И всё равно студия между прерываниями обрабатывает по одному нопу. Значит отлично - не обсчитаешься, основной код всегда будет потихоньку ползти. Допустим на те же кнопки и индикацию с лихвой хватит.

Всё... Теперь всё на своих местах....

Может, я спросонок чего-то не понял, но если уже всё равно таймер в режиме CTC (т.е. таймер уже всё равно свёрнут до периода меандра), то зачем прерывания и зачем себя ограничивать по частоте?
При 8-мегагерцовом внутреннем RC отлично генерит меандр 4МГц на OC0A
Я на тини15 с внутренним 1.6 МГц делал управление линейкой S9226, генерировал 0.4 МГц такт аппаратно и синхронно с ним стартовый импульс программно. При этом ещё опрос кнопок для регулирования в +- пероида накопления сигнала и двиганья влево-вправо строба на осциллограф.

Кстати, как раз для той линейки я меандр генерировал несколько более сложным образом. Мне нужна была в программе привязка к фазе меандра, а в режиме инверсии вывода по совпадению значение TCNT0 такой информации не несёт.

Можно установить FAST PWM + CTC, тогда период PWM определяется OCR0A, а на OCR0B получаем ШИМ.
Если в OCR0B занести половинку преиода, опять получим меандр.
Итого код
генерирует три меандра.
OCR0B - 1/2 тактовой частоты процессора
OCR0A - 1/4 тактовой
PORTB7 - 1/8 тактовой.

Если цикл в конце заменить полезной работой. то есть два меандра и полностью свободый процессор.

Было бы всё так просто, то мы бы не дёргали портом в прерываниях и так бы не извращались.
Дело в том, что нам надо было вывести меандр совсем из другого вывода, так как на ноге, которая предназначена для выхода ШИМа, уже сидела другая периферия и нам надо было дёргать другой ногой.
Ну вот например мой МК (ATTINY26L) имеет на борту встроенный RC генератор на 64МГц
для ШИМа.

Да, DX168B точно понял ситуацию. Задействовать аппаратный режим проблем нет. Да и вообще, при необходимости, можно впаять отдельный кварцевый генератор (стоит около 30 рублей) и не трогать контроллер.
Тут скорее интересная головоломка, нежели практическая необходимость. Которую мы решили!

Опять же похвастаю, в СиЛабовских контроллерах нет жёсткой привязки периферии к конкретному выводу МК

А на мощных ПЛИСах можно даже пень III отгрохать, если постараться.
А мы решаем нестандартную задачу. Чем-то напоминает передачи из Discovery, типа "Свалка"
Есть куча хлама и нам надо сделать что-то работающее.

Точно, я просто тему невнимательно просмотрел, там явно о занятости ног сказано было. Вот как бывает, сначала какой-то светодиод или кнопка займёт ногу ШИМ, а потом корячиться приходится. Как в той байке про инженера, которого берут на ставку уборщицы потому, что ставка инжерена уже занята. Уборщицей. Которую брали на работу, когда ставка уборщицы была занята электриком.
Старушка tiny15 тоже не дура в этом смысле. А на тини26 я лет семь назад приставалку к людям делал (ик-барьер и рекламная требуха из AT45DB на динамик при подходе к стенду с товаром), звук тем ШИМ-ом и делал.

А по барабану, там можно хоть 1 и 2 поставить. Всё равно между прерываниями будет по команде из основного кода, а прерывание будет выполняться столько, сколько сможет. Просто флаги взводиться будут несколько раз подряд без обработки. Фигня может быть в одном случае - если запросы идут слишком часто (за время обработки OCR0A срабатывает дважды), то по выходу из обработчика OCR0A опять вызовется он же, а OCR0B не вызовется, так как у него ниже так называемый приоритет. Т.е. при слишком частых запросах выполняться будет только OCR0A и на линии будет фиксированный уровень. В переходной зоне будет в разы прыгать период - OCR0B то будет вклиниваться, то не будет.

И, кстати, в первый раз такты были посчитаны правильно rjmp из вектора на код не нужен, как не нужны и два прерывания. Если у нас таки мега48, а не что-то старое. Вектора OCR0A и OCR0B идут подряд, можно прерывание OCR0B не использовать и код поместить прямо в зоне векторов, сделав в прерыванииинвертирование состояния ноги. Причём не при помощи SBI, занимающей два такта, а при помощи OUT, занимающей один такт.
Тогда минимальное время обработки 4+1+4 = 9 тактов. Заодно при слишком частых запросах просто перестанет уменьшаться период, так как прерывание одно.
«меандр», естественно, вышел немного не меандр, так как в осноном коде есть комады с разным временем выполнения. Поскольку команд всего две, по осциллографу на выходе PORTC5 устойчиво единичка (прерываем 1-тактовую команду) немного короче, чем нолик (прерываем 2-тактовую).

Я не понял, как у вас происходит инвертирование бита. Поясните пожалуйста.

У всех «достаточно новых» AVR - например, у tiny13, mega48, но не у mega8A (она хоть и новая, но аналог старой mega8) есть такая особенность.
Триггер хранения состояния выхода PORTx охвачен обратной связью с инвертором, которая активируется записью единицы в соответствующий PINx

При записи в PORT значение в триггер попадает с шины данных, при записи в соответствующий PIN - инверсное значение старого состония.
Писать единичку в PIN можно как при помощи SBI, так и при помощи OUT. Нолики в OUT не влияют на состояние соответствующих выходов.

Для конкретного контроллера смотреть картинку в I/O-Ports - Ports as General Digital I/O (там схема проще, так как не замешивается инвертирование по Output Compare) или в Alternate Port Functions. Если есть такая вот запись через мультиплексор, то это оно.
Там же и в тексте абзац