MSP430 и timestamps

В Keil и IAR точно есть ограничения, да.

Starting in September 2016, the floating license model ceased to exist.
For CCS release 7.x the paid license ceased to exist. The software and all its components are distributed with a TSPA license.[1]
The free license model was also retrofitted to all public CCS releases since v4.

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

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

Keil и IAR

И это линуксоид говорит...

Но! При включении экрана (при включенном выводе объема/скорости на экран) время меняется значительно. При подключении по USB всё, опять же, меняется.

Это может быть объяснено тем, что при включении экрана или USB начинают работать какие-то процедуры прерываний и код, связанный с экраном и USB, что естественно занимает процессорное время, поэтому начинается разброд во временных интервалах выдачи данных. Но вот не факт, что измерения не были сделаны точно вовремя. Они могут быть все сделаны вовремя на основе обработки высокоприоритетного прерывания таймера, а вот расчет и их передача, могут подзадержаться. Если исходить из этих соображений, то данные, которые приходят неравномерно, все равно были сделаны через равные промежутки, поэтому попытка считать время между их фактическим приходом может быть ошибочной. Надо вчитаться во всю документацию по EVM430-FR6043. Или спросить у TI на форуме или в поддержке.

Ага, вот примечание (мелким шрифтом) есть в Ultrasonic Design Center (slau720b):

The LCD screen on the EVM430-FR6047 can be used when running the application without the GUI (1).

(1) The LCD screen on the EVM430-FR6047 can also be used when running the application with the GUI. However, the LCD routines can disrupt communication between the device and the GUI, and the timing between captures. These disruptions affect the data displayed on the GUI.

Как бы это понять. Я так понимаю, что компьютер поэтому сам измеряет время между приходом данных, так как они в теории могут приходить неравномерно, если включили LCD. Но, если честно, я не понял еще про can disrupt the timing between captures. Имеется в виду, что измерения будут по интерфейсу приходить не вовремя (это так и будет, да) или они фактически платой будут сниматься не вовремя (а вот это вопрос).

Дополню следом: Так как GUI все же измеряет фактическое время между измерениями (или это он просто информационно делает? Для чего он это делает? В графике учитывает?), а не исходит из того, что данные даже пришедшие неравномерно, сделаны равномерно, то все-таки фактическое время между захватами на плате меняется из-за экранчика.

Рафинирую. Упрощу:

Неравномерно приходящие данные из платы интерпретируются GUI как снятые платой равномерно, но просто приходящие неравномерно и отображаемые с разными задержками на экране, или как снятые платой неравномерно?

История такова, допиливаю прошивку под MSP430FR6043/FR6047 и подобные.

А поясни с самого начала, ты куда именно программу пишешь? В саму EVM430-FR? Если да, то зачем? Ты хочешь объем считать и передавать в компьютер? А плата не считает (раз на индикаторе отображает, то, значит, считает)?

Или ты делаешь программу в какой-то внешний контроллер, который к этой плате цепляется по какому-тоинтерфейсу?

Или вы планируете делать девайсы потом на основе MSP430FR6043/FR6047, но со своей прошивкой и без этого LCD?

Если с самого начала, то история такова.

Мы разработали ультразвуковые датчики и внутренности (запчасти) для бытового газового счетчика. После теста различных чипов, выбор электроники для работы с сенсорами и подсчета объема газа остановился на MSP430FR6043. Важно(!), ультразвуковое измерение дает нам только СКОРОСТЬ газа в счетчике на момент измерения, объем же мы должны считать кумулятивно.

Для тестирования мы использовали ту самую EVM. С ней же и отправили заказчику для тестов на точность и т.д. Но заказчик не может использовать GUI для своих тестов, то есть информация должна выводиться средствами самой платы, LCD или LED (моргать каждый литр, например).

В будущем, конечно, плата будет своей, на основе MSP430FR6043/FR6047, скорее всего без USB вообще. Но разбираться в прошивке приходится уже сейчас.

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

Также сейчас разрабатываем счетчик для воды, скорее всего на MSP430FR6047. Проблемы одни и те же.

как снятые платой неравномерно?

Да.

However, the LCD routines can disrupt communication between the device and the GUI, and the timing between captures.

Значит именно то, что мы недавно выяснили — использование LCD влияет на длину интервалов между измерениями :)

