Форум: Техническая поддержка

Вы описываете функционал, который потенциально может быть поддержан в обновляемом FPGA и в API. Но здесь сразу нужно спросить: 
"указать, на каком месте одной страницы буфера воспроизведение закончить" - Непонятно, для чего. Для того, чтобы принудительно прервать очень долгий цикл воспроизведения? 
"с какого места другой страницы начать воспроизведение сразу после этого" - в циклическом режиме это место всегда жестко задано - с первого отсчёта циклической записи.
В циклическом режиме в неактивную страницу отсчёты записываются последовательно, без адреса (как в FIFO). Перед записью FIFO очищается.
Важно отметить, что смысл циклического режима в том, чтобы активная страница работала в реальном времени циклического воспроизведения, а неактивная -  не в реальном, чтобы в неё была возможность неспешно подкачать следующий циклический сигнал. Но, судя по тому, что Вы описываете, Вам необходимо, чтобы обе страницы находились в реальном времени процессов подкачки и воспроизведения и работали по типу "двойной буферизации"...

Глобально циклический режим нужен для экономии ресурсов компьютера в ситуации, когда нужно повторять идентичные циклы развёрток большое количество раз, и только иногда форму сигналов развёрток менять. Хочется избежать многократной загрузки в LTR-35 одной и той же информации (что нужно делать в потоковом режиме).

Указание мест перескока "откуда" на одной странице буфера и "куда" на другой требуется для того, чтобы "сшить" старый сигнал развёртки с новым в наиболее удачном месте. И при необходимости подправить фазу сигнала. (Например, если развёртка управляет токами в катушках большой индуктивности, то нужно, чтобы не произошло скачка, то есть нужно подобрать для перескока такие фазы старого и нового сигнала, чтобы у них в этих фазах совпадали амплитуды.)

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

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

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

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

Алексей, принцип теперь понятен - нужен общий случай сшивки циклов. Да, это возможно - интересный режим.
Значит, получается, что для циклического режима Вам нужен следующий дополнительный функционал LTR35 (прошу подтвердить):
1. Переход от одного цикла к другому в произвольно заданных точках этих циклов. - После закачки с ПК следующего сигнала и номеров отсчётов сшивки (i и j),  после прихода асинхронной команды смены страниц, указатель буфера воспроизведения должен дойти до i-того отсчёта и синхронно перескочить на j-тый отсчёт в другой странице  - в процессе смены страниц.
2. Синхронный цифровой ввод с 2-х входов.

Да, подтверждаю, всё верно.

Ещё есть вопрос про поведение LTR-35 в случае, когда предыдущая команда переключения страниц ещё не выполнена, но уже пришла следующая (или несколько). Поведение (для наших целей) в этой ситуации может быть любым, но предсказуемым. (Специально создавать такие ситуации не предполагается, но желательно, чтобы при случайном возникновении они не приводили к непредсказуемому поведению.)

Сейчас это работает так. Когда в LTR35 событие смены страниц происходит, то LTR35 высылает подтверждение в ПК, после чего ПК должен сначала подкачать следующий сигнал, а потом только выслать следующую команду на смену страниц, и т.д.
Тот случай, который описываете Вы, он нештатный - я затрудняюсь сейчас сходу сказать, что произойдёт - это нужно анализировать.
С другой стороны, Ваш случай выглядит как одна из возможных программных ошибок ПО верхнего уровня (нарушение взаимодействия с LTR35), и поведение LTR35 во всех случаях программных ошибок я вряд ли смогу описать...

Отредактировано Инженер (07.11.2020 23:51:42)

