Программный ШИМ на AVR

mich91

interrupt [TIM1_COMPA] void timer1_compa_isr(void)
{
 TCNT1H=0x00;
 TCNT1L=0x00;
 
 if(count>=PWM_digit)
        count=0;
 count++;
 
  if(value<count)
       {
        PWM_out=0;
        
       } 
      else 
       {
        PWM_out=1; 
       }
  
}

Мой вариант программного ШИМа, где скважность импульсов задает value, 0<=value<=PWM_digit.Можно легко через CASE добавить нужное количество ножек с независимой регулировкой ШИМ,например вот так

Код: Выделить всё

 for(i=0;i<=Chanel_Count;i++)
  { 
    if(count<Chanel_Lev[i])
    {
      switch(i) 
      {
        case 0 : PORTD.0=1;break;
        case 1 : PORTD.1=1;break;
        case 2 : PORTD.2=1;break;
        case 3 : PORTD.3=1;break;
        case 4 : PORTD.4=1;break;
        case 5 : PORTD.5=1;break;
        case 6 : PORTD.6=1;break;
        case 7 : PORTD.7=1;break;
      }
    }
    else
    {            
       switch(i) 
      {
        case 0 : PORTD.0=0;break;
        case 1 : PORTD.1=0;break;
        case 2 : PORTD.2=0;break;
        case 3 : PORTD.3=0;break;
        case 4 : PORTD.4=0;break;
        case 5 : PORTD.5=0;break;
        case 6 : PORTD.6=0;break;
        case 7 : PORTD.7=0;break;
      }
    }  
      
  }

Но в этом алгоритме есть минус в том что частота ШИМа равна (Частота прерываний таймера)/(количество ступенек регулирования(PWM_digit)), тоисть чем больше ступенек тем меньше частота. Может есть какой нибуть другой алгоритм или все же невозможно без потерь частоты ШИМ сделать ?

Реклама

Ser60

Попробуйте вторй switch написать так: switch(Chanel_Count - i).

Реклама

urry

http://bsvi.ru/bam-alternativa-shimu/

vitalik_1984

Вот уж действительно БУМ рулит. более 200 шим по трем проводам.
любой оптимизированный программный шим просто меркнет на фоне БУМ (BAM)

Ser60 писал(а):Попробуйте вторй switch написать так: switch(Chanel_Count - i).

Вы, должно быть забыли, что в switch можно только целые числа запихать.Никаких выражений в процессе работы.
В выражении есть переменная i, значит нужно выносить выражение за функцию.
И что вообще даст это ваше нововведение? Смену состояния ДРУГОЙ ножки.Если i это номер канала, с которым работаем.

Реклама

Ser60

Да, видимо я неправильно понял роль переменной i.

Реклама

BOB51

vitalik_1984 писал(а): Вот уж действительно БУМ рулит. более 200 шим по трем проводам.
любой оптимизированный программный шим просто меркнет на фоне БУМ (BAM)

Не стоит слишком расслабляться...

Сделай два варианта - стандартный ШИМ и BAM с последовательным плавным набором градаций (и последующим спадом) - простой "перебор по кругу" для светика и сразу разницу увидиш...

Реклама

vitalik_1984

Сделай два варианта ... сразу разницу увидишЬ

Как же эта разница будет выглядеть по вашему?
Речь идет о программном шим, не аппаратном с аппаратным то как раз все замечательно.
В случае с BAM вроде как проще управлять большИм количеством выводов.
Хотя возможно это мнение ошибочно.

phanis

Еще как вариант можно предложить зажигать светодиод по переполнению таймера, а гасить по совпадению того же таймера.

BOB51

А вот сооруди макетик ШИМ и BAM с частотой 50-60Гц для светиков и прокрути на том макетике плавный перебор уровня яркости - именно плавный перебор, а не фиксированное значение или прыжки уровня...
на макетике с BAM будут несанкционированные мерцания (то-ли погасанием, то-ли вспышкой) : это особенности формирования сигнала на переходах весовых коэффициентов - вместо
__--__--__ получается кратковременно что-то вроде__--____--__ или __----____--, но такой "мелочи" вполне достаточно для дискомфорта восприятия при динамическом изменении уровня яркости ("джиттер фазы")... В остальном BAM намного эффективнее по использованию рабочего времени МК (кроме кванта уровня=1 там и BAM и ШИМ равноценны), чем ШИМ

phanis

Вот что пишут по этому поводу на одном из форумов

1 Возможно Вы не знали, что в ВАМ методе, при переходе значений от 127 к 128 и наоборот возникают артефакты в виде заметного моргания. Такое получается из за того, что при смене вышеуказанных значений соседние периоды ВАМ образуют облась с одним уровнем (в зависимости от напрвления перехода 0 или 1) с периодом равным целому периоду ВАМ.

Для того, чтобы этого избежать, в каждый следующий период работы ВАМ нужно меняеть направление обработки

источник http://forum.getchip.net/viewtopic.php? ... e&start=10

