evil_laugh

Если б умел в кикад - подсобил бы однозначно. Но я в Mentor Graphics работаю. Ну, и в DipTrace иногда... А вообще "последить" - это я имел в виду, что поизучаю и поднаберусь опыта. :) Вообще у меня проблема ещё и в том, что из "подопытных кроликов" у меня только два УАЗа карбовых и Daewoo Nexia поджопная, т.е. ковырять особо нечего. Идея изобрести велик родилась, когда я хотел ГБО на уаза ставить - в то время ещё толком не было ни ГИГ, ни GSP3U, вот и захотелось свой газовый инжектор сделать :) Но сейчас уже как-то отошёл от всей этой "механики" - для инжектирования карбового УАЗа (даже простейший моновпрыск газа) треба дофига механического геморроя. Форсунки врежь, датчики расставь... Раньше бы взялся (тогда перебрать двигло за выхи было чем-то плёвым). Сейчас - лень :) А нексию ковырять как-то... кхм, не комильфо. Вообще была идея прикупить убитый инжекторный жыгуль типа 08-09, но выкидывать на это дело $3-4к (дешевле оно на рынке просто не стоит) тоже не комильфо как-то :) Кстати, по поводу GSP3U - в прошлом году, в сентябре, связывался с его разработчиком на предмет того, чтобы получить/купить у него исходники и схему в целях обучения (там всё вообще на PIC18 и на ассемблере сделано). Добыть исходники не удалось, но кучу информации в процессе приятной беседы я таки получил. Тогда проект был заморожен, а сейчас - вон, на одном из форумов инфа, что там уже распределённый газовпрыск рисуют вовсю :D Жаль, что не open source.

Андрей239, классная задумка. Почитал Grassroot Motorsports, почитал твой форум - грамотно! :) Жаль, не могу поучаствовать - слишком незначительны пока что навыки в высокоуровневом программировании и тем более в теории управления ДВС. Идею изобрести велосипед вынашиваю давно, даже есть кое-какие схемотехнические наработки (разведённые "мозги" уже года полтора как ждут воплощения в железе), но времени нет катастрофически. :( Послежу за проектом. Авось и что-нибудь своё сляпаю, воодушевившись, так сказать :) У меня к тебе вопрос - ты, как software developer - где брал информацию по теории управления ДВС? Я, если честно, всегда полагал, что для того, чтобы успешно завести двигло, надо как минимум в/о по ДВС иметь. :) зы: Гирявеца читал :D

Так навскидку и не скажешь... Нужно, я бы сказал. Можно.

Я знал! Я знал, что всё просто Требований по скорострельности нет, потребителю всё равно, через сколько на него напряжение прокинется :) Если я правильно понимаю, ни одного. :) Уже бегу рисовать схему :) Нарисую - выложу на критику. есть немного. "Заработался" это называется :laughing:

Доброго всем дня. Стоит, казалось бы, простая задача: ключевать питание нагрузки. Напряжение питания плавающее: от 3.5 В до 60 В (оно же питание всей ключующей схемы). Ток потребления нагрузки до 4 А. Режим - длительный. Просмотрев кучу даташитов на Load Switch-и, понял, что настолько простого решения тут не существует. Решил использовать обычный MOSFET. P-канальный, естественно. Подобрал образец, макс. напряжение с-и -75 В, ток протягивает до 5 А, полностью открывается -3 вольтами, всё отлично. Но вот беда: напряжение з-и у него не более -20 В. Простое решение: надо ставить делитель, чтобы при 60 В на истоке (макс. входное напр-е) и открытом транзисторе напряжение на затворе было не больше 40 В, и тогда Uзи будет -20 В. Делитель должен быть 4/6. Но возникает другая проблема: при таком делителе и минимальном напряжении питания (3,5 В) на затворе будет 3,5*4/6=2,3 В, то есть Uзи будет -1,2 В. Транзистор просто не откроется. Решение не годится. Как реализовать подобное "адаптивное" управление p-мосфетом? Управление осуществляется с микроконтроллера, у него есть возможность мерить напряжение питания, так что считаем его известным. Условия получается следующими: если ключуемое напряжение меньше, скажем, 15 В (с запасом, чтобы не сгорел) - можно "напрямую" тянуть затвор P-мосфета к земле, тогда Uзи будет больше или равно -15 В. Если напряжение больше 15 В - нужно ограничить напряжение затвора p-мосфета таким образом, чтобы Uзи не превышало -15 В. Вопрос: как это сделать? Как вообще делаются такие вещи? Читал интернет, гуглил информацию, нашёл в основном идеи про использование драйверов, преимущественно верхнего плеча. Но там основная беда - бутстрепная техника управления затвором N-канальника не даст возможности долго держать транзюк открытым. Ну и свои заморочки типа узкого диапазона напряжений питания и управления, ну это ладно, вопрос решаемый... Видел технику постоянной подкачки бутстрепной ёмкости зарядовым насосом на базе NE555, но это решение, на мой взгляд, слишком громоздкое и ненадёжное, тем более о нём встречены отрицательные отзывы. Голову сломал, не могу выдумать ничего красивого и надёжного, чтобы раз - и заработало. Прошу помощи. Спасибо.