Насколько я понимаю (я глянул, но, может, глянул не все), исходников, как LCD считает объем, нет? Исходный код снял бы все проблемы, так как было бы видно, измеряется ли время между измерениями или считается как запрограммировано (скажем, 250 мс).

В документации на библиотеку на сайте расписаны ресурсы, которые используются библиотекой. Используются Timer_A2 и Timer_A0. Больше никаких таймеров, если верить этому не используется.

http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/USSSWLib/USSSWLi...

Если больше таймеров никаких не задействовано, то получается, что при расчете объема на LCD (в документации написано, что объем считается) время не измеряется, хотя возможны какие-то хитрые манипуляции с перепрограммированием Timer_A2 на лету.

Если вы свою плату делать хотите, то там вы можете процессом самостоятельно управлять и точно будете знать обо всех задержках.

Что касается приоритетов, то в Datasheet есть карта прерываний и их приоритеты. (табл. 6-4).

Значит именно то, что мы недавно выяснили — использование LCD влияет на длину интервалов между измерениями :)

Но вот тут не ясно четко. Фактических интервалов или интервалов прихода данных по интерфейсу. На второе определенно влиять будет, а на первое - вопрос. LCD, например, при расчете объема может считать измерения равномерными (этот код, я полагаю, закрыт?), то есть не измеряет время. Хорошо бы получить разъяснения от TI.

Код есть, они просто умножают на время между измерениями (длительность сна). Поэтому LCD у них пишет откровенную чушь.

float resultsCalcVolume(uint16_t rate)
{
	// Scale the Volume data based upon the correct Flow Rate unit
	if(GPM == g_ResultsOfLastMeasurement.FR_unit)
	{
		return (float)( ( (float)g_ResultsOfLastMeasurement.last_FlowRate *
				(float)rate )
				/ ( (float) MILLISECONDS_IN_MIN) );
	}
	else
	{
		return (float)( ( 2.65*(float)g_ResultsOfLastMeasurement.last_FlowRate *
				(float)rate )
				/ ( (float) MILLISECONDS_IN_HOUR) );
	}
}

rate = sleep time

Немного есть в моем треде на е2е, который я тут уже кидал.

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

Фактических интервалов. Я прописал, чтобы LED на плате включался в конце измерения (где я считаю объем) и выключался к конце следующего (т.е. LED включен каждый второй цикл). Подключил к нему осциллограф и смотрел на длительность. Когда ничего не происходит, LED включен 185мс, выключен 185мс, включен 185мс ... Оказлось, 185 или 187 мс. Но если начать взаимодействовать с дисплеем, числа меняются значительно, может быть и 250мс.

Код есть, они просто умножают на время между измерениями длительность сна). Поэтому LCD у них пишет откровенную чушь.

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

Фактических интервалов. Я прописал, чтобы LED на плате включался в конце измерения (где я считаю объем) и выключался к конце следующего (т.е. LED включен каждый второй цикл).

А запрограммирована установка была на 185 мс?

Вот тут поясню, что я имею в виду. Сырые данные он может получать вовремя. Сырые данные прямо с АЦП можно посмотреть в GUI. Он там позволяет их смотреть (sample они это зовут). Но сырые данные - это сырые данные. Дальше контроллер считает что-то и в результате включения LCD и портов с расчетом и выдачей результата через API может припоздниться. Он позднее выдает данные, но они сделаны на основе данных, которые измерены вовремя. То есть сами результаты измерений скорости начинают идти неравномерно, но данные, которые содержаться в них как бы могут считаться более менее снятыми через равные промежутки времени. Поэтому вопрос тут - можно ли утверждать, что LCD пишет чушь?

Да и как софт GUI считает объем, тоже интересно бы узнать. Он тоже может запрограммированный интервал использовать для расчетов, хоть и измеряет время между приходом данных, но вот учитывает ли его?

Давай сначала.

Я могу в прошивке задать время сна, которое сейчас стоит в 100мс.

Насколько я понимаю, это основной параметр, который влияет на частоту измерений. Других я не нашел, т.е. они были неизменны во время всех измерений.

Если GUI не включен, LCD не включен, весь цикл измерения занимает 185мс (сон + измерение + расчет + ... ).

Если же включить только LCD, то общее время уже не 185мс, а 200мс.

