Това също е вариант, но за съжаление при PIC16 латентното време при заявка за прекъсване не е константа. На всичкото отгоре не е и детерминирано. А относно споменатият колега мога само да кажа че е истинско удоволствие да се работи с него. Каквото и да му възложат ще измисли решение.

Добре, де. На пикльовците са им сложили един кепчър, с който можеш да хванеш много точно ( до 250 ns ) момента, когато входния сигнал си сменя състоянието. Останалото е аритметика. Така не става ли?

Трябва да хванеш момента и когато състоянието се върне отново в изходното. Нали трябва да се измери ШИМ, а не продължителност на импулс. Аз не съм ползвал capture-то но доколкото си спомням май имаше някакъв проблем да измериш паузата веднага след импулса. Сещам се за един начин, но ще трябва да се смятат разни времена за изпълнение на инструкциите и да запускаш capture-то със закъснение. После ще има едни корекции ...... Най-добре е TIMER1 със gate control.

Клатигорично не! С кепчъра си става много добре. Пускаш го по единия фрон, при прекъсването от кепчъра записваш TimeStamp_0. Сменяш фронта, при следващото прекъсване записваш TimeStamp_1. Възстановяваш предишното значение на актичния фронт, получаваш TimeStamp_2. Period = TimeStamp_2 - TimeStamp_1. DutyCycle = Period / (TimeStamp_2 - TimeStamp_1).
Трябва да се внимава да не се прехвърли границата от 16 бита за периода. Ако в хода на меренето таймерът се препълни, не е фатално. Сметките се "самонагаждат".

По описаният от теб начин ще работи но само с едно измерване си за никъде. Както споменах в предният си пост ако не изчислиш точният момент на запускане на capture-тo няма да можеш да компенсираш закъсненото му пускане при изваждането (трябва време за да запомниш timestamp-a, да обърнеш фронта и да запуснеш capture-то отново). Това ще доведе до грешка от нелинейност. Както по-горе съм споменал латентното време за влизане в прекъсване варира и затова не съм превърженик на това да се използва прекъсване, след като не е необходимо. В крайна сметка да мериш SMT не е основната задача на PIC-a в една нормална програма.
При еднакви други условия ако се използва gate control на TMR1 в сравнение с capture ще се получи:
1. по-висока точност на измерването
2. минимум N пъти по-малко процесорно време при N измервания.
3. по-малко код
4. по-прост ISR

Не знам може би си прав. По "моя" начин също имаш възможност за многократни измервания. Освен това НЕ ЗАВИСИ от латентността на софта. Тези датчици имат повече от милисекунда време мезду фронтовете, което е повече от достатъчно. Не ти трябва да запускаш кепчъра - веднъж запуснат, той си щрака на всяко събитие. Убеден съм, че това е по-точният метод.

Има латентност на хардуера който се грижи да се извика вектора за прекъсване а не на софтуера. При твоя метод той влияе и то на всеки цикъл. Предложеният от мен начин е лишен от тези недостатъци, защото въпреки че измервам изтеклото време с ТМR0 и съответно ISR аз чета TMR0 във фоновата програма. Ако не ме мързеше толкова бих драснал една времедиаграма от която всичко ще се изясни.

Е не! Латентността на извикване на ISR не касае точността - моментът се фиксира в един 16-битов регистър и можеш да си го прочетеш, когата си искаш (преди следващия фронт). Мометът на фиксация няма латентност. Така съм мерил и честота, и период, и DutyCycle, и винаги е било точно.

Допуснал съм грешка и не съм съобразил че ти не нулираш ТМR1 след прекъсване. Иначе всичко ми изглежда работоспособно. От теоретична гледна точка и двата подхода са коректни:
1. Измерване на продължителността на импулса и периода, като в последствие делиш първото на второто.
2. TMR1 се инкрементира за времето през което имаш 1 и после го делиш на общото време за измерване.

Забележките ми по отношение на времето за изпълнение и дължината на кода си остават. Между другото не се заяждам, но в предният ти пост си объркал формулата за изчисление на PWM-а. Записано на един ред трябва да изглежда

DutyCycle = (TimeStamp_1 - TimeStamp_0) / (TimeStamp_2 - TimeStamp_0)

Това е ако приемем че първо измерваш продължителността на импулса.

Беше пропуснал да споменеш TimeStamp_0 в сметките.
Както и да е, получи се интересна дискусия.

"Е, случват се и грешки", рекъл таралежът и слязъл от четката за дрехи
Поне забелязвам, че ме четеш насериозно.