Я бы предложил алгоритм Герцеля, но он не будет эффективнее БПФ при таком количестве выходных отсчётов...

Если два последних прилепленных изображения - это спектр на входе и выходе, то что-то Ваш ФНЧ не очень "фнчит".

Вот в пункте 4 стартового поста я делал почти так же, только использовал 30 фаз по 60 коэффициентов. Тут столкнулся с рядом проблем, которые тоже увеличивают время выполнения и требуемую память. Нужно точно знать, какую фазу (точнее, две фазы, или больше, если использовать Лагранжа порядком выше) использовать при вычислении каждого из 128 выходных отсчётов. Либо вычислять это на месте (занимает время), либо заранее рассчитыватт и загонять в lookup table (минимум +256 байт, максимум - зависит от лагранжа). Нужно точно знать, в каком месте между двумя вычисляемыми фазными отсчётами находится интерполируемый, для каждого из 128 интерполируемых. Минимум +256 байт, ну или опять же довольно сложная арифметика на месте. Нужно точно знать, сколько новых отсчётов нужно вдвинуть в буфер при вычислении каждого из 128 отсчётов. Опять либо время, либо +128 байт. Ещё нужно учитывать момент, когда интерполируемый отсчёт находится между последним фазовым и следующим за ним (как бы "нулевым"). Для вычисления "нулевого" фазового нужно временно вдвинуть в буфер ещё один входной отсчёт, профильтровать и снова вернуть буфер на место. (Блин, коряво объяснил, но опытные товарищи, надеюсь, поймут). А это проверка условия на каждом выходном отсчёте. Опять же, время. Вот так как-то... Всё это работает, но не так эффективно, как хотелось бы :) К тому же при таком количестве фаз и коэффициентов я не укладывался в требования по подавлению. "По-правильному" фаз должно быть 128, как же оно с восемью так хорошо работает? :)

Для непрерывной обработки данных потребуется циклический буфер длиной N, где N - кол-во коэфф-тов импульсной хар-ки фильтра. Вдвигаете в буфер отсчёт вх. сигнала, перемножаете буфер с ИХ фильтра, произведения суммируете. Краевой эффект будет заметен при недостаточной длине фильтра. Получите ужосчто. Циклическая свёртка вместо линейной. Сигнал фильтровать нужно непрерывно, а не блоками. Для этого и нужен сдвиговый буфер. Если хотите делать фильтрацию в частотной области, то гугль по ключ. слову overlap-save Вам в помощь.

Вот теперь мозаика сошлась в единое целое. :) Спасибо. Я пробовал делать подобное (пункт 4 первого сообщения темы), правда, с другой стороны подошёл немного. Попробую сделать и так, как Вы сказали. Заодно время выполнения алгоритма и общую требуемую память подсчитаю.

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

То есть Вы делаете простую однокаскадную передискретизацию, но с таким вот хитрым фильтром? А на какую частоту дискретизации фильтр считался? Я так понимаю, Вы не делали "честное" повышение частоты дискретизации до 44100*128, а сделали как-то по-другому? А как?

Serg76, похоже, Вы познали Дао. У меня только один вопрос: КАК? :) Можно, пожалуйста, подробнее про алгоритм? :)

Большое всем спасибо за грамотные и содержательные ответы. Картина значительно прояснилась. Попробую повысить частоту дискретизации и потом использовать Лагранжа. Надо учиться пользоваться Матлабом, а то симуляция различных вариантов много времени занимает :)

