Кажется, мы друг друга не понимаем(:-). Где там? Что такое точность 3200? Частота до 62 кГц для 12 шим? Программно или аппаратно?

Почему только фиксированные точки синуса?

Александр, это хорошо, можем потом обсудить, но сколько было ступенек для 12 каналов шим, реализованных на си (по ссылке, которую я давал)?

Число каналов задаётся разработчиком, как и характеристики шима. Как они могут влиять друг на друга? Что такое погрешности на краях?

У меня любой из 24-х каналов шима имеет одинаковые характеристики, т.е. 256 ступенек, длительность каждой ступеньки, скажем, 0.7 мкс (по памяти). Первая ступенька всегда 0, а переход может быть на любой ступеньке, нет никаких краёв, а раз краёв нет, то и борьбы нет(:-).

Тогда мы действительно не понимаем друг друга.

Смотря как ты ШИМ реализовывал.
Я реализовывал по прерываниям. Расчитывал как бы таблицу времён-портов. В прерывании перегружал следующую константу таймера и выводил значения портов. В связи с тем, что минимальная разница - одна единица, то длительность прерывания должна быть меньше чем Тшим/Nступеней.

Такое построение имеет своё преимущество. Поскольку я первым делом вывожу состояние портов, то погрешность вывода незначительна. Есть и недостаток. В связи с тем, что прерывание занимает значительное время (вход/выход/сохранение контекста/обработка) то достичь высокой частоты ШИМ не удаётся.

Можно делать прямым опросом таймера, как я видел в примерах на PIC. Честно говоря такой подход меня не устраивает и я его не применяю.

Можно обрабатывать все ступеньки. То есть делать 256 прерываний за период. В принципе метод отличается от первого большей регулярностью и меньшим временем реакции на прерывание. Частота, соответственно будет выше. Правда загруженность процессора будет многократно выше.


Пост о котором я писал я реализовывал первым описанным способом. Управлял ШД (делал дробление) Соответственно полную синусоиду мне выводить не было необходимости. В тоже время точность вывода (число ступенек) была 3200. Что тут непонятного?

Вот моя базовая процедура, выполняется за 18 МЦ, можно еще укоротить (не буду смущать народ, а то придёт сами знаете кто, и начнёт верещать...)

Код

;Процедура формирования 256-точечного 24-канального ШИМа (18МЦ)
pwmisr:  ld   temp,x+       ;обновление
        out   port1,temp    ;порта 1
        ld    temp,x+       ;обновление
        out   port2,temp    ;порта 2
        ld    temp,x+       ;обновление
        out   port3,temp    ;порта 3
        ld    temp,x+       ;новая уставка
        out   TCR0,temp     ;для сравнения
        reti

Как видишь, можно обойтись без всяких сохранений контекстов(:-).

Для твоего случая, для 12 каналов, время прерывания можно сделать порядка 10 МЦ, т.е. с клоком 20 мег время одной ступеньки будет равно 0.5 мкс, период шим = 256*0.5=128 мкс, следовательно частота шим - 7.8 кГц, это на чистом ассемблере, а у тебя 5 кГц на си, неужто компилятор генерит такой быстрый код?

Непонятно одно. Если 3200 ступеней, то как получить шим 5 кГц? У тебя время одной ступени будет 200 мкс/3200=62.5 нс, а это примерно один МЦ контроллера.

Такой вопросик с целью понимания вопроса(тфт): Скажите уважаемые коллеги, если у меня 256 ступенек шима и порт я обновляю с частотой 25кГц, то минимальное (суммарное значение длительности импульсов) за 1с получается 1/256с?так? И могу ли я справедливо назвать что шим 25Кгц?
зы: делал программный 32-ух канальный шим для управления диодами. 25кГц,256дискрет.

18-канальный ШИМ на Мега8 (18.432МГц) для управлениея 6-тью полноцветными светодиодами

