Полная версия этой страницы: 2 ШИМа на 16 разрядном таймере
Возможно ли сделать 2 шима на 16 разрядном таймере (T1) на ATmega 16 ?
Естественно можно, но с одинаковой частотой.
Верно ли это ?
TCCR1A=0xA1;
TCCR1B=0x09;
///////// TIMER1 COMPA Interrupt ////////////
#pragma vector = 0x18
__interrupt void TIMER1_COMPA_Interrupt( void )
{
OCR1A = Next;
}
///////// TIMER1 COMPB Interrupt ////////////
#pragma vector = 0x1C
__interrupt void TIMER1_COMPB_Interrupt( void )
{
OCR1B = Next;
}
Next - значени при досчете до которого возникает прерывание .
TCCR1A=0xA1;
TCCR1B=0x09;
///////// TIMER1 COMPA Interrupt ////////////
#pragma vector = 0x18
__interrupt void TIMER1_COMPA_Interrupt( void )
{
OCR1A = Next;
}
///////// TIMER1 COMPB Interrupt ////////////
#pragma vector = 0x1C
__interrupt void TIMER1_COMPB_Interrupt( void )
{
OCR1B = Next;
}
Next - значени при досчете до которого возникает прерывание .
Только вопрос: нафига размножать прерывания, если можно обновлять оба регистра в прерывании Timer1 Overflow?
Цитата(_Pasha @ Aug 27 2009, 18:44) 
Только вопрос: нафига размножать прерывания, если можно обновлять оба регистра в прерывании Timer1 Overflow?
Угу, тем более, что так можно с легкостью получить еще несколько match в том же цикле.
На сколько я понимаю Timer1 Overflow это когда таймер до конца досчитывает ,
мне так не надо, мне надо генерить прямоугольные импульсы разной длины.
мне так не надо, мне надо генерить прямоугольные импульсы разной длины.
Ну да. И регистры сравнения надо обновлять именно в этот момент.
Цитата(Varlamov_E @ Aug 27 2009, 17:51)
мне так не надо, мне надо генерить прямоугольные импульсы разной длины.
Если делать так, как Вы хотите - то получится, что обновление ОСх будет аж в следующем ТОРе, поскольку прерывание будет после данного события. Если писАть в нуле(overflow) - регистры обновятся в текущем ТОРе. Если сделаете это быстро- то практически для всего набора значений.
Господа инженеры, не забывайте что в PWM-режимах регистры OCR работают с двойной буферизацией. Писать в них можно когда угодно, не обязательно в прерывании, но данные будут храниться в буферных регистрах и только по началу следующего цикла будут аппаратно переписаны в регистры сравнения.
В примере выше установлен режим FastPWM 8bit, поэтому в соответствии с Table 47. Waveform Generation Mode Bit Description регистры OCR обновляются когда TCNT сбрасывается в 0 (BOTTOM).
В примере выше установлен режим FastPWM 8bit, поэтому в соответствии с Table 47. Waveform Generation Mode Bit Description регистры OCR обновляются когда TCNT сбрасывается в 0 (BOTTOM).
Но два прерывания всё равно не нужны. Об этом и указали топикстартеру.
Если обрабатывать обновление в голове, то требуется следить за флагом, а так - типичная работа по прерыванию OVF, что и было ему предложено.
Если обрабатывать обновление в голове, то требуется следить за флагом, а так - типичная работа по прерыванию OVF, что и было ему предложено.
Цитата(SSerge @ Aug 27 2009, 19:20)
В примере выше установлен режим FastPWM 8bit, поэтому в соответствии с Table 47. Waveform Generation Mode Bit Description регистры OCR обновляются когда TCNT сбрасывается в 0 (BOTTOM).
Давно я, оказывается, не обновлял ДШ на мегу16... В старом был в табл.47 OCRx update on TOP. Пардон за попытку ввести в заблуждение
Цитата(SasaVitebsk @ Aug 27 2009, 20:38)
Но два прерывания всё равно не нужны. Об этом и указали топикстартеру.
Если обрабатывать обновление в голове, то требуется следить за флагом, а так - типичная работа по прерыванию OVF, что и было ему предложено.
Если обрабатывать обновление в голове, то требуется следить за флагом, а так - типичная работа по прерыванию OVF, что и было ему предложено.
Если обрабатывать в OVF, задержим смену на 0 и околонулевые значения всегда у обоих PWM каналов! PWM для "тихих сигналов" будет работать с искажениями.
Если обслуживать каждый OCR индивидуально как делает автор, то проблемы с доп искажениями на "тихих сигналах" практически исчезнут полностью, за счет хардварной буферизации. Но накладных расходов будет больше.
Поэтому категорически заявлять, что два прерывания не нужны - не стоит. Надо подумать что важнее и выбрать между, накладными расходами и искажением слабых сигналов.
Цитата(defunct @ Nov 17 2009, 15:08)
Если обрабатывать в OVF, задержим смену на 0 и околонулевые значения всегда у обоих PWM каналов! PWM для "тихих сигналов" будет работать с искажениями
Поясните, что значит "задержим смену на 0", она же аппаратно делается.
Не понял также, почему нельзя в одном прерывании сделать две пересылки?
OCR1A = Next;
OCR1B = Next;
Цитата(=GM= @ Nov 17 2009, 17:37)
Поясните, что значит "задержим смену на 0", она же аппаратно делается.
Код
OVF OVF OVF
---|------------------|------------------|------------------|----
^ ^ ^ ^ new OCR applied here
OCR current | +-- new OCR placed into the HW buf
+ still old OCR tiggered OC event
---|------------------|------------------|------------------|----
^ ^ ^ ^ new OCR applied here
OCR current | +-- new OCR placed into the HW buf
+ still old OCR tiggered OC event
Посмотрел на свою же картинку и понял, что никаких проблем не будет. Будет только задержка на один OVF цикл.
А в плане качества так наоборот лучше, т.к. задержка вывода сл. семпла не зависимости от значения в OCR.
Прошу предыдущий пост игнорировать, поспешишь людей насмешишь.
Использование TOVF для перезагрузки обоих каналов более безопасно чем перезагрузка по OC event'у, и в тоже время менее накладна для процессора.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.