PIC12. Измеритель скважности ШИМ.

[RXL]

Имеется микроконтроллер PIC10F202 (система команд PIC12) - малютка с шестью выводами. Ресурсов довольно мало: Flash на 512 командных слов, 24 регистра и встроенный генератор на 4 МГц.

Задача следующая: имеется источник ШИМ-сигнала, необходимо определить его скважность по, предположим, 100-бальной шкале. Периодичность замеров - 20 мс. Частота ШИМ сигнала в пределах 1-16 кГц (тестируемый образец имеет 4 кГц).

Я вижу два метода решения:

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

2. Замером времени между фронтами сигнала для небольшого числа периодов (пусть будет 8) с последующим определением доли "активной" части сигнала. Дискретность замеров ограничена 5 мкс.

Хочу оценить данные методы и понять, имеет ли второй метод преимущество над первым. Первый я уже реализовал и вполне им доволен, но чип полностью загружен большую часть 20 мс цикла, а мог бы заниматься в это время чем-нибудь другим.

[Sla]

Я не знаю этот чип, и...
А есть у него какой-нибудь вход реагирующий на переход с 0 на 1 (или наоборот?)

[Ochkarik]

RXL,  
входной ШИМ дает напряжение +/-V ? или 0/1? или этой ошибкой пренебрегаем?

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

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

либо я 1 от 2 не могу отличить... что значит "последующее определение доли активной части"? - чем это отличается от   интегрирования?

[RXL]

Детектора фронт/спад нет. Точнее он есть, но за отсутствием прерываний, кроме сброса, время реакции на него не определенное. Называется там это просыпанием по смене линии. Соотв., чип должен быть в sleep и в этом режиме выключен тактовый генератор - сколько займет его запуск из даташита я не понял. Да и не метод это - проще сканировать в цикле.

Вход только цифровой - 0/1.

Замеры идут циклами по 20 мс. Результат последнего цикла используется в следующем. Т.е. есть задержка до 20 мс. Большая точность не требуется.

Скважность любая - 0..100%. На испытуемом девайсе - либо 0, либо 40..80%.

Под "активной" частью я имел в виду % скважности. Отличается: временем замера: 1 - долгий замер, 2 - несколько периодов; принципом: 1 - подсчет единиц на входе без анализа , 2 - здесь подсчет времени между сменой уровней.

[Dale]

Какие требования к точности измерений? Все-таки при частоте входного сигнала 16 кГц период составляет 62.5 мкс, что при дискретности 5 мкс даст довольно грубое разрешение (12 градаций). Не для всех применений сгодится, даже для дистанционного управления может оказаться многовато. А если учесть, что

На испытуемом девайсе - либо 0, либо 40..80%.

, и того меньше - 8 ступенек. Насколько я знаю, в типовых пультах дистанционного управления крайние значения не используются, заполнение импульса всегда болтается в районе 50%.

Что дальше происходит с сигналом в девайсе после измерения? Не преобразуется ли он в аналоговый?

[RXL]

Изначально я не знал параметров ШИМ - ни частоты, ни диапазона скважности - работал совершенно вслепую. Разработка любительская, приборов нет, источники сведений разрозненные и противоречивые.
По этому я закладывался на 1..16 кГц. Позже, используя аудио-карту, я определил частоту (8 кГц) и диапазон скважности (семплировал на 192 кГц - по 24 отсчета на период) своего источника.
Т.е. целевая частота - 8 кГц, но хотелось бы рассчитывать, пусть и с потерей точности, на работу и с 16 кГц.
При 5 мкс получается 25 замеров в единичном измерении одного периода - 4-8% точности. При большом количестве замеров точность растет. По этому я написал, т.к. задумался - годится ли метод 2 из первого поста на замену методу 1.

Как я уже говорил, скважность я замерил доступными мне средствами - она приблизительно от 40 до 80%, либо 0% ниже некого порога на пульте. Пульт показывает на своем дисплее уровень от 0 до 100% с шагом в 1%.

В дальнейшем результат используется для задания ширины импульса в PPM-сигнале. Сигнал подается на контроллер управления электродвигателем (без реверса).


Добавлено через 5 минут и 1 секунду:
В симуляторе я пробовал подавать сигналы разных частот и разной скважности и проверять девиацию измерений. На 3000 Гц и 50% на каждое пятое измерение есть отклонение на 1/800. На 6000 Гц и 50% - на каждом измерении колебание +- 4/800.


Добавлено через 2 минуты и 25 секунд:
В планах создание устройства, которое объединяло бы в себе измеритель ШИМ и контроллер бесколлекторного трехфазного двигателя. Отсюда и тема возникла: текущий метод занимает много процессорного времени, а алгоритм управления двигателем тоже требует больших временных затрат.

