Вам бы еще компилятор сменить на вменяемый, например, IAR.



Предлагаю 4 датчика и воспользоваться тем, что еще один датчик можно зацепить на порт D - на непосредственный вход компаратора - именно тот, который сидит на мультиплексоре. Второй - оставить на земле.

А по чем датчики брали?

Вот так выглядит при оптимизированном обработчике прерывания (масштаб такой же как на предидущем видео):

Видео с осциллографа

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

Думаю что не бывает плохих компиляторов, быват плохие программисты. :-)) В крайнем случае напишу #asm... и, эх раззудись плечо, размахнись рука... :-)) Хотя и отвык от АСМа капитально.



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


С датчиками оказалось сложно. Сначала хотел купить в Платане, но дешевых нет в наличии, а те которые есть предложили привезти по 500 р за шт. Я че то пожадничал. Негуманный ценник. И тогда заказал у китаезов вот такой парктроник. За 1000 р. я получил 4 датчика с комплектом электроники "для опытов". Правда пришлось месяц ждать доставки.
Отдельно датчики от парктроников по вменяемой цене тож не нашел.

Неа. Разница есть. Надо драйвить сразу оба пина в противофазе. Значит, оба вывода датчика должны быть подключены к одному порту.



Бывают компиляторы, генерящие плохой код в не зависимости от мастерства программиста. ICC в их числе.

Пробовал и одновременно, и по очереди. Разницы не заметил.


У меня CodeVision. Хотя думаю особой разницы нет. Но меня ПОКА устраивает.

Вопрос еще такой. Интегратор это как? Мне представляется - сложить все измерения, например те же 1024 цкла, и по окончании поделить. Арифметическое среднее короче. Или принять первое значение, а потом в зависимости от значений следующих измерений либо прибавлять либо отнимать единичку к первому принятому?

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

А не думали умножить сигнал на sin/cos тех же 40кгц, а уже потом проинтегрировать ? Вроде бы должно помочь принципиально подавить помехи ?

То не помехи были, уже ж разобрались. А добротность у датчика вполне приличная. Кстати, из-за приличной добротности я перед самим измерением вхолостую дую где-то 1000 периодов.

Можно измерять в диапазоне -128 0 +128. Значение капчи присваивать переменной типа signed char и отнимать 128. А для усреднения использовать модуль. Тогда получиться как в коде Грея - на краях диапазона различие в один младший разряд. Только одновременно нужно считать количество положительных и отрицательных компонент при усреднении, что бы понимать в положительной или отрицательной половине остаемся.

Не совсем понятно, что Вы хотите сделать.

Ну например постоянно принимается 0-255-0-255. Мы это число переводим в знаковое и от каждого измерения отнимаем 128. ТОгда получается что на выходе то -1 то 0. Вот их и усредняем. О, даже и отнимать ничего не надо. В знаковом виде будет то -127 то +127. Таймер то считает от 0 до 255, а в знаковом виде - от -127 до +127. Т.е. когда он досчитал до +127, переполнился и начинается - 127. Или я что то неправильно понимаю?

Мне кажется, что да. Попробуйте написать код. Не весь, а только расчетные выражения.

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

Причем тут код Грея? Достаточно того, что разность между двумя измерениями стремится к 0. Ху из разность? Правильно, производная. Значит, чтобы получить среднее по всем измерениям, надо дважды проинтегрировать разности соседних измерений (сначала получить интеграл производной, т.е. собственно значение измерения, но уже без переполнения, т.к. производная мала (помещатеся в signed char), а интегратор - достаточно широк, например, 16 бит для простоты), а затем - проинтегрировать (усреднить) уже полученные "непереполняющиеся" значения измерения.

2 Rst7

Т.е. так?

Интегратор(16бит) += (Текущее_измерение - Предидущее_значение);

... повторям много раз

Фактическое_значение = Интегратор/количество_отсчетов

Нет. Не так.

Интегратор1(16бит) += (Текущее_измерение - Предидущее_значение);
Интегратор2(32бита) += Интегратор1;

... повторям много раз

Фактическое_значение = Интегратор2/количество_отсчетов

ЭЭЭэээ...
А разве это не одно и то же?

Разве нельзя сократить



до

Интегратор2(32бита) += (Текущее_измерение - Предидущее_значение);

... повторям много раз

Фактическое_значение = Интегратор2/количество_отсчетов ??


Или Интегратор1 тоже static?

Конечно. Где Вы видели интегратор не static?

- Семен Семеныч!!!
- Ах да, да...


:-))

Только если быть до конца точным, то должно быть


Обратите внимание на приведение типа именно к 8ми битам со знаком. Если его не написать, то компилятор исполнит integer promotion и все пойдет по женскому половому органу

Уважаемый RST7, а можно взглянуть на ваш вариант программной реализации? Собственно интересует сам механизм измерения сдвига фазы

Так вроде все описано выше. Конкретно код там довольно специфический и нечитабельный, по большому счету.

из описанного выше вполне понятно как обработать полученный результат, а я будучи латышОм, не совсем понимаю сам механизм работы ацп в данном решении, потому даже не читаемый код был бы хорошим подспорьем, на чем еще учиться как ни на работе профи!?

В данном решении не используется АЦП, только компаратор.