T0_OVF:
push temp
in temp,SREG
push temp
clc
ror rd
ror rd
cp cval,rR5 //PD2
ror rd
cp cval,rB4 //PD3
ror rd
cp cval,rG4 //PD4
ror rd
cp cval,rR4 //PD5
ror rd
cp cval,rB3 //PD6
ror rd
cp cval,rG3 //PD7
ror rd
cp cval,rR3 //PB0
ror rb
cp cval,rB2 //PB1
ror rb
cp cval,rB6 //PB2
ror rb
cp cval,rG2 //PB3
ror rb
cp cval,rG6 //PB4
ror rb
cp cval,rR2 //PB5
ror rb
clc
ror rb
ror rb
cp cval,rR6 //PC0
ror rc
cp cval,rB1 //PC1
ror rc
cp cval,rB5 //PC2
ror rc
cp cval,rG1 //PC3
ror rc
cp cval,rG5 //PC4
ror rc
cp cval,rR1 //PC5
ror rc
clc
ror rc
ror rc
com rb
com rc
com rd
out PORTB,rb
out PORTC,rc
out PORTD,rd
inc cval
andi cval,0x7F ; 127 - уровней, мона убрать - станет 8-бит
pop temp
out SREG,temp
pop temp
reti

Инициализация таймера:
// Настройка таймера T0
clr temp
out TCNT0,temp
ldi temp,(1<<PSR10)
out SFIOR,temp
ldi temp,0x01
out TCCR0,temp
ldi temp,(1<<TOIE0)
out TIMSK,temp
Объявление переменных:
// Константы
.equ F_CPU = 18432000
.equ USART_SPEED = 19200
// Определения
.def rR1 = r1
.def rG1 = r2
.def rB1 = r3
.def rR2 = r4
.def rG2 = r5
.def rB2 = r6
.def rR3 = r7
.def rG3 = r8
.def rB3 = r9
.def rR4 = r10
.def rG4 = r11
.def rB4 = r12
.def rR5 = r13
.def rG5 = r14
.def rB5 = r15
.def rR6 = r16
.def rG6 = r17
.def rB6 = r18
.def temp = r19
.def rb = r20
.def rc = r21
.def rd = r22
.def buf = r23
.def cval = r24

Ну ну..
1. теряем ценный регистр X.
2. не понятно где осуществляется сброс X в начальное состояние.
3. почему TCR0 меняется самым последним?
4. Зачем он вообще меняется (25-й канал)?

Функция по тактам возможно и оптимальна, но с т. з. функциональности то, что вы привели - это разрозненные колбасные обрезки.

Немного не так. Обновление порта может случиться на любой из ступенек, следовательно, частота 256-ступенчатого шима ровно в 256 раз меньше частоты обновления порта, т.е. 97 Гц.

Это конечно класно. Но вопрос возникает тогда, когда надо подготовить колбаску в озу для выдачи в порт. Это же очень медленно. Т.е. если понадобится изменить заполнение какого-либо канала, то на это нужно потратить очень много времени.

Спасибо! таким образом получается что ШИМ который имеет значение 256 дискрет, и частоту обновления 5Кгц, незя называть 5-ти килогерцовым шимом?
и как тада получается :

етож 6000*256=1536000 ~1.5МГц! и на 20МГц, да еще и 24 канала?

зы:видел гдето что шим можно и на апаратном уарте сделать. (последовательно данные выдвигаем), но тут уже надо 32байта запихнуть в USART на один дискрет.