[Ochkarik]

RXL, подсчет единиц от подсчета времени по моему никак не отличается... время - те же условные  единицы. либо я опять не понял... имеется в виду разница в чисто программной реализации?

а оставшаяся разница в 1 и 2 будет проявляться на граничных условиях.
при высоких входных частотах - будет падать точность 2, так как сократится время измерения.
насколько падать - думаю пропорционально сокращению этого времени. не помню точно)

Добавлено через 3 минуты и 11 секунд:
или не... наверное все таки корню...

Добавлено через 8 минут и 30 секунд:
вообще, это выводится математически... но у меня по статистике всегда плохо было:( хотя постоянно с ней имею дело)))
можно гистограмму построить. точность от частоты и скважности, (со случайной начальной фазой усреднять распределение - по ней же).

[RXL]

Да, программная реализация является сутью вопроса. Как уже писал, метод 1 устраивает полностью, но есть планы на другой девайс и там этот метод не сможет уживаться с другими модулями программы. В текущей реализации детектор почти непрерывно работает 16 мс из доступных 20 мс.

А какой другой метод можно применить?

Закрадывается мысль, что проще окажется оставить как есть - каждая программа в своем чипе.

[Ochkarik]

регистры там 8 битные?  или есть аккумулятор на 16?
я так понимаю, ты в него складываешь в цикле входное значение, в конце цикла делишь сдвигом на число тактов?
если регистры 8 бит - основные накладные расходы на что, на перенос из 8го в 9 бит?

[Ochkarik]

либо второй вариант - подсчет постоянной составляющей за целое число периодов.
в знаковый аккумулятор +1 если "1", -1 - если "0".
в конце делить на число периодов (но тут деление очень накладное)

или это и были те два метода?

[RXL]

Все 8-битное. Архитектура RISC - команды примитивнейшее. Большей частью используют специальный буфер w (он не является аккумулятором!) - результат вычисления помещается либо в регистр, либо в w - по выбору программиста. Все операции за один машинный цикл, за исключением условий прерывания линейного потока выполнения - тогда +1 цикл на выборку по новому адресу. RAM нет совсем (в более продвинутых чипах регистровый файл больше, но доступ к "излишкам" страничный).

Я делаю так: цикл длиной 20 мкс, в нем 4 замера (на два канала одновременно, каждый со своим набором переменных), количество итераций заранее известно, но не более 63; после цикла складываю результат с 8-битным счетчиком накопления и по его переполнению инкрементирую другой 8-битный счетчик. Данный цикл выполняется столько раз, сколько надо. Например, сейчас программа разделена на 4 фазы: 54 итерации, 40, 12х60, а в четвертой замеров нет - здесь расчет значений и синхронизация с таймером.



Вот-вот - "за целое число периодов" - такая прошивка есть в сети. Но я не уверен в ее точности, хотя она работает. Хреново то, что у меня только софт, а тестированием на железе занимается другой человек в Киеве - нет возможности субъективно оценить.

[Ochkarik]

с другой стороны а чего собственно волноваться? когда ты 1-м методом считаешь - там та же ошибка проявляется. поскольку время интегрирования у тебя от входного периода не зависит.
вопрос только отношению времени с целым числом периодов к времени этого последнего куска в который целое число периодов не уложилось.

можно попробовать еще инерционный фильтр поставить, но там разрядность и сдвиги.... не знаю, можно в 8 уложить или нет.
например (a - вход, x - выход/аккумулятор, k<1 - коэф. сглаживания ): x=k*x + a
в целочисленном я делал так: x = x  - (x>>4) + (a>>4)
(k = 1 - 1/16) - коэф. сглаживания. чем ближе к 1 ближе к 0, тем больше усреднение.
но на PIC  8 бит это вряд ли ляжет...

[RXL]

А можно подробнее? Буфер задержки отсутствует?

[Ochkarik]

ну буфер отсутствует, но присутствует аккумулятор.
фильтр применяется в радиотехнике, из за простоты. это так фильтр класса Фильтр с Бесконечной Импульсной Характеристикой (БИХ или IIR). конкретно этот - фильтр первого порядка. используется в виду своей простоты. это ФНЧ, (полоса пропускания считается в коэффициент k, если интересно потом гляну на работе формулу), в полосе подавления - затухание идет 6дБ/октаву.
словами: на каждом новом такте, значение аккумулятора умножается на коэф.<1 и складывается с входным значением.
задержка тем не менее у него присутствует (как у всех фильтров) зависит от полосы пропускания. но это не должно пугать - у интегратора тоже есть задержка, на длину интегрирования.