Мой метод замера времени я описал выше. Вот код:

    if(led_indicator)
    {
        hal_system_LEDOn(HAL_SYS_LED_0);
        led_indicator = 0;
    }
    else
    {
        hal_system_LEDOff(HAL_SYS_LED_0);
        led_indicator = 1;
    }

Он находится в функции HMI_PostAlgorithm_Update(), которая ВСЕГДА исполняется по окончанию измерения и получении скорости.

Т.е. LED включается или выключается в одном и том же месте в полном цикле измерения.

LCD же берет и умножает скорость (скажем, 100 литров в час) на 100 мс, когда надо умножать на 185 (если LCD выключен) или на 200 (если включен).

Это даёт неправильную цифру, что подтверждено экспериментально.

(длительность сна)

Кстати, таймер, используемый для длительности сна можно менять через конфигурацию. timerBaseAddress

http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/USSSWLib/USSSWLi...

По умолчанию, я так понимаю, стоит A2. А вот A0 более приоритетные прерывания имеет. Хотя вот написано, что A0 используется тоже, но почему-то в описании по тому поводу никаких предостережений нет. Возможно, он на лету перепрограммируется для другой функции, а потом на место встает.

Самый приоритетный таймер - TB0. Он даже приоритетнее Watchdog, но вот тут опции нет. Его можно, конечно, попробовать подсунуть. Он после немаскируемых прерываний идет.

Это даёт неправильную цифру, что подтверждено экспериментально.

Это меняет дело, раз эксперимент был. А пробовали те данные, которые выдает GUI с измерениями промежутков (вот тут ссылка на это: MSP430 и timestamps (комментарий)) суммировать и сравнивать с экспериментом? Становится похоже на правду?

я про метод измерения все понял, но тому, что я написал, как раз не противооечит. Вернее, не то, что я утверждаю, а предполагаю. Вот на картинке поясню.

Уходим в сон - просыпаемся - тут же измеряем сырые данные - считаем - выдаем - уходим в сон...

Вот время между «просыпаемся» и «тут же измеряем» может быть предельно маленьким и без задержек, а вот считаем-выдаем могут подзадержаться. Понимаешь, о чем я? Но результат расчета соответствует времени сразу после просыпания, а не моменту получения расчетного результата.

Мой метод замера времени я описал выше. Вот код:

А можешь измерить, влияет ли USB и LCD на время сна? То есть измерить время только сна. Может, именно время сна начинает гулять? Но тогда все будет предельно понятно.

Да, в GUI всё очень похоже на правду, нет ошибки в 2 раза как на LCD.

Сейчас попробую измерить время сна.

Сейчас попробую измерить время сна.

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

Время сна всегда 100мс.

Значит, дело во всём остальном.

LED включается до сна, выключается сразу после.

https://imgur.com/a/R9PX8nJ

Внизу видно, сон 100 мс, остальное 84 мс.

При включении LCD: сон 100 мс, остальное 109 мс.

Время сна всегда 100мс. Значит, дело во всём остальном.

Хм, тогда тот вопрос, что у меня созрел выше, остается в силе. Сырые данные он может снять быстро, буквально в первые моменты после выхода из сна, то есть равномерно через 100 мс, а вот математику считать он может долго, если расчет нетривиальный. Без исходного кода и понимания, какие там прерывания работают в момент измерения, кто там мешает сильно, трудно сказать. Поэтому замер времени между измерениями может быть только частичным решением, потому что вы не можете определить, когда закончилось непосредственно измерение АЦП и когда начался расчет на основе снятых данных. У вас всегда будет ошибка из-за этого, так как ты собираешься считать время между событиями «sampling+расчет — sampling+расчет», а не между «sampling-sampling»..

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

То, что данные о скорости потока устаревают на 70мс к моменту подсчета объема — совсем не проблема. Всегда будет погрешность «интегрирования», которое мы производим во время расчета объема.

Если мы умножаем скорость на 180мс, а пользователь нажал на кнопку и теперь нам надо умножать на 200, а мы всё так же умножаем на 180 — большая проблема.

То, что данные о скорости потока устаревают на 70мс

Вся фишка в том, что они могут устаревать с переменной задержкой и не с той, с которой меняется время между двумя расчетами. На числовом примере: 218 мс - фактическое время между двумя последовательными расчетами. Из них 100 мс - Время сна (точное), а измерение+расчет = 118 мс, само измерение - 50 мс, расчет - 68 мс. И вот это соотношение между временем измерения и расчета может гулять и не ясно в какой пропорции. Идеально было бы знать время между двумя измерениями, а не между двумя расчетами.