Вот тут не совсем понял... Вы предлагаете сперва ограничить по частоте исходный сигнал, а потом куда-то его интерполировать?.. Тем временем я спешу доложить о результатах моих сегодняшних изысканий. Сделал я Фарроу. Кубический. Симметричный. Децимирует с 44100 до 38400. Тестировал так: генерировал испытательный синус 0 dBFS с ЛЧМ модуляцией (от 0 до 20 кГц в течение 100 секунд) и прогонял через наскоро набросанную на Си программку. Результат печален. На частотах до 2-3 кГц всё неплохо, гармоники в сигнал не лезут. С повышением частоты начинаются весёлости. Какие - красочно иллюстрирует рисунок ниже. На входе синус 6 кГц, Fд = 44100. На выходе - вот что. Хорошо видно, что из-за полиномиальной интерполяции в сигнал лезут ложные гармоники просто из-за ошибки интерполяции. Сгенерировал в маткаде идеальный дискретный синус и нашёл разность полученного мной сигнала и идеального. Полная шкала от -32768 до +32767. Сдаётся мне, что либо этот метод не слишком хорошо применим, либо я что-то делаю не так... Программу проверял, кажется, Фарроу пашет правильно.

В таком случае я просто не могу не задать Вам ужасающий своей тупостью и отдающий крайней степенью дилентантизма вопрос: как считаете такой фильтр Вы, что у Вас получается 150 коэффициентов? :) Фильтр, который стоит между интерполятором и дециматором при однокаскадном дробном ресамплинге, должен работать на частоте дискретизации, которая получается после интерполяции. В моём случае она равна 44100*128 = 5.625 МГц. Если рассчитать на эту частоту ФНЧ с требуемыми параметрами - получится больше 7 тысяч коэффициентов. Что я делаю не так? :( Так-так, чрезвычайно интересно... Завтра попробую провести расчёты... Входной сигнал прост, как три рубля - передаваемая через микрофон человеческая речь. У микрофона АЧХ вряд ли все 20 кГц имеет... Завтра измерю. Спасибо! Буду пробовать и этот метод, если не сработуют другие. Не мешало бы мне какую-нибудь литературку по вопросу почитать. Скорее всего, я просто не знаю, где искать :) Спасибо большое. С Вашей помощью собаку, если повезёт, съем и я Это вполне жизнеспособный вариант, идеальный с точки зрения "ортодоксальности" и работоспособности. Я пробовал делать подобное (правда, немного с другими коэффициентами, согласно теории об оптимальном выборе коэфициентов для каждлого каскада), но вариант был "отфутболен" из-за высоких вычислительных затрат... Думаю вернуться и к нему тоже и попробовать посчитать получше/оптимизировать процесс, может, выйдет что-то путное :)

Вот как раз в уровне подавления собака и порылась. Если уменьшить требования к моему подавлению хотя бы на 10 дБ, то 7 тысяч коэффициентов одним махом превращаются в 3-4. Это явление (правда в "профиль" - уменьшал не подавление, а длительность переходной полосы) было использовано в пункте 4 сабжа. Если делать "по правилам" с соблюдением всех условий - будет так, как есть :( А вот такая комбинация мне не приходила в голову. Именно полиномиальный дециматор в каскаде с обычным... Мне нравится идея. А Фарроу не будет искажения в сигнал вносить засчёт алиасинга? Вообще я пробовал записывать речевой сигнал с микрофона, там редко когда за 16-17 кГц частота вылезает, но всплески порой бывают. Они не будут сильно влиять? И что делать, если будут? :) Страшные слова... Я таких не слышал даже... :( Впрочем, с апсемплингом тоже вариант...

Спасибо за ответ. Эту книжку я до дыр зачитал уже Там совсем мало про передискретизацию с нецелым коэффициентом. Моей настольной книжкой в этом отношении стала зарубежная книга Chrochiere&Rabiner "Multirate Digital Signal Processing", но все "лежащие на поверхности" методы оттуда я уже, кажется, испробовал... Хотя не знаю. Вот для того и перечислил всё то, что я уже сделал или изучил, чтобы было понятнее :)

Спасибо за ответ. Фильтры я реализовывал с помощью известного метода замены Ремеза, они вроде как оптимальные по количеству коэффициентов и подавлению/пропусканию. Окна пробовал - результат печален, либо тонна коэффициентов, либо ЧХ от желаемых далеки, как Луна от Земли :) Может, есть ещё что-то, что я упустил из виду?

