Использую tiny26 для формирования шима на 2 ногах PB1 и PB2... соответственно прямого и инвертированного.

Кварц 16МГц(хотя от 8 тоже пробовал на fast PWM). Тактирование от СК с делителем на 128.

DDRB = 3;
TCCR1A = ((1<<COM1A0) | (1<<PWM1A));
TCCR1B = 136;

Генерируем меандр с переменной частотой от 2кГц до 2,5кГц, меняется с частотой 7Гц.
В цикле меняем

OCR1C=X;
OCR1A=X/2;

Где Х вычисленное значение для генерации необходимо частоты меандра.

Причем на некоторых частотах такого эффекта не наблюдалось(там была медленная смена 2 частот)

На осилографе наблюдаем переодическое пропадание шима... т.е. установление в 0 или 1 на несколько милисекунд... В чем причина такого поведения?

Также пробовал atmell-овский пример на fast PWM (avr131) где генерируется синусоида на фаст ПВМ. Наблюдалось также только половина синусоиды ..

Обратите внимание на тот момент, что Вы никак не синихронизируете смену значения в OCR регистрах
и значение таймера. Поэтому возникает ситуация, когда Вы сменили значение в OCR, а TCNT продолжает считать, и если его значение выше нового OCR, то счётчик будет считать до переполнения, потом,естественно, обнулится, и только после этого произойдёт возврат к нормальной генерации.

Чтобы избежать подобных проблем - после записи в OCR ОБЯЗАТЕЛЬНО обнуляйте TCNT регистр.
Тогда сбоев в формировании ШИМ не будет.

Программно трогать сам таймер (TCNT), работающий в режиме PWM, не нужно и даже вредно. Разработчики Atmel позаботились о том, чтобы запись в OCR1A/B можно было делать В ЛЮБОЙ МОМЕНТ без сбоев в формировании ШИМ:



А вот с OCR1C (TOP) ситуация иная - запись в него делается напрямую, без буферного регистра, и именно это обстоятельство и может вызывать наблюдаемый эффект. Чтобы исключить его, надо сделать так, чтобы запись в OCR1C происходила в безопасные моменты времени, т.е. сразу после сброса TCNT, вызванного его совпадением с OCR1C. Это легко и просто делается с помощью изредка разрешаемого прерывания по TOV1 - когда main вычислил и готов загрузить новые значения в OCR1A/C, то сначала грузит OCR1A и просто разрешает прерывание по TOV1, обработчик которого будет вызван при ближайшем TCNT1==OCR1C. Обработчик этот, в свою очередь, грузит новое значение в OCR1C и запрещает дальнейшие прерывания по TOV1. По завершению 7-ГЦ периода main снова разрешит однократное срабатывание прерывания по TOV1 и т.д.

Отмечу, что из обработчика TOV1 грузить и новое значение OCR1A нежелательно, т.к. именно из-за буферизации оно вступит в силу только после следующего совпадения TCNT1==OCR1C. Впрочем, при малом шаге генерируемой частоты это будет практически незаметно. В идеальном случае нужно устраивать не одно-, а двукратное прерывание - в первом грузить OCR1A, а в следующем - OCR1C, и уже после этого запрещать. Немного усложнится код, но зато результат будет безукоризненным для любой крутизны изменения частоты

А во время изменения OCR я не отключал раньше прерывания и у меня постоянно так скакали 0 и 1 когда я 0 в I запихивал а потом опять 1 то все стало ОК... может дело из-за прерываний происходит...

Всем большое спасибо за помощь!

Менять TCNT программно это действительно не выход...
Это помогает... но появляются небольшие на 1-2 цикла шима задержки..... зато часто, что дает еще более худший эффект, чем длинные но редко .

Решением было менять OCR1C и OCR1A в прерывании, запуская прерывание после вычисления значения, и запрещая их по выходу из прерывания.
Хотя я так и раньше пробовал... но почему-то не получилоось , наверное я не запрещал прерывания...

Работает и так как предложил уважаемый =AVR=, т.е. меняя в прерывании сначала OCR1A, затем OCR1C и запрещая прерывания, хотя отличий не видно, т.к. частота небольшая.

Вам надо именно меандр формировать от 2 кГц до 2.5 кГц или это просто пример? А то я было подумал, что можно обойтись одной переменной, записываемой в OCR1C и смена состояния пина.