Может, измерять реальное время между двумя отсчетами и ввести какой-нибудь экспериментально полученный поправочный коэффициент на разность «измеренный период минус время сна», применяемый на каждом шаге суммирования, чтобы подогнать под реальный объем, чтобы уменьшить ошибку.

В общем, есть какие-то темные пятна, да. В общем, ладно. Все. Все, что мог, изложил. Дальше уже времени нет. Короче, бери таймер TimerB, так как он 100% свободный и программируй его как выше. Без прерываний можно, ему хватит диапазона и получишь весьма точное время. Там все предельно просто.

Да, вроде бы всё теперь ясно. Спасибо за помощь!

Буду настраивать таймер.

rate = sleep time

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

само измерение - 50 мс, расчет - 68 мс.

А вот тут я, кажется, нагнал. Во время измерения мат. расчет не входит. Если я правильно понимаю, USS_startUltrasonicMeasurement и USS_startLowPowerUltrasonicCapture выполнит только измерение, но не будет ничего считать, пока не попросят (преобразования Гилберта и др. методы). А расчет - это отдельная функция, насколько я понял: USS_runAlgorithms и т .п. из Algorithms API и она работает непосредственно над семплированными данными. Я что-то думал, что и измерение и расчет в одной функции. А совершенно не так. Тогда получается, да, что и LCD, и порты влияют именно на время физического измерения.

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

Нет-нет, я не мерил время измерения, только вместе с алгоритмами. Завтра измерю.

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

Они знают. Под LCD код они написали чисто для галочки, насколько я понимаю. Используйте GUI, типа.

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

По идее должно занимать около 22мс и быть стабильным.

Первый сенсор излучает звук, второй принимает, это около 1мс. Потом задержка в 20мс для стабилизации сенсоров. Потом второй излучает, первый принимает. Это ещё 1мс.

По идее должно занимать около 22мс и быть стабильным.

Если будет так, то можно вернуться назад и дополнительно рассмотреть вариант с равномерным интервалом измерений по таймеру. То есть задается интервал, который заведомо больше времени измерения и расчета. Скажем, 200 мс и выше. По событиям таймера делать измерения, считать и складывать во временный буфер, а потом в удобный момент отправлять это все скопом. Можно и сразу по одному. но это все если измерение по времени стабильно, а не скачет в диапазоне 10 мс.

Плюс равномерной шкалы будет в случае, если нужно будет гнать измерения по интерфейсу (не текущий объем, а мгновенное значение скорости). Если ты знаешь, что данные сняты с шагом 200 мс, то и нет проблем с интерпретацией. Данные могут приходить неравномерно, но ты точно знаешь, что там содержатся отсчеты каждые 200 мс и измерять на компьютере интервалы не надо. Вот сейчас информации об интервале нет и GUI вынуждено считать интервал по таймеру, что дает ошибку. Минус в том, что надо заведомо знать, сколько времени работает алгоритм, чтобы знать минимально возможный интервал отсчетов, иначе до следующего измерения не успеет посчитать.

А если измерять фактическое время между измерениями на плате (как вот сейчас рассматриваем по схеме сон-измерение-расчет-сон-...), то тут явный плюс в том, что не надо знать, сколько работает алгоритм. Сколько проработал, столько и проработал. Как закончил, то сразу (или после сна) начинать следующее измерение. Считать можно интервалы сразу после measurement. Минус в том, что сетка неравномерная. Но если это не так важно, то засекание времени между измерениями кажется проще и быстрее реализовать. А с передачей через порт можно подумать. Ведь можно в посылку к данным загнать и timestamps. Как-то так.

Минус в том, что сетка неравномерная.

Это не минус, на самом деле. Некоторые производители даже приподносят это как плюс. Есть такое явление как пульсирующий поток. И если частота измерений кратна частоте пульсаций потока — проблема.

Поэтому я вникаю в таймеры.

Как и предполагалось, время самого измерения (USS_startLowPowerUltrasonicCapture) стабильно и занимает 10.2 мс.

Но это так, чисто ради информации.

Я тут нашёл API для таймеров.

