kovalgg писал(а):функция tda7719SetMiddleFilter - reg10 |= (aPar->tune[AUDIO_TUNE_MIDDLE_QUAL] <TDA7719_MIDDLE_QFACT_OFT);
и функция tda7719SetBassFilter - reg11 |= (aPar->tune[AUDIO_TUNE_BASS_QUAL] << TDA7719_BASS_QFACT_OFT);
В присваивании первой функции ошибка? Я правильно понял?
Нет, тут всё правильно.
Вот кусочек из даташита на TDA7719:
Для настройки фильтра средних частот нужно записать 5 байтов Gain/Attenuation по нулевому смещению и два байта Middle Q Factor по смещению 5.
Что делает код:
Код: Выделить всё
int8_t value = (aPar->flags & AUDIO_FLAG_BYPASS) ? 0 : aPar->tune[AUDIO_TUNE_MIDDLE];
uint8_t reg10 = (value > 0) ? (31 - value) : (15 + value);
reg10 <<= TDA7719_MIDDLE_ATT_OFT;
reg10 |= (aPar->tune[AUDIO_TUNE_MIDDLE_QUAL] < TDA7719_MIDDLE_QFACT_OFT);
1 строка.
Если пользователем задана настройка
AUDIO_FLAG_BYPASS (отключены все аудио фильтры), используем значение 0. Иначе - значение, заданное пользователем
aPar->tune[AUDIO_TUNE_MIDDLE] - некое число от -15 до 15. Например, -14
2 строка.
Мы не можем просто записать это число в регистр. Согласно табличке значению -14дБ соответствует число 1 (00001b). Вот его здесь пересчитываем и в переменной reg10 и запоминаем
3 строка.
Сдвигаем это число по смещению TDA7719_MIDDLE_ATT_OFT = 0. Фактически ничего не происходит, но для унификации кода так удобнее - сдвиги могут быть и ненулевые, как дальше.
4 строка.
Дописываем в reg10 значение
aPar->tune[AUDIO_TUNE_MIDDLE_QUAL], заданное пользователем (от 0 до 3), но сдвинутое на TDA7719_MIDDLE_QFACT_OFT = 5 позиций влево.
Просто напомню, что запись
var <<= value (как и прочие подобные - обычно встречается
+=) означает
var = var << value. А
var |= value - это, соответственно,
var = var | value;
Дальше уже рассчитанное значение reg10 пишется по I²C шине в аудиопроцессор.
kovalgg писал(а):И растолкуйте пожалуйста - static const AudioGrid gridVolume = {NULL, -79, 15, (int8_t)(1.00 * STEP_MULT)} - умножение на STEP_MULT.
У многих из поддерживаемых контроллеров шаг настройки параметров не целый, а, например, 1.25дБ, или 1.5дБ. Получается, например, такое соответствие значения в регистре и реальных децибелов:
Это чисто для удобства хранения значений аудиопараметров в ОЗУ (в 8-битных ячейках). А уже для вывода на экран (функция
canvasShowTune()) происходит перерасчёт (
showValue = value * mStep / STEP_MULT).
Можно было бы хранить и дробные числа, но тогда пришлось бы по 4 байта на каждый использовать.
kovalgg писал(а):И растолкуйте пожалуйста - static const AudioGrid gridVolume = {NULL, -79, 15, (int8_t)(1.00 * STEP_MULT)} - умножение на STEP_MULT.
Это как раз то, что я и описывал выше. Например,
# tda7418.c
static const AudioGrid gridVolume = {NULL, -79, 15, (int8_t)(1.00 * STEP_MULT)}; // -79..15dB with 1dB step
# tda731x.c
static const AudioGrid gridVolume = {NULL, -63, 0, (int8_t)(1.25 * STEP_MULT)}; // -78.75..0dB with 1.25dB step
В первом случае шаг регулировки равен 1дБ, поэтому grid.mStep равен 8.
Таким образом, raw значение -79 в регистре таким и останется при выводе:
showValue = -79 * mStep / STEP_MULT = -79 * 8 / 8 = -79
Во втором случае шаг регулировки равен 1дБ, поэтому grid.mStep равен 1.25*8 = 10.
Таким образом, raw значение -63 в регистре таким и останется при выводе:
showValue = -63 * mStep / STEP_MULT = -63 * 10 / 8 = -78,75
kovalgg писал(а):dcOft - это типа АРУ
Это находится среднее значение, чтобы потом, вычев его, выровнять полученный набор данных относительно нуля. Тогда не будет ложного ненужного первого столбика спектрограмме, который обычно бывает, если есть постоянная составляющая в сигнале (0 Герц).