Приветствую уважаемых гуру цифровой обработки :) Прошу помочь мне с алгоритмом, который бы осуществлял изменение частоты дискретизации сигнала с 44100 до 12800 Гц. Сигнал - 16битные отсчёты с микрофона, обычный PCM. Требования к передискретизатору следующие: а) пропускание частоты сигнала в полосе от 0 до 6 кГц с неравномерностью АЧХ не более 3 дБ б) подавление сигнала в полосе 6200 Гц - 6400 Гц не меньше, чем на 60 дБ в) и самое главное - крайне жёсткие требования к объёму используемой оперативной памяти и процессорного времени. Процессор, для которого пишется алгоритм, помимо передискретизации загружен ещё тонной задач. Оперативной памяти для алгоритма может быть выделено не более 2 кБ. Время - как всегда, чем меньше, тем лучше. Расскажу о том, какие исследования я провёл в этой области. Естественно, что чтобы сделать изменение Fд 44100->12800, нужно сперва повысить частоту в 128 раз, потом понизить в 441 раз. Фильтр, который нужен для такой передискретизации в один каскад, имеет больше 7000 коэффициентов (рассматриваем КИХ-фильтрацию), поэтому вариант с таким алгоритмом отпал сразу. Следующим моим шагом было создание многокаскадной системы: сперва повышение частоты в 2*4*16=128 раз, потом её уменьшение в 21*7*3=441 раз. Естественно, использовалось полифазное разбиение фильтров. На входе алгоритма был 441 отсчёт, на выходе - 128. Всё работало и обеспечивало требуемые параметры АЧХ, однако требовалось много места (нужно же где-то хранить 441*2*8 промежуточных отсчётов сигнала на высокой частоте) и много процессорного времени. Поэтому от этого алгоритма тоже пришлось отказаться. Было поставлено требование: только однокаскадная передискретизация. Попутно, кстати, была прочитана горка литературы по фильтрам Фарроу, Ланцоша и прочим полиномиальным фильтрам, но ввиду почти полного отсутствия вменяемых реализаций с графиками и прочими данными - я понял только общий принцип и то, что обмануть никого не удастся и всё равно придётся реализовывать огроменный фильтр. Дальше попробовал сделать так: разработать фильтр с меньшим количеством отсчётов, а при фильтрации проводить интерполяцию полученных значений. При этом было решено поступиться требованиями к переходной полосе фильтра и сделать так, чтобы на 6200 Гц обеспечивалось подавление не ниже 15 дБ, но все дальнейшие частоты выше какой-то величины (у меня получилось 7 кГц) всё равно должны были подавляться не меньше, чем на 60 дБ. Алгоритм был написан на Си и показал свою работоспособность. Казалось бы, всё в порядке и можно писать программу для DSP, но меня не покидало ощущение того, что можно попробовать что-то ещё. Поэтому плавно переезжаем к... ...фильтрации в частотной области, которую я решил рассмотреть как вариант реализации передискретизатора. Что нужно? Правильно, взять ДПФ исходных 441 точек сигнала, занулить ненужные гармоники, выкинуть ненужные 441-128 отсчётов из середины спектра и золотой ключик у меня в кармане. Однако снова возник ряд проблем. Первая - это "как быстро взять ДПФ 441 точек?". Дополнение нулями до 512 точек, судя по всему, не прокатывает - для передискретизации в частотной области придётся выкинуть нецелое количество точек. Ладно, для этого вопроса решение было найдено путём штудирования книжки Блейхута "Быстрые алгоритмы цифровой обработки", откуда я выудил алгоритмы Кули-Таки и алгоритм Гуда-Томаса (который прекрасно работает для числа 441, ибо это 3*3*7*7 - произведение простых чисел). Решение спорное, впрочем, ибо архитектура DSP, ИМХО, ну ни разу не приспособлена для подобного рода выкрутасов со всеми этими адресными тасованиями, тем более в моём дилетантском исполнении. Впрочем, возникает вторая проблема, которая затмевает собой первую: как избежать эффекта Гиббса в данной ситуации? Напрашивается всем известный overlap-save, однако не получится ли так, что время, затрачиваемое на вычисление "лишних" точек, которые потом выкидываются, сведёт весь выигрыш от используемого алгоритма на нет? Собственно, у меня вопрос к уважаемому сообществу: что можно ещё придумать, чтобы выполнить задачу? Приветствуются пинки ногами, крики "пшёл вон, нуб", а также ссылки на авторитетные источники, личный опыт и другую информацию. Напомню задачу: 44100 -> 12800. пропускание 0-6 кГц с неравномерностью 3 дБ, подавление 6200-6400 минимум 60 дБ, минимум процессорного времени, 2 кБ памяти. Спасибо :)