Насколько я понял, мне надо запускать как-то так:

Timer_A_initContinuousModeParam  measurementTimerParams = {.clocksource=TIMER_A_CLOCKSOURCE_ACLK, .clockSourceDivider=TIMER_A_CLOCKSOURCE_DIVIDER_1, .timerInterruptEnable_TAIE=TIMER_A_TAIE_INTERRUPT_DISABLE, .TIMER_A_DO_CLEAR=timerClear, startTimer=1};

Timer_A_initContinuousMode(TIMER_A1_BASE, measurementTimerParams);

...
...


Timer_A_stop(TIMER_A1_BASE);

uint16_t timer_count;
float elapsed_time;

timer_count = Timer_A_getCounterValue(TIMER_A1_BASE);
elapsed_time = (float) (timer_count / 32768);

Timer_A_initContinuousMode(TIMER_A1_BASE, measurementTimerParams);

Пойду тестить.

После исправления опечаток всё заработало, вроде бы.

Всем спасибо за помощь!

elapsed_time = (float) (timer_count / 32768);

Включу пуриста. Это лучше делать после рестарта таймера, хоть это и микросекунды (хотя арифметика с плавающей точкой медленная). А то получается, что это деление не учитывается в замере времени. Вообще время между остановкой, чтением и перезапуском лучше сделать как можно меньше (опять с точки зрения пуриста).

timer_count = Timer_A_getCounterValue(TIMER_A1_BASE);

Я бы вообще лучше напрямую с регистрами работал. Глянул API. Вот эта функция как бы натаскана на чтение таймера без его остановки и использует мажоритарный принцип, чтобы отсечь неправильное чтение. То есть он читает подряд, скажем, три раза и если два раза одно и то же значение, а третье запорото, то возвращает значение, которое выпало два раза. Близость «голосов» управляется переменной TIMER_A_THRESHOLD. В случае, когда таймер остановлен, три раза будет прочитано одно и то же значение. Не так страшно, в общем-то - это тоже все микросекунды. Кстати, это вот тут описано тоже MSP430 и timestamps (комментарий) . У тебя именно ситуация, когда ACLK и MCLK асинхронно идут - разные генераторы.

Но если ты останавливаешь таймер, то тебе, в общем-то не надо читать несколько раз подряд и выбирать значение по мажоритарному принципу. Если остановил таймер, то достаточно прочесть один раз регистр TA1R, и все. Об этом в user guide и говорится. Потом сбросить и запустить снова.

Но это опять придирки, в общем-то. Такая функция хороша, когда нельзя останавливать таймер.

Да, ты прав. Поправил.

       Timer_A_stop(TIMER_A1_BASE);      
       timer_count = Timer_B_getCounterValue(TIMER_A1_BASE);
       
       Timer_A_initContinuousMode(TIMER_A1_BASE, &measurementTimerParams);

Я проверил, сейчас работает и считает всё правильно!

Напрямую с регистрами потом попробую. И так 3 дня потратил на эти таймеры. Почти все инструкции и примеры работы рассказывают о интераптах, хороших объяснений не так много.

Скорее всего, всё равно буду аутсорсить разработку платы и прошивки.

У тс-а проблемы с измерениями при операциях ввода-вывода, т.е. тогда, когда чип занят какой-то работой. Я бы посадил основной функционал на прерывания.

Ынтырпрайз, безсмысленный и безпощадный.

На пред работе IDE под TI C2000 покупали на все рабочие места. Потому что это дешевле, чем перейти на другую платформу.

Суда по его измерениям, порт и LCD влияют только на время расчета, на математику, а на выполнение самих измерений не влияют. Так что не помогут прерывания тут никакие. Математика там (преобразование Гильберта) даже и без ввода-вывода будет считаться переменное время (алгоритм может по разным веткам ходить в зависимости от данных). Но дождаться рачета алгоритма все равно надо - данные нужны каждый отсчет. Так что...

Что касается таймеров, то тут как раз-таки надо без прерываний. Ему надо измерять интервалы, ну, до 2 секунд. Это даже сетка таймера не успеет переполниться. То есть он вообще без прерываний будет работать автономно и его ни одно более приоритетное прерывание не задержит. Таймер будет считать даже если процессор в глубокий сон уйдет (а у него так и есть).