avreal

BOB51 писал(а):А вот сооруди макетик ШИМ и BAM с частотой 50-60Гц для светиков и прокрути на том макетике плавный перебор уровня яркости - именно плавный перебор, а не фиксированное значение или прыжки уровня...
на макетике с BAM будут несанкционированные мерцания (то-ли погасанием, то-ли вспышкой)

Всего-то? Так это лечится одной дополнительной переменной (фрагмент кода из параллельного разговора по BAM в теме codevision).

Код: Выделить всё

volatile uint8_t value; // Сюда верхний уровень пишет нужную яркость

static uint8_t value_cache;
static uint8_t mask;

interrupt [TIM2_COMP] void timer2_comp_isr(void)
{
    mask <<= 1;
    if (mask == 0) {
        mask = 0x01;
        value_cache = value; // И никаких скачков
    }
    OCR2 += mask;
    if (value_cache & mask) {
        PORTD.0=1;
    } else {
        PORTD.0=0;
    }   
}

avreal

phanis писал(а):Вот что пишут по этому поводу на одном из форумов

Надо посоображать. Это не то, о чём я -- о смене кода value в середие периода, когда первая половина периода отработает по одному коду, а вторая по другому. От этого промежуточная переменная спасёт.
А от такого склеивания - надо подумать, будет оно (даже при промежуточной переменной) проявляться только при частотах на грани восприятия или всегда.

BOB51

Там ведь не только при переходе с 0х7F на 0x80 (или с 0x80 на 0х7F) подобная ситуация встречается - просто это наиболее заметное явление - как один из способов борьбы программное предсказание ситуаций "склеивания" с подстановкой "правильного" значения - однако такой "фокус" избыточно усложняет код.

По крайней мере мне это мерцание не понравилось

- для фиксированного или ступенчато изменяемого уровня вполне пригодно, но для плавных переливов "не очень".

Да и коды я рисую на асме...

mich91

avreal писал(а):
BOB51 писал(а):А вот сооруди макетик ШИМ и BAM с частотой 50-60Гц для светиков и прокрути на том макетике плавный перебор уровня яркости - именно плавный перебор, а не фиксированное значение или прыжки уровня...
на макетике с BAM будут несанкционированные мерцания (то-ли погасанием, то-ли вспышкой)
Всего-то? Так это лечится одной дополнительной переменной (фрагмент кода из параллельного разговора по BAM в теме codevision).
Код: Выделить всё
volatile uint8_t value; // Сюда верхний уровень пишет нужную яркость

static uint8_t value_cache;
static uint8_t mask;

interrupt [TIM2_COMP] void timer2_comp_isr(void)
{
    mask <<= 1;
    if (mask == 0) {
        mask = 0x01;
        value_cache = value; // И никаких скачков
    }
    OCR2 += mask;
    if (value_cache & mask) {
        PORTD.0=1;
    } else {
        PORTD.0=0;
    }   
} 

Как обьяснить то что этот код во втором таймере не пашет, получается что таймер не вовремя меняет счет, а если кинуть без переделок в первый то сразу работает ???

BOB51

Тогда это уже табличная предкоррекция данных для обработчика

qwerky

Вот уж действительно БУМ рулит. более 200 шим по трем проводам.

вы хоть загляните в листинг компилятора - программно ШИМ проще и легче БАМа.
ШИМ - это один общий счетчик и одно сравнение на канал, для БАМа алгоритм посложнее, тем более заполнение у него далеко неравномерное.
если нужно равномерное - тогда уж Брезенхем.

BOB51

" программно ШИМ проще и легче БАМа "
Неверное мнение!

Не знаю, что там Сишшшные компиляторы выписивают, но с точки зрения ассемблера BAM реализуется если не на равных, то несколько проще, чем программный ШИМ - зато экономия времени для основной программы безспорна.

Единственное обязательное требование - 16-разрядный таймер (при ШИМ возможно применение 8-разрядного с предделителем).

Кстати, насчет программного ШИМ, да еще с некоторыми "прибамбасами" -
http://radiokot.ru/forum/viewtopic.php? ... 9&start=60
http://radiokot.ru/forum/download/file.php?id=119897
на 13-й тиньке 4 канала 256 градаций с мультиплексированием х4 и выборкой рисунка из ПЗУ (асинхронная картинка для каждого из каналов), но... бедная тинька на пределе возможностей...

qwerky

Не знаю, что там Сишшшные компиляторы выписивают, но с точки зрения ассемблера BAM реализуется если не на равных

ошибаетесь. ШИМ - это инкремент счетчика и одно сравнение на канал. Для ВАМа алгоритм посложнее

BOB51

Для BAM всего лишь простой сдвиг данных в соответствующий бит порта (даже сравнение не требуется)

qwerky

Для BAM всего лишь простой сдвиг данных в соответствующий бит порта (даже сравнение не требуется)

на каких контроллерах возможен прямой сдвиг в бит порта, не подскажете ?