Доброго всем времени суток. Вопрос больше по примитивной арифметике. Делаю передискретизатор частоты. На входе - последовательность данных с АЦП, формат - беззнаковый 16 бит (16.0) Есть рассчитанные коэффициенты имп. хар-ки КИХ-фильтра, по модулю не превышающие 1. Их думаю представить в формате 1.15 - 1 знаковый бит, 15 дробных, диапазон значений от -1 до (1-2^-15). Задача - провести фильтрацию. Ну и впоследствии умножить всю выходную последовательность на целочисленный коэффициент интерполяции, опять же в формате 16.0. Есть процессор ADSP-BF533 семейства Blackfin, на котором всё это надо реализовать. Имеет встроенный умножитель с накопителем, который умеет (как я понял) автоматически перемножать либо данные в формате 1.15, либо в формате 16.0. Оба формата для него стандартные. У меня возникает закономерный вопрос: как совместить форматы данных коэффициентов и данных АЦП? Необходимо, как я понимаю, либо нормировать данные с АЦП (т. е. приводить их в формат 1.15), как написано в одной умной книжке, либо наоборот - коэффициенты приводить в 16.0, либо как-то иначе стыковать эти два формата. Если нормировать - то как перевести число из 16.0 без знака в 1.15 (со знаком)? Необходимое условие реализации - только ассемблер, никаких Си и им подобных. В Си бы такого вопроса не возникло. Если у кого-то есть любые идеи, как реализовать вычисления - я буду рад выслушать и научиться. В ЦОС я пока полный новичок, с арифметикой столкнулся только сейчас. В принципе приветствуются тапки, носки, помидоры, паяльники, карданы и вопли праведного гнева из серии "пойди диодиком помигай, нуб"

Добрый день всем. Руки снова дошли до изучения STM8, продолжил (а точнее, начал) читать документ CPU Programming Manual. Вот ссылка. У меня сразу же возник миллион вопросов. Рассмотрим самую первую страницу, рассказывающую о том, как работает конвеер команд. Вот она. Для наглядности я выделил команды, о которых пойдёт речь, разными цветами. Меня прежде всего заинтересовал вопрос: как производится подсчёт циклов на Decode и Execute? Откуда берутся эти цифры? Открываем описание первой команды LDW. И видим там следующее. Написано, что команда занимает минимум 5 циклов. Это вполне соответствует сумме указанных на предыдущей картинке тактов для Decode и Execute: 4 + 1 = 5. Смотрим следующую команду. ADDW, написано, что занимает 2 цикла на декодирование, и 2 на выполнение. Смотрим описание. Что за притча? Почему написано, что команда занимает 2 цикла? Ведь 2 цикла на decode + 2 цикла на execute = 4, разве нет? Ничего не понятно. Следующая команда - LD. Кажется, в ней есть ошибка, так как синтаксиса LD A,[30].w в описании не встречается. Квадратная скобка д. б. в другом месте, но это мелочи. Сказано, что занимает 3 цикла на decode и 1 на execute, всего 4. Проверяем. Всё верно, 4 цикла там, 4 здесь. Вопрос номер один: чего я не понимаю? Может кто-нибудь объяснить доступным языком, где моя ошибка?