Ещё и оказалось, что при нажатии на кнопок, контролирующих LCD, происходит какая-то адская дичь, которая занимает несколько секунд и фризит всё (ну или почти всё). Я отключил его к чертям, только мешает.

Но а таймер с GUI работает нормально теперь, всё точно считает.

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

А в чем проблема? Может, тогда сетку таймера расширить? Сейчас у тебя 2 секунды с точностью 1/32768 сек. Можно ставить делитель на 2 или 4. Будет диапазон 4 сек, 8 сек с точностью 1/16384 и 1/8192 сек соответственно, что тоже достаточно для твоих нужд. И тогда реакция на кнопки тоже измеряться будет, но там будут уже промежутки больше 1 секунды, если такие задержки действительно, что, конечно, приведет к ошибкам, но это только один раз же, а не постоянно.

Я бы еще, кстати, при расчете объема делал бы какую-нибудь интерполяцию. Например, самую примитивную — линейную. Сейчас, в общем-то, ступеньки считает.

Точно! Сейчас впихну делитель и протестирую.

Так как у меня примерно одинаковые промежутки между измерениями (кроме как при использовании кнопок :D), интерполяция не имеет особого смысла (каждое значение используется дважды), хотя и почти не добавляет оверхед. Можно будет протестировать, если точность будет проседать на перемененных скоростях.

(каждое значение используется дважды), хотя и почти не добавляет оверхед.

Расшифруй. Имеется в виду, что площадь считается что-то типа 1/2*(прежний отсчет+новый отсчет)*время? Если да, то это и есть по сути своей расчет площади под кусочно-линейным графиком. Это площадь трапеции.

Ещё и оказалось, что при нажатии на кнопок, контролирующих LCD, происходит какая-то адская дичь, которая занимает несколько секунд и фризит всё (ну или почти всё). Я отключил его к чертям, только мешает.

Но вообще, раз уж расчет объема вещь важная, то этот процесс должен быть самым приоритетным. Кнопки можно задерживать, а измерения и расчет нет. Газ назад вернуть нельзя уже будет и проиграть по новой. Поэтому, конечно, софт тут надо соответствующим образом переписать.

А кнопки не могут там использовать таймер, который ты используешь? А то, видимо, ресурсы, которые расписаны в руководстве на библиотеку не имеют отношения к ресурсам, которые используются программой, которая этой библиотекой пользуется. Например, на debouncing. Если кнопки и ты напали на один таймер, то последствия непредсказуемые. Может, как раз фриз из-за этого.

Имеется в виду, что площадь считается что-то типа 1/2*(прежний отсчет+новый отсчет)*время?

Ну это же и есть твоя линейная интерполяция, да? Или я что-то не так понимаю?

В этом случае каждое измерение используется дважды, как «прежний отсчет» и как «новый отсчет».

С делителем всё работает, кстати, спасибо за подсказку.

С дисплеем происходит дичь, так как по нажатию кнопки он начинает скроллить название выводимой информации (V-o-l-u-m-e i-n l-i-t-e-r-s), что занимает хороших 3-5 секунд, в зависимости от текста. И это всё происходит, насколько я понимаю, в основном потоке.

Ну это же и есть твоя линейная интерполяция, да? Или я что-то не так понимаю?

Если вот так вот делаешь, как я написал, то, да, как раз линейная интерполяция. Она и есть

С дисплеем происходит дичь, так как по нажатию кнопки он начинает скроллить название выводимой информации (V-o-l-u-m-e i-n l-i-t-e-r-s), что занимает хороших 3-5 секунд, в зависимости от текста. И это всё происходит, насколько я понимаю, в основном потоке.

Это поведение надо переписывать, конечно. Не дело, так как прерывает измерения и расчет. Измерения и расчет должны быть более приоритетной задачей иначе профукаешь объемы. :) Тогда надо подумать, как делать лучше. Можно, конечно, по прерываниям, как советовали выше. Тогда выполнение основного потока прерывается и выполняется процедура измерения и расчета, а потом возвращается в основной поток. То есть всегда более приоритетная вещь. Есть и другие варианты.

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

Я так понимаю, что у тебя в плате этой просто демонстрационный код, не претендующий на промышленное применение. Он сделан, чтобы продемонстрировать, как работать с библиотекой.

http://theproteus.ru/

И это всё происходит, насколько я понимаю, в основном потоке.

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