Ну, в ваших терминах, это будет частота обновления трёх 8-ми битных портов одновременно, чтобы получить 24 канала. Программка обработки прерывания 24-канальной шим, которую я привёл выше (см.пост #18), выполняется за 18 МЦ (машинных циклов). Один машинный цикл для клока 20 МГц выполняется за 0.05 мкс. Получается обработка прерывания выполняется за 18*0.05=0.9 мкс. То есть за это время обновляются три порта. Частота обновления портов соответственно будет равна 1/0.9=1.1 МГц, ну а частота шим будет в 256 раз ниже, т.е. 1.1/256=4.3 кГц. Никаких чудес, всё по-честному. (Замечу в скобках, что время выполнения можно ещё малёк подсократить, скажем до 13 МЦ, тогда частота 24-канального шима будет порядка 6 кГц.


Да, приём исходных данных и подготовка "колбаски" проводится в фоне и занимает относительно много времени, порядка 2500 МЦ, т.е. 125 мкс. Максимальное занятое время процессора, с учётом времени работы прерываний, составит 148 мкс, в то же время период шим равен 166 мкс. Сиё означает, что есть возможность за ОДИН период шима сменить ВСЕ ДВАДЦАТЬ ЧЕТЫРЕ временные уставки, и еще останется свободными 18 мкс (360 МЦ). Смысла менять уставки чаще, чем период шима, я не вижу(:-)

Пока других, более быстрых способов программного формирования многоканальных шим, я не нашёл.

Ну в Вашем случае вы подготавливаете "колбаску" вне прерывания.. adnega делает это внутри прерывания.. Есть ли в Вашем способе(скажу что способ вообщем то один и тотже) смысл выносить подготовку "колбаски за прерывание"?В таком случае для экономии времени в прерывании прийдется работать с флагами (события по окончанию обновления "колбаски").. и возможен пропуск момента смены значений? в чем выигрыш? может полагаясь на то что данные выводимые в шим обновляются не так часто? тогда какой смыс так "задирать"частоту"шима?

Чето я не понял. Как-то это все не стреляет. Общая идея то понятна, и будет работать, но вот цифры не сходятся



Пусть будет 13 тактов. И еще надо добавить 4 - на вычитывание вектора и т.д. - внутренние операции.

Итого 17.

Теперь с другой стороны. За 166мкс*20МГц=3320 тактов надо выполнить 256 прерываний. На прерывание 12.97 тактов. Меньше 17. Значит свободного времени у процессора нет совсем. И есть недобор. Почти в 1.5 раза. Непонятно, где-же время на генерацию колбаски?

Надо бы рыбку уменьшить

дауж.. т.е. если у Вас GM ("частота обновления портов соответственно будет равна 1/0.9=1.1 МГц" выражаясь моими терминами ) то это совершенно не означает что вы можете менять данные с такой скоростью(переписывать регистры новыми значениями) у вас просто не останется времени на это и плюс еще "колбаска". По честному должна быть возможность менять данные (для 256 значений) один раз через 256 прерываний. так? а сколько у вас остается "свободных"тактов (суммарных от 256-ти прерываний)? По 20МЦ-13МЦ=7МЦ (это наверное с учетом 7 циклов на вход/выход в прерывание) 7*256=1792МЦ... хм.. может быть...?!

Наверное я объяснил не очень, но всё же перечитайте мой пост. Там я пишу что первый способ требует сохранения контекста и вычислений. И там же написал, что при выводе 256 прерываний за период шима (ваш способ который я отнёс к третьему) прерывание короче и частота ШИМ выше. То что Вы описали для меня вполне укладывается в голову и я такие подходы тоже реализовывал.


А мне непонятно, что именно непонятно Вам. Частота у меня 16000. 16000/3200 = 5кГц. Для двигателей я использую 2 канала на двигатель. Дробление делаю на 16. Сдвиг фаз 90 градусов. То есть мне фактически надо формировать несколько значений. Вот я и написал в первом своём посте, что плавность не нужна а точность 3200. Вы уточнили про точность.

Но принципиально, тем не менее, так тоже можно работать. За период ШИМ необязательно делать вывод 256 раз (при 256 ступеньках) Достаточно 1 раз на один канал +1. В этом случае тоже создаётся соответствующая колбаса, только она короче. А также учитываются случаи совпадений. Ошибки будут при малых значения разницы таймера.



Вы, кстати, зря смеётесь. Те характеристики, что указывает GM я берусь реализовать и времени на расчёт останется вагон. Могу продемонстрировать. Лишь бы прерывание укладывалось в ступеньку. Время - я конечно заношу так как указывает defunct, хотя это и не обязательно. П/п линейная и ошибку можно высчитать и учесть при расчётах.

Конечно, алгоритм генерации будет хитрый. Но в худшем случае будет всего N прерываний, где N - количество шимов. А чтобы не было ошибок, надо чтобы частота шима была меньше чем Fcpu/(Ni*256), где Ni - количество тактов на обработку прерывания.