Добрый всем день. Столкнулся с проблемой. Камен - 18F4550, проблема с модулем MSSP. Решил воспользоваться библиотеками микрочипа. Акселерометр ST lis3lv02dl. Опыт с ним уже имел, на х51 собирал проект с ним, работает, захотелось нечто подобное собрать и на пике, но вот незадача, на линиях SDA & SCL тишина полная, т.е. подцепляюсь осцилографом я вижу полный штиль на линиях. Может быть я куда-то не правильно ткнулся (я про код) ? #include <p18f4550.h> //Включаем в наш проект хеад файлы #include <i2c.h> //Конфигурация процессора #pragma config FOSC = INTOSCIO_EC //выбор типа кристала (4MHZ) #pragma config PLLDIV = 1 #pragma config WDT = OFF //Выключаем сторожевой таймер #pragma config LVP = OFF //выключаем низковольтовое напряжение #pragma config MCLRE = OFF // Выключаем пин сброса #pragma config XINST = OFF //Выключаем расширенный набор функции #pragma config FCMEN = OFF #pragma config PWRT = OFF #pragma config VREGEN = OFF #pragma config CCP2MX = OFF #pragma config BOR = OFF #define AXS_ADR 0x3A #define WHO_I_AM 0x0F #define OUTX_L 0x28 #define OUTX_H 0x29 #define OUTY_L 0x2A #define OUTY_H 0x2B #define OUTZ_L 0x2C #define OUTZ_H 0x2D #define CTRL_REG1 0x20 #define CTRL_REG2 0x21 #define CTRL_REG3 0x22 #define STATUS_REG 0x27 #define REG1 0xD7 #define REG2 0x40 unsigned char STAT=0; unsigned short AXS_X=0; unsigned char dat=0; void send_data(unsigned char ADR,unsigned char DATA) { unsigned char temp; temp=AXS_ADR<<1; // 3A=0b00111010 -> 0b01110100 // т.к. происходит запись, то r/w=0, => не трогаем StartI2C(); // Start I2C IdleI2C(); // Ждём пока отпустит WriteI2C(temp); // Записали адресс+операцию выполняемую IdleI2C(); // Ждём пока отпустит WriteI2C(ADR); // Отправляем адресс регистра IdleI2C(); // Ждём пока отпустит WriteI2C(DATA); // Отправляем новое значение регистра IdleI2C(); // Ждём пока отпустит } unsigned char read_data(unsigned char ADR) { unsigned char temp; temp=AXS_ADR<<1; // 3A=0b00111010 -> 0b01110100 temp++; // бит r/w=1 => инкрементируем в значение 0b01110101 StartI2C(); // Start I2C IdleI2C(); // Ждём пока отпустит WriteI2C(temp); // Записали адресс+операцию выполняемую (чтение) IdleI2C(); // Ждём пока отпустит WriteI2C(ADR); // Пишем адресс считываемого регистра IdleI2C(); // Ждём пока отпустит dat=ReadI2C(); // Читаем значение с регистра } void main(void) { OpenI2C(MASTER, SLEW_ON); //MASTER SSPADD=0x27; //baud rate - 100kHz, 4MHz (Таблица в ДШ BRG) //Конфигурируем Акселерометр: send_data(CTRL_REG1,REG1); send_data(CTRL_REG2,REG2); while(1) { read_data(OUTX_H); // Считываем старший разряд ускорения по Х AXS_X=dat; AXS_X=AXS_X<<8; // смещаем до 16-битного числа read_data(OUTX_L); AXS_X=AXS_X+dat; // получаем 16-битное число OUTX_H_OUTX_L } } Контроллер виснет на чтении данных, т.е. передача "осуществляется", а вот с чтением данных уже посложнее, точнее она отсутствует (хотя по моему мнению отсутвует и передача данных, осцилографом изменений не вижу никаких). или же проблема заключается в том, что всю эту радость я пытаюсь завести от внутреннего генератора ? p.s. забыл, т.к. 10кОм найдены не были, засунул от линии на VDD 16kOm резисторы.

Мне казалось, что и таймер, и процессор тактируются одной и той же частотой, а именно SYSCLK от генератора, соответственно, должны быть синхроны... Ну да ладно, впрочем, осциллограф покажет :) Печально только то, что если мне, например, потребуется реализовать задержку NOP-ом, или подсчитать время выполнения подпрограммы - я не смогу без осциллографа понять, сколько оно будет составлять, ибо отладчик вкупе с таймером, как оказывается, могут показывать не совсем то, что нужно...

ZiB, благодарю за информацию, документ весьма полезен. Буду изучать и сопоставлять его с даташитом. scifi, я перепроверю код ещё раз. Но судя по частоте мигания диодиком, которую отсчитывает таймер (раз в секунду) тактовая похожа на указанную в ДШ. Спасибо за ценное указание! А не затруднит ли Вас коротко озвучить несколько самых распространённых причин того, почему такое измерение может быть ошибочно?.. Хотелось бы понять, в целях расширения познаний по предмету. Спасибо :)