До этого проэкта писал только в иаре на си.... Мне поставили задачу на меге 16 получить частоту синусоидального сигнала 50 кГц (Восемь точек на период).... Я на порт А повесил самый простейший цап (R-2-R цепочку).... Организовал на асемблере масив из восьми точек..... В программе также использую два вектора прерывания... Первый 0-й... Он у меня используется для организации прерывания в одну милисекунду... За это прерывание я вызываю все системные функции(работа с индикатром, функция опроса кнопок, ну функция определяющая логику работы программы)... Второй вектор прерывания он 1-й(их всего 4{0,1,2,3}).... В этом векторе я вызываю первую точку из масива... Отпраляю это значение в в порт А... При следующем прерывании вызываю следующую точку и так по кругу.... Меняется частота за щет того что я в функции отвечающей за логику программы в зависимости от нажатия кнопок изменяю значение регистров OCR1AL и OCR1AH....

Но есть баг... Если я начинаю повышать частоту то понятно что не хватает времени на обработку прерывания по 1-му вектору прерывания и программа зависает.... Но как объснить то что я понижаю частоту а при некоторых значениях которые я заношу в OCR1AL и OCR1AH программа зависает.... Прерывание происходит по переполнению при максимальной частоте в OCR1AH находится 0x00, а в OCR1AL значение 0x1B(минимальное значение при котором все работает)... Так вот я начинаю увиличивать значение регистра OCR1AL а программа (заметьте только при некоторых значениях) зависает... Или когда я работаю в далике от максимальной частоты к примеру значение OCR1AL равно 0xF0.... Я увиличиваю это значение на 1... Тоесть в OCR1AL заношу 0xF1... Частота должна уменьшиться.... А она наоборот увеличилась.... Как такое объяснить???

Выше я описал как я организовал рабту всей программы... Порсьба в следующем или подсказать что это за Баг и как с ним бороться... Или может Программы для написания генераторов организовываются по другому принципу... Поделитесь пожалуйста опытом.... Ну собственно буду очень благодарен за любую помощь....

А в какие моменты Вы заносите новое значение в OCR1A ?
ИМХО, у Вас перенастройка таймера просто пересекается с
прерываниями TIM_COMPA/B / TIM_OWF !?
Код прерываний и перенастройки таймера покажите.

Я просто думаю что не совсем будет хрошо если я выложу весь свой проэкт(мне вовсе не жалко)... Просто он очень в запущенном состоянии там много закоментированных строк... Нет коментарий вообще... И собственно думаю не у кого не будет желания разбираться в моем коде.... Поробую пояснить так....

Естественно организован цикл(типа main)..... В 0-м векторе прерывания я организовал щетчик....

В маине постоянно идет ее опрос... Как только занчение переменной щетчика достигнуто определенной величины в маине щетчик обнуляется и вызывается ряд вункций(опрос клавы, жки, и логика[в логике я именно и меняю значение OCR1A])...

Посмотрите вот это: http://www.telesys.ru/projects/proj035/index.shtml .
Вполне возможно, найдете для себя что-то интересное в смысле алгоритма синтеза синусоиды.

Во-первых, замечание по генератору: смену частоты нужно обязательно привязать к фазе генерируемого сигнала.
Во-вторых, не совсем понятен алгоритм программы. Вложенные прерывания у вас разрешены? Стек достаточного размера для этого выделен? И зачем вообще нужно второе перывание с периодом 1 мс? ИМХО проще в "генераторном" прерывании (50кГц как я понял) организовать инкремент числа, которое будет выполнять функцию системных "тиков". Приращение "тикам" можно вычислять синхронно с изменением частоты генератора. А в основном "суперцикле" программы анализировать значение переменной "тиков" и вызывать все системные функции по достижении ей требуемой величины. Не знаю полностью вашей задачи, но обрабатывать клаву и индикатор с частотой 1кГц (период 1 мс) это явно лишнее. Никакая супермашинистка не сможет с такой частотой долбить по клавишам. Да и устранение дребезга обычно требует 5-20мс пауз между опросами клавы. Про дисплей аналогично. Смену информации на индикаторе чаще 3 раз в секунду делать не имеет смысла. У человеческого глаза реакция не лучше 100мс. А быстросменяющаяся визуальная информация просто не воспринимается адекватно осмысленно человеческим мозгом. Так что если других подводных камней нет, а прерывание жизненно необходимо, то смело увеличивайте период системного прерывания на порядок (до 10-20мс).

P.S. Опс! Пока писал ответ появились подробности.

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

Записывать в OCRL/H надо не как попало, а сначала Н, потом L. Между записями не д.б. обращений к др. 16-битным рег. таймера. Если между записями возможно прерывание, в к-ром обращение к 16-б рег. тайм., то прер. надо запрещать.
Читайте ДШ про запись/чтение 16-б регистров