выполняет фильтрацию по алгоритму:
y(i) = y(i-1) + (x(i)-y(i-1))*k

переходная характеристика (на входе меандр период 10 тактов со скважностью 40%) три варианта выходных сигнала для фильтров с k=1/16, 1/32, 1/64.
моделирование во float point...
честно говоря не уверен что 8 разрядов хватит. да и используется он в непрерывном сигнале обычно. то есть не-блочный режим.
но зато может непрерывно отслеживать. здесь он фактически фильтрует постоянную составляющую меандра которая пропорциональна скважности импульсов.
то есть в установившемся режиме (где то тактов через 100 для этих значений), среднее значение порядка 0.4 от размаха 1.0 меандра.

//RC фильтр первого порядка
void
func_rc_filtr(int &in, int &out)//значения по ссылке изменяется глобально
{
    //dt = 1/T=частота цифровки,  fs = частота среза
    //a = exp( -dt * fs * 2*M_PI  )
    //b = 1.0 - a;    
    //out = (in * b + out * a)
    out +=  -((out)>>8) + (in>>8);
}
  

[RXL]

Спасибо, подумаю, поэкспериментирую.

[PredatorAlpha]

Там в этой серии есть чип с компаратором. И на компараторе, насколько я помню, есть прерывание. Может стоит использовать этот чип?

[RXL]

Прерываний у данной серии нет вообще. Есть только просыпание по событию, что по сути — сброс.

[RXL]

Для завершенности темы: исходники и готовые прошивки. Чипы pic10f20x.

[Ochkarik]

кстати... в экстримовском аналоге конвертора... из его описания... присутствует модуль автоопределения частоты ШИМ.
если сначала тактовую частоту определить - может быть это что то даст в плане точности и скорости?

[RXL]

Сомневаюсь, что это нужно. Думаю вернуться к варианту 2 из первого поста. Так можно сократить время реакции конвертера до нескольких периодов ШИМ. Пусть, к примеру, будет 4 периода на 4 кГц - 1 мс. Время реакции ESC уже никак не сократишь: ему нужно принять импульс PPM, а значит гарантированная задержка 1..2 мс. Итого 2-3 мс минимум. Длительность цикла можно попробовать сократить до 5-6 мс.

При варианте два я вижу такой алгоритм:
1. Синхронизация с таймером (цикл PPM).
2. Замер ШИМ и расчет PPM.
3. Выдача PPM.

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

[Ochkarik]

а никак нельзя все три шага перемешать?)
в непрерывном режиме...
или попробовать предсказание положения фронта сделать, тогда не обязательно надо будет непрерывную выборку одного внутри периода ставить.

[RXL]

PIC10/12 слаб на периферию - у него даже прерываний нет, кроме сброса. У меня есть две чужие прошивки под ATmega8 и ATtiny13 - там все построено на таймерах и прерываниях от входных линий, не говоря уже об аппаратном формировании импульса PPM.

В текущем варианте (1) обработка ШИМ и выдача PPM совмещены, но ширина импульса зависит от результата предыдущего цикла.

[Ochkarik]

кстати, а почему PIC выбрал? легкодоставабельный+цена?

PS а в чем там сейчас основная проблема - время реакции или точность?
я пока чисто теоретически интересуюсь... на работе похожие поделки делаем... думал хоть это хобби отвлекать будет, а все равно в сторону улучшений думается))))

[RXL]

Я не выбирал
Тут такая история... Саша-Сушка решил делать конвертер, нашел одноканальную прошивку для pic10f202, написанную каким-то немцем, изготовил плату, прошил - заработало. Потом возникла идея сделать двухканальный вариант на том же чипе. Я посмотрел исходники той прошивки и порешил, что по тому алгоритму сделать два канала не выйдет. В общем, я писал и тестировал в отладчике, а он прошивал и тестировал на железе. Но на ХР никто не тестировал! Желающих получить конвертер было много и он растиражировал конвертер и послал его не менее чем 35 человекам. Т.е. выбирать другой чип поздно - надо имеющееся поддерживать
Когда дошли до тестов с ХР, выяснилось, что обратная связь через гироскоп плюс задержка передачи сигнала дают полный разлад.

[Ochkarik]

а может для канала ОХXP отдельный алгоритм поставить. типа хрен с ней с точностью - пусть будет только скорость.


Добавлено через 1 минуту и 25 секунд:
скольк там вообще градаций - кто-нибудь пробовал смотреть?

[RXL]

Надо подумать. Попробую на днях что-нибудь написать. Программатор у меня сейчас есть. ESC - "HK 3A 1g". Движок - AP-03. Прошью и посмотрю, как он будет реагировать.