Мой вариант программного ШИМа, где скважность импульсов задает 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)), тоисть чем больше ступенек тем меньше частота. Может есть какой нибуть другой алгоритм или все же невозможно без потерь частоты ШИМ сделать ?
Вы, должно быть забыли, что в switch можно только целые числа запихать.Никаких выражений в процессе работы. В выражении есть переменная i, значит нужно выносить выражение за функцию. И что вообще даст это ваше нововведение? Смену состояния ДРУГОЙ ножки.Если i это номер канала, с которым работаем.
:tea: Вот уж действительно БУМ рулит. более 200 шим по трем проводам. любой оптимизированный программный шим просто меркнет на фоне БУМ (BAM)
Не стоит слишком расслабляться... Сделай два варианта - стандартный ШИМ и BAM с последовательным плавным набором градаций (и последующим спадом) - простой "перебор по кругу" для светика и сразу разницу увидиш...
Как же эта разница будет выглядеть по вашему? Речь идет о программном шим, не аппаратном с аппаратным то как раз все замечательно. В случае с BAM вроде как проще управлять большИм количеством выводов. Хотя возможно это мнение ошибочно.
А вот сооруди макетик ШИМ и BAM с частотой 50-60Гц для светиков и прокрути на том макетике плавный перебор уровня яркости - именно плавный перебор, а не фиксированное значение или прыжки уровня... на макетике с BAM будут несанкционированные мерцания (то-ли погасанием, то-ли вспышкой) : это особенности формирования сигнала на переходах весовых коэффициентов - вместо __--__--__ получается кратковременно что-то вроде__--____--__ или __----____--, но такой "мелочи" вполне достаточно для дискомфорта восприятия при динамическом изменении уровня яркости ("джиттер фазы")... В остальном BAM намного эффективнее по использованию рабочего времени МК (кроме кванта уровня=1 там и BAM и ШИМ равноценны), чем ШИМ
1 Возможно Вы не знали, что в ВАМ методе, при переходе значений от 127 к 128 и наоборот возникают артефакты в виде заметного моргания. Такое получается из за того, что при смене вышеуказанных значений соседние периоды ВАМ образуют облась с одним уровнем (в зависимости от напрвления перехода 0 или 1) с периодом равным целому периоду ВАМ.
Цитата:
Для того, чтобы этого избежать, в каждый следующий период работы ВАМ нужно меняеть направление обработки
А вот сооруди макетик ШИМ и 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; } }
_________________ Лень в виде мании величия: «ты гений, зачем стараться?». В виде комплекса: «всё равно не выйдет, зачем упираться?». Как логика: «если достаточно, зачем знать и уметь больше?». Цель одна: остановить. Не любит тепло работающих мышц и шум работающего мозга.
Надо посоображать. Это не то, о чём я -- о смене кода value в середие периода, когда первая половина периода отработает по одному коду, а вторая по другому. От этого промежуточная переменная спасёт. А от такого склеивания - надо подумать, будет оно (даже при промежуточной переменной) проявляться только при частотах на грани восприятия или всегда.
_________________ Лень в виде мании величия: «ты гений, зачем стараться?». В виде комплекса: «всё равно не выйдет, зачем упираться?». Как логика: «если достаточно, зачем знать и уметь больше?». Цель одна: остановить. Не любит тепло работающих мышц и шум работающего мозга.
Там ведь не только при переходе с 0х7F на 0x80 (или с 0x80 на 0х7F) подобная ситуация встречается - просто это наиболее заметное явление - как один из способов борьбы программное предсказание ситуаций "склеивания" с подстановкой "правильного" значения - однако такой "фокус" избыточно усложняет код. По крайней мере мне это мерцание не понравилось - для фиксированного или ступенчато изменяемого уровня вполне пригодно, но для плавных переливов "не очень". Да и коды я рисую на асме...
А вот сооруди макетик ШИМ и 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; } }
Как обьяснить то что этот код во втором таймере не пашет, получается что таймер не вовремя меняет счет, а если кинуть без переделок в первый то сразу работает ???
:tea: Вот уж действительно БУМ рулит. более 200 шим по трем проводам.
вы хоть загляните в листинг компилятора - программно ШИМ проще и легче БАМа. ШИМ - это один общий счетчик и одно сравнение на канал, для БАМа алгоритм посложнее, тем более заполнение у него далеко неравномерное. если нужно равномерное - тогда уж Брезенхем.
" программно ШИМ проще и легче БАМа " Неверное мнение! Не знаю, что там Сишшшные компиляторы выписивают, но с точки зрения ассемблера BAM реализуется если не на равных, то несколько проще, чем программный ШИМ - зато экономия времени для основной программы безспорна. Единственное обязательное требование - 16-разрядный таймер (при ШИМ возможно применение 8-разрядного с предделителем). Кстати, насчет программного ШИМ, да еще с некоторыми "прибамбасами" - viewtopic.php?f=3&t=77399&start=60 download/file.php?id=119897 на 13-й тиньке 4 канала 256 градаций с мультиплексированием х4 и выборкой рисунка из ПЗУ (асинхронная картинка для каждого из каналов), но... бедная тинька на пределе возможностей...
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
Вот уж действительно БУМ рулит. более 200 шим по трем проводам.
Сделай два варианта - стандартный ШИМ и BAM с последовательным плавным набором градаций (и последующим спадом) - простой "перебор по кругу" для светика и сразу разницу увидиш... 
- для фиксированного или ступенчато изменяемого уровня вполне пригодно, но для плавных переливов "не очень". 