Здравейте, внимателно изчетох всичко по темата и искам и да прибавя моето решение на мерене на температура с SMT160-30. Сензора е хубав ката параметри в datasheet, но само дотук ! На практика е много трудно да постигнеш точни резултати с този сензор. Най-лошото не е точността, а това че този сензор не е подходящ за измерване на температура в промишлени условия - и при най-малките радио и електо смущения дава големи отклонения. Изследвал съм го на стенд, самоделка наистина, но вършеше работа. При 50 MHz честота, не си спомням каква мощност, този сензор даде разлика от цели 10 градуса, като в същото време допотопния LM335Z даде отклонение 0,5 градуса. Така, че приятели, един безплатен съвет: ако ще мерите температура в промишлени условия, забравете за него. Другия проблем с нестабилните показания или трудно измерване на ШИМ, го реших по един най-елементарен начин: превърнах ШИМ-а в аналогово напрежение върху един Кондензатор ( 200uF ), през резистор 6k8, т.е. реализирах НЧФ. От Кондензатора измервах директно с АЦП-то на PIC16C73, резултатите бяха повече от чудесни. Дори не се налагаше усредняване. Усредняването се вършеше от самия кондензатор. Трябва само да се приложи преобразуваниет от показние на АЦП, за да получим температурата. Аз използвам следното:
t = (ADRES-0.32*pow(2,10))/(0.0047*pow(2,10)),
където ADRES e стойността на АЦП-то, и след следните замествания:
0.32*pow(2,10) = 327.68;
0.0047*pow(2,10) = 4.8128;
се получава следната формула, при 10-битово АЦП.
t = (ADRES-328)/4.8;
Опорното напрежение е +5V. Пробвайте, ако не вярвате, но това работи. Преди да се спра на тази схема, пробвах с таймери, с кепчъри и ефекта беше нулев. По така описания алгоритъм работят вече над 4 години, 10-тина устройства, който се намират буквално на къра в едно голямо предприятие и по модем FX604 предават данните на няколко километра. Това е, ако някой се нуждае от повече информация, ще му изпратя и част от програмния код.
След като разбрах, че SMT160-30 не струва, преминах на LM335Z. С него много лесно се работи, а тези дето казват, че калибровката му е страшна се лъжат. Може и да не се калибрира ако му се осигури генератор на постоянен ток. В този случай, мисля, че грешката беше под 1 градус. Ако се калибрира се достига до 0,5 градуса. Може директно да си изтеглите една моя разработка, наречен frigo от http://www.geocities.com/svetoslavpirev/frigo/frigo.zip. Там използвам PIC12F629 и LM335Z за измерване на температура. Има и интерфейс по RS232 към терминал на ПК, за да виждате резултатите. Използвам и източник на опорно напрежение, в лицето на TL431. Тъй като PIC12F629 няма АЦП използвам компаратора. Microchip имат много добра AN, не си спомням номера, в която описват как да се мери напрежение в обхвата 0-5V с компаратора.

П.П.
Пропуснах да кажа, че трябва паралелно на кондензатора да свържите един високоомен резистор, май използвах 330 кила, защото ако се прекъсне проводника на изхода с ШИМ, то кондензатора ще се разреди много бавно през високоомния вход на процесора, като през това време ще имате грешни показания. При прекъсване на проводника с ШИМ, доколкото си спомням се получаваше температура -57 градуса, което беше индикатор за мен, че има проблем. Освен това процесора не беше PIC16C73, а PIC16F873, но последното не е голям дерт.

А някой да иска да подхванем темата за платина и термодвойки. Можем да си споделим различни неща, които да бъдат от полза за всеки. Имам известен опит там, въпреки че не е кой знай какво.

Темата за измерване на температура е интересна, независимо от използваните датчици. В момента работя върху терморегулатор за температури -20...+99 градуса Целзий, или по-точно вариант1: -20...10 и вариант2: 0...+99.
Бави ме окончателния избор на датчик. Първоначално се спрях на LM335Z заради добрите параметри и ниска цена. Даже именно за това избрах PIC12F675 с АЦП. Обаче, след това реших да пробвам най-напред популярния DS18B20. Схемата заработи добре, индикацията е с точност до 1 градус, което при грешка от 0.5 градуса на DS в диапазона -10...+85 градуса е съвсем прилично. Работата е в оптимизацията на цената. DS18B20 е скъп, а в един от вариантите ще ми трябват 2 бр. От друга страна, интерфейса 1-wire позволява на същия пин на Пика да закача и двата датчика и мога да използвам малко по-евтиния PIC12F629.
Ако използвам LM335, цената пада, но ще ми трябват два пина с АЦП, но тогава няма да ми стигнат изводите, а не искам да минавам на друг Пик.
SMT-тата са малко по-евтини, но близки по цена на DS, но и грешката им е малко по-висока.
Някакъв съвет от по-опитните?

Темата за измерване на температура е интересна, независимо от използваните датчици. В момента работя върху терморегулатор за температури -20...+99 градуса Целзий, или по-точно вариант1: -20...10 и вариант2: 0...+99.
Бави ме окончателния избор на датчик. Първоначално се спрях на LM335Z заради добрите параметри и ниска цена. Даже именно за това избрах PIC12F675 с АЦП. Обаче, след това реших да пробвам най-напред популярния DS18B20. Схемата заработи добре, индикацията е с точност до 1 градус, което при грешка от 0.5 градуса на DS в диапазона -10...+85 градуса е съвсем прилично. Работата е в оптимизацията на цената. DS18B20 е скъп, а в един от вариантите ще ми трябват 2 бр. От друга страна, интерфейса 1-wire позволява на същия пин на Пика да закача и двата датчика и мога да използвам малко по-евтиния PIC12F629.
Ако използвам LM335, цената пада, но ще ми трябват два пина с АЦП, но тогава няма да ми стигнат изводите, а не искам да минавам на друг Пик.
SMT-тата са малко по-евтини, но близки по цена на DS, но и грешката им е малко по-висока.
Някакъв съвет от по-опитните?