Алексей, устраивает ли Вас такой штатный вариант взаимодействия? - это основной вопрос. Если в Вашей задаче обоснованно могут возникнуть отклонения от этого взаимодействия, то для описания поведении LTR35 в Вашем ПО, я полагаю, нужен конкретный пример программирования LTR35, по которому мы восстановим конкретную последовательность низкоуровневых команд в LTR35, и далее, при симуляции этого случая в среде верификации проекта FPGA, точно определим поведение LTR35 и опишем путь возврата к штатному варианту взаимодействия.
Но, ещё раз подчеркну, что описанный Вами случай выглядит как ошибка ПО верхнего уровня логики (и смысла) циклического режима работы LTR35:
1. Подкачивать очередные данные можно только после подтверждения от LTR35 смены страниц (кроме случая заполнения первой страницы перед началом воспроизведения данных).
2. Высылать в LTR35 следующую команду смены страниц можно тогда, когда соответствующие данные в текущую неактивную страницу были подкачены (согласно п.1).

Отредактировано Инженер (08.11.2020 09:25:06)

Да, такой вариант полностью устраивает.

(Первоначально я не понимал, что после смены страниц высылается подтверждение. Думал, что этот момент нужно будет отлавливать самостоятельно. Отсюда и возник вопрос.)

Просьба уточнить про цифровые входы. В руководстве (с сайта) указано

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

И как происходит опрос двух каналов цифрового входа в одном цикле, когда оба они используются: одновременно или по очереди(через пол-периода?)?

Алексей, Вы правильно понимаете. Потоки цифрового ввода-вывода синхронны, их скорости кратны и необходимые времена установления сигналов выдерживаются при непосредственном соединении цифровых выходов и входов.
В двухканальном режиме введённые в сдвиговый регистр биты цифрового входа передаются в 12-битовых полях 24-битного формата данных от LTR35. Прошу Вас подождать выхода руководства пользователя на следующей неделе, где эти вопросы будут отражены подробнее.

Отредактировано Инженер (08.11.2020 17:57:05)

Выложена ревизия 4.0.0 руководства пользователя LTR
https://www.lcard.ru/download/ltr.pdf
- Дополнены техданные о LTR35.
- Характеристики скорректированы по результатам недавно проведённой сертификации Установки измерительной LTR.

Прошу уточнить, какие из имеющихся у вас в продаже плат клеммников можно использовать с модулем LTR-35.

В частности, годится ли для этого плата CR-24? Возможно ли на ней скоммутировать BNC-разъёмы на нужные аналоговые выходы?

Алексей,
LTR35 совместимы с клеммниками DB-37F-INCREASER  https://www.lcard.ru/products/accesories/db-37f-i
С клеммниками CR-... совместимости нет.
Читайте также https://www.lcard.ru/support/faq/terminal_block_use

Подскажите, где можно взять примеры программирования для ltr35.

Во первых Вам в любом случая понадобится документация по ltr35api: https://www.lcard.ru/download/ltr35api.pdf

Примеры в конечном виде еще не были подготовлены, но можно взять текущие рабочие тестовые варианты:
вывод в циклическом режиме - https://gitlab.com/l-card/acq/devices/l … cle/main.c
пример, на котором отлаживался синхронный ввод в потоковом режиме: https://gitlab.com/l-card/acq/devices/l … eam/main.c (параметры описаны в комментарии в начале, разные варианты перезапуска использовались больше для отладки корректного ввода-вывода при разных вариантах перезапуска).

Также на всякий случай отмечу, что если нужно, то под Linux есть версия демонстрационной программы выставления простых сигналов на LTR35 (пакет ltr35gen).

После прочтения руководства по API возник вопрос.

Там сказано, что настройка арифметического генератора определяется структурой типа TLTR35_ARITH_SRC_CONFIG, в которой содержится начальная фаза double Phase и приращение фазы double Delta. Правильно ли я понимаю, что каждый раз фаза будет увеличиваться на Delta с округлением, свойственными операции double+double, и тем самым при длительной работе будут накапливаться ошибки округления? Возможно ли этого избежать и задать период работы арифметического генератора кратным целому числу периодов частоты преобразования ЦАП?

Алексей, "арифметические генераторы" реализованы внутри LTR35 в FPGA. В каждом генераторе логика приращения тригонометрического угла на угол Delta  реализована на основе целочисленного 32-битного сумматора и регистра-аккумулятора (в FPGA), что исключает накопление ошибки округления в процессе накопления угла. Этот функционал FPGA (прошивка 24) упомянут в https://www.lcard.ru/download/ltr.pdf , п.17.3.2, но, как я понимаю, недостаточно полно объяснён.

Минимальное приращение угла (в радианах): пи*2^-31, где пи = 3,141...

Отредактировано Инженер (24.11.2020 19:09:59)

А есть ли возможность точно проконтролировать выставляемые значения начальной фазы и приращения?

То есть либо явно их указать в виде целочисленного количества минимальных приращений пи/2^-33 радиан, либо узнать алгоритм, по которому происходит преобразование долей градусов типа double в целочисленные количества минимальных приращений (с учётом ошибки округления).

Сейчас как выяснилось не совсем корректно идет пересчет по формуле code = (DWORD)((double val) * 0xFFFFFFFF / 360), т.к. код 0xFFFFFFFF - на один шаг меньше 2*пи и правильнее думаю округлить до ближайшего.
Завтра выложу вариант с пересчетом (DWORD)((double val) * 2^16 * 2 ^16) / 360 + 0.5).
Минимальный шаг все же 2*пи/2^32 = пи/2^31

Отредактировано Алексей L Card (24.11.2020 19:17:03)

В принципе пока эта возможность еще не используется клиентами, можно сделать и задание фазы кодом, просто введя отдельную функцию заполнения этого кода по double, для возможности установить любым способом.

Да, было бы очень хорошо иметь возможность задать начальное значение фазы и дельту непосредственно в кодах, загружаемых в модуль LTR-35 без каких-либо промежуточных преобразований. Чтобы не приходилось перепроверять. Приближённые вычисления с double всегда могут приподнести сюрприз, работая по-разному с разными версиями компиляторов и библиотек.

Прошу уточнить, как нужно компилировать примеры для ltr35 и что перед этим обновить.
Возникает ошибка:

$ gcc main.c -o main -lltr35api
/usr/bin/ld: /tmp/ccglSyBt.o: неопределённая ссылка на символ «LTR_GetCrates»
//usr/lib/libltrapi.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

Нужно добавить ещё -lltrapi, т.к. используются функции из общей библиотеки ltrapi для получения списка крейтов и модулей.

Прошу уточнить.

Верно ли я понимаю, что физические выходы аналоговых каналов LTR-35 нумеруются от 1 до 8 (OUT1 1:1 и OUT1 1:10, OUT2 1:1 и OUT2 1:10, ..., OUT8 1:1 и OUT8 1:10), а соответствующие им программные каналы (ch_num) - от 0 до 7, и каждому выходу с номером N соответствует канал с номером (N-1).

А также, что аналогичным образом нумеруются арифметические генераторы: для генератора, выходам которого присвоен номер N (1, 2, 3, 4; N=1 для LTR35_CH_SRC_SIN1 и LTR35_CH_SRC_COS1 и т. д.) в программе нужно использовать индекс (N-1).

Алексей. - В соответствии с этой статьёй FAQ: https://www.lcard.ru/support/faq/signal_numbering.
Так, функциональные узлы - арифметические генераторы в руководстве пользователя  на Рис. 17-2. LTR35-1-8. "Функциональная схема" -  нумерованы с единицы как физические сущности, но программно они адресуются (индексируются), в данном случае, с нуля. Этот принцип для всех изделий "Л Кард" подтверждает п. 3.1 (стр.43) руководства пользователя LTR.

Отредактировано Инженер (26.11.2020 06:22:24)

Уточните, пожалуйста, как следует запускать генерацию, если используются только арифметические генераторы (hltr35.State.SDRAMChCnt=0).
Функция LTR35_SwitchCyclePage в этом случае выдаёт ошибку - в буфер ничего не загружено.
Возможна ли для этой цели загрузка в буфер фиктивных данных? Если да - такие фиктивные данные могут быть любыми или нужно подготовить их каким-то специальным образом?