Помогите пожалуйста разобраться с синхронным вводом выводом. Вот такой код

void QAdcObject::init()
{
    RzaApplication* app = (RzaApplication*)qApp;
    char serial[2][X502_SERIAL_SIZE];
    qint32 err, devs;

    if(m_dev != 0)
    {
        m_bRun = false;
        X502_Close(m_dev);
        X502_Free(m_dev);
    }

    err = E502_UsbGetSerialList(serial, 2, X502_GETDEVS_FLAGS_ONLY_NOT_OPENED, (uint32_t*)&devs);
    if(devs == 0)
    {
        qDebug() << "no device found";
        return;
    }
    m_dev = X502_Create();
    err = E502_OpenUsb(m_dev, serial[0]);
    if(err != 0)
    {
        qDebug() << "open e502 failed";
        X502_Free(m_dev);
        m_dev = 0;
        return;
    }

    X502_SetMode(m_dev, X502_MODE_FPGA);
    err = X502_SetLChannelCount(m_dev, app->m_channel.count());
    for(int i = 0; i < app->m_channel.count(); i++)
    {
        err = X502_SetLChannel(m_dev, i, i, X502_LCH_MODE_COMM, X502_ADC_RANGE_10, 1);
    }

    X502_SetSyncMode(m_dev, X502_SYNC_INTERNAL);
    X502_SetSyncStartMode(m_dev, X502_SYNC_INTERNAL);

    double fAcq = 2000000.0, fAdcFrame = 50.0 * (double)app->m_pnts;
    err = X502_SetAdcFreq(m_dev, &fAcq, &fAdcFrame);

    X502_StreamsEnable(m_dev, X502_STREAM_ADC);

    X502_SetDinFreq(m_dev, &fAdcFrame);
    X502_StreamsEnable(m_dev, X502_STREAM_DIN);

    X502_SetOutFreq(m_dev, &fAdcFrame);
    X502_StreamsEnable(m_dev, X502_STREAM_DOUT);

    err = X502_Configure(m_dev, 0);

    memset(m_inputs, 0, sizeof(quint16) * 6);
}

void QAdcObject::startAdc()
{
    RzaApplication* app = (RzaApplication*)qApp;
    qint32 buffer[256];
    qint32 rcv_size, adc_size, inp_size, err;

    X502_PreloadStart(m_dev);
    out_buff[0] = 0;
    err = X502_PrepareData(m_dev, 0, 0, (uint32_t*)out_buff, 1, 0x0, (uint32_t*)buffer);
    err = X502_Send(m_dev, (uint32_t*)buffer, 1, 2000);
    X502_StreamsStart(m_dev);

    m_bRun = true;
    int count = app->m_channel.count();

    address  = 0;
    m_relays = 0;

    int counter = 0;
    while(m_bRun)
    {
        rcv_size    = count;
        out_buff[0] = address;
        err = X502_PrepareData(m_dev, 0, 0, (uint32_t*)out_buff, 1, 0x0, (uint32_t*)buffer);
        err = X502_Send(m_dev, (uint32_t*)buffer, 1, 2000);

        rcv_size = X502_Recv(m_dev, (uint32_t*)buffer, count + 1, 2000);

        adc_size = count;
        inp_size = 1;
        err = X502_ProcessData(m_dev, (uint32_t*)buffer, rcv_size, X502_PROC_FLAGS_VOLT, adc_data, (uint32_t*)&adc_size,
                                                                              (uint32_t*)inp_buff, (uint32_t*)&inp_size);

        m_inputs[address++] = inp_buff[0];
        if(address == 6) address = 0;
        }
    }
    X502_StreamsStop(m_dev);
}

ОС - Линукс, частота АЦП (на канал) 2 МГц, сбора кадра - 4 кГц, число каналов АЦП - 11.
Кроме сбора аналоговых данных от этой функции необходимо еще чтение 16 разрядов с цифровых входов по адресу некоторого внешнего регистра, указанному в out_buff[0] (3 мл.бита от 0 до 6).. Для простоты текста я не привожу вывода сообщений об ошибках потому что в этом варианте их нет.

А вот и не получается. Такое ощущение, что синхронная запись не выполняется, для всех значений  в out_buff[0] читается одно и тоже значение в inp_buff[0].
Если все тоже самое сделать (запись/чтение цифровых данных) в асинхронном режиме, то все работает (конечно при соответствующих изменениях в функции инициализации). Но этот вариант слишком медленный для моей задачи.

Да, кстати, еще замечание: при асинхронной записи функция
X502_AsyncOutDig(m_dev, out_buff[0], 0)
возвращает ошибку с кодом 1004. В списке кодов ошибок такого кода нет, но тем не менее в асинхронном режиме запись работает.

Если необходимо могу выложить код асинхронного варианта.

По поводу ошибки при асинхронном выводе, то такая проблема была, но она должна была быть исправлена в последней версии FPGA (0.11) - на Linux можете взять пакет
lxfw-update последней версии - там утилита и новая прошивка должны были быть в нем и обновить можно, запустив e502-fpga-update-all.sh.
Кстати там была исправлена и некоторая проблема, которая влияла на синхронный вывод.

Не до конца пока понял, как при таком выводе синхронизируются моменты вывода и входные данные, т.к. все же есть некая задержка между тем как данные будут сняты с входов и тем как их успеет принять программа на верхнем уровне. Если нужно перебирать значения на выходах всегда в одном порядке, то я бы воспользовался бы циклическим выводом, записав перед стартом последовательность всех адресов на вывод и модуль бы уже аппаратно бы их выводил с заданной частотой (только нужно учесть, что частота вывода из определенного набора и ровно 4 КГц там вроде не получится -- я бы выводил на 1МГц но уменьшил бы частоту изменения за счет повтора данных - тогда можно вообще сделать, чтобы изменения выходов были посередине кадра, чтобы было время на установление данных -- у вас же наверняка есть электрическая задержка сигналов между установкой адреса и появлением данных).
При этом значения входов для первого отсчета будет соответствовать еще не выставленным выходам, второго кадра - первому коду и дальше по кругу.

Вот спасибо, обновление прошивки помогло для случая асинхронного вывода/ввода - эта странная ошибка исчезла.
Для синхронного варианта вроде помог следующий вариант; добавил счетчик после чтения входных данных типа вот такого:

           counter++;
            if(counter == 20)
            {
                counter = 0;
                m_inputs[address++] = inp_buff[0];
                if(address == 6) address = 0;
            }

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

Правильно ли я понял, что Вам нужно просто с заданной частотой читать значения входов при определенных значениях выходов, при этом значения выходов по сути должны перебираться последовательно по кругу из заданного набора кодов (у Вас в примере от 0 до 6)?

да, примерно так.. только есть еще один вариант - в адрес может асинхронно по времени добавляться 4 бит, а в  а старшие биты -  некоторая управляющая информация для внешнего оборудования.. Тогда при чтении должен читаться регистр состояний. Т.е. все несколько сложнее простого перебора чтения внешних данных по адресам от 0 до 5.

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

Если эти доп. данные влияют на вход, то с асинхронными данными и этой дополнительной информацией есть требования ко времени считывания реакции и если есть, то какое?

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

Проблема в том, что как я и раньше писал, хотя E502 вводит и выводит синхронно, но от реального ввода данных модулем до того как прочитаете данные в программе проходит некая задержка. Как и при выводе. Соответственно она у Вас и получается видимо порядка 20 циклов.

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

Соответственно для асинхронного вывода эта задержка всегда будет (Вы в примере по сути и сводите синхронный вывод к асинхронному, т.к. по сути формируете данные асинхронно).

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

Т.е. перед стартом можно выполнить один раз что-то вроде:

#define DOUT_FREQ         1000000
#define OUT_PERIOD_WORDS (DOUT_FREQ/DIN_FREQ)
#define OUT_PERIOD_CNT   6
#define OUT_POINTS      (OUT_PERIOD_CNT*OUT_PERIOD_WORDS + OUT_PERIOD_WORDS/2)


static int32_t f_preload_signal(t_x502_hnd hnd) {
    int32_t err = X502_ERR_OK;

    unsigned i, p, put_pos = 0;

    uint32_t dout_wrds[OUT_POINTS];
    uint32_t snd_wrds[OUT_POINTS];

    for (i = 0; i < OUT_PERIOD_WORDS/2; i++) {
        dout_wrds[put_pos++] = 0;
    }

    for (p = 0; p < OUT_PERIOD_CNT; p++) {
        for (i = 0; i < OUT_PERIOD_WORDS; i++) {
            dout_wrds[put_pos++] = p;
        }
    }

    err = X502_OutCycleLoadStart(hnd, OUT_POINTS);
    if (err == X502_ERR_OK) {
        err = X502_PrepareData(hnd, 0, 0, dout_wrds, OUT_POINTS, 0, snd_wrds);
    }
    if (err == X502_ERR_OK) {
        int32_t snd_cnt = X502_Send(hnd, snd_wrds, OUT_POINTS, 3000);
        if (snd_cnt < 0) {
            err = snd_cnt;
        } else if (snd_cnt != (int)OUT_POINTS) {
            err = X502_ERR_SEND_INSUFFICIENT_WORDS;
        }
    }
    if (err == X502_ERR_OK) {
        err = X502_OutCycleSetup(hnd, 0);
    }

    return err;
}

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

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

Далее на вводе нужно будет только еще определить, каким принятым кадрам соответствует асинхронная информация. Я бы один бит с выхода завел на вход, который всегда устанавливается в 1 при асинхронном выводе и в 0 при обычном опросе, тогда на входе можно понять, какие данные чему соответствуют.

Все это интересно конечно,  но пока я отвлекся на аналоговые входы. 
И я вот что обнаружил. На АЦП подаю три фазы напряжения, сдвинутые на 0, 120 и 240 градусов. Код основного цикла выглядит так:

   while(m_bRun)
    {
        out_buff[0] = address;
        if(m_relays != 0)
        {
            out_buff[0] |= m_relays;
            if(m_startRelay)
            {
                m_startRelay = false;
                counter = 0;
            }
        }
        out_buff[0] |= 0x4000;

        err = X502_AsyncOutDig(m_dev, out_buff[0], 0);

        rcv_size = X502_Recv(m_dev, (uint32_t*)buffer, count, 2000);
        adc_size = rcv_size;
        err = X502_ProcessAdcData(m_dev, (uint32_t*)buffer, adc_data, (uint32_t*)&adc_size, X502_PROC_FLAGS_VOLT);

        err = X502_AsyncInDig(m_dev, (uint32_t*)inp_buff);
        if(m_relays == 0)
        {
            m_inputs[address++] = inp_buff[0];
            if(address == 6) address = 0;
        }        
        else
        {
            counter++;
            if(counter == 2)
            {
                counter  = 0;
                m_relays = 0;
                m_status[address] = inp_buff[0];
                address = 0;
            }
        }
        app->rza->adcReady();
    }

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

   while(m_bRun)
    {
        rcv_size = X502_Recv(m_dev, (uint32_t*)buffer, count, 2000);
        adc_size = rcv_size;
        err = X502_ProcessAdcData(m_dev, (uint32_t*)buffer, adc_data, (uint32_t*)&adc_size, X502_PROC_FLAGS_VOLT);
        app->rza->adcReady();
    }

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

Это может быть, если Вы не успеваете в своей программа вычитывать данные синхронного ввода. Т.е. из АЦП данные передаются быстрее чем Вы их реально вычитываете через Recv(), в результате Вы откачиваете более старые данные из начала очереди.

Если Вы принимаете за один Recv всего по одному кадру, а кадр на 4 КГц, то соответственно Вам и нужно вызывать Recv() так, чтобы в среднем он вызывался не меньше 4000 раз в секунду. У Вас же в цикле Recv идет последовательно с асинхронными операциями, которые в общем не быстрые и могут занимать время больше чем 250 мкс (управляющие запросы вполне могут выполнятся и за несколько мс), соответственно получается, что Recv() вызывается с меньшей скоростью.

Соответственно нужно либо вызывать асинхронный ввод-вывод не на каждый кадр, либо асинхронные функции вызывать из другого потока, либо использовать синхронный ввод/вывод для цифровых линий.

Вернулся к синхронному варианту: чисто синхронный ввод и прием данных с АЦП... что-то вообще начался бардак с АЦП-шными данными.Код примерно такой:

    qint32 rcv_size = X502_Recv(m_dev, (uint32_t*)buffer, count + 1, 2000);
    quint32 adc_size = count;
    quint32 inp_size = 1;
    qint32 err = X502_ProcessData(m_dev, (uint32_t*)buffer, rcv_size, X502_PROC_FLAGS_VOLT, adc_data, (uint32_t*)&adc_size, (uint32_t*)inp_buff, (uint32_t*)&inp_size);

т.е. я хочу принять только слово с цифровых входов.
При инициализации я задаю (дополнительно к параметрам АЦП):

    double fDIO = fAdcFrame;
    X502_SetDinFreq(m_dev, &fDIO);
    X502_StreamsEnable(m_dev, X502_STREAM_DIN);

если это это убрать и убрать добавление 1 к числу каналов АЦП (т.е. вернуться к  приему только данных с АЦП), то все работает нормально.

Что подразумеваете под словом "бардак"? ProcessData возвращает те резмеры, которые ожидаете? завершается без ошибок?

вот здесь два снимка экрана: https://cloud.mail.ru/public/GexC/rRb8ANWSN
В обоих случаях на вход АЦП подаю три напряжения и три тока. После приема данных и ДПФ в левой части прорисовываются амплитуды, а в правой - круговые диаграммы амплитуда-фаза. На первом рисунке (2016-10-18 09-27-42) просто сбор данных с АЦП, на втором (2016-10-18 09-29-51) - сбор данных с АЦП и синхронное чтение входного регистра.
В связи с тем что как-то не получается совместить чтение аналоговых и цифровых сигналов не может ли это быть связано с тем, что я использую упрощенную версию Е502 (без микроконтроллера и ЦАП)?

вынес асинхронный ввод/вывод цифровых данных в отдельный поток. Данные с АЦП принимаются нормально, но с цифровых входов ничего не читается. Прямо заколдованный круг какой-то. Если в АЦП-шном цикле заменяю чтение с АЦП на чтение цифровых данных - все ок..

В каком смысле не читается? Функция возвращает ошибку или читаются все время нули или что именно? Все же стоит описывать через поведение вызовов функций....
Как и насколько корректно получается финальный результат и что значит его отклонение все же из этого куска нельзя понять.

разобрался немного и поправил свои ошибки в варианте раздельных потоков: запускаю последовательно два потока:

1. В первом потоке - синхронное чтение данных с АЦП

    qint32 err = X502_StreamsEnable(m_dev, X502_STREAM_ADC);
    if(err < 0)
    {
        qDebug() << QString("error stream enable (%1)").arg(err);
        return;
    }
    err = X502_StreamsStart(m_dev);
    if(err < 0)
    {
        qDebug() << QString("error stream start (%1)").arg(err);
        return;
    }
    m_bRun = true;
    while(m_bRun)
    {
            qint32 rcv_size = X502_Recv(m_dev, (uint32_t*)buffer, count, 2000);
            if(rcv_size <= 0)
            {
                 qDebug() << QString("error received adc data (%1)").arg(rcv_size);
            }
           quint32 adc_size = rcv_size;
           qint32 err = X502_ProcessAdcData(m_dev, (uint32_t*)buffer, adc_data, (uint32_t*)&adc_size,  X502_PROC_FLAGS_VOLT);
           if(err < 0)
           {
              qDebug() << QString("error processing data (%1)").arg(err);
           }
     }
     app->rza->adcReady();
}

2. второй поток - асинхронное чтение/запись цифровых данных

    while(m_bRun)
    {
        out_buff[0] = address;
        if(m_relays != 0)
        {
            out_buff[0] |= m_relays;
            if(m_startRelay)
            {
                m_startRelay = false;
            }
        }
        out_buff[0] |= 0x4000;

        err = X502_AsyncOutDig(m_dev, out_buff[0], 0);
        if(err < 0)
        {
            qDebug() << QString("error write digital data (%1)").arg(err);
        }

        err = X502_AsyncInDig(m_dev, (uint32_t*)inp_buff);
        if(err < 0)
        {
            qDebug() << QString("error read digital data");
        }

        if(m_relays == 0)
        {
            m_inputs[address++] = inp_buff[0];
            if(address == 6) address = 0;
        }
        else
        {
                m_relays = 0;
                m_status[address] = inp_buff[0];
                address = 0;
            }
        }
    }

Сразу после старта поток 1 (чтение АЦП) выдает ошибку:  "error stream enable (-15)" (Истекло время ожидания освобождения мьютекса). Если я запускаю или 1=й поток или 2-й,  то по отдельности все работает.

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

Пока оставим это и если можно попытаемся разобраться почему поток с синхронным вводом с АЦП не хочет совмещаться с потоком асинхронного ввода с цифровых входов.

Да, так понятнее.
Хотя одного я пока не понимаю - когда запускается второй поток относительно первого и делает ли он что-то до этого кода и точно m_bRun изначально в false?

Просто у Вас ошибку возвращает функция X502_StreamsEnable(), но если я правильно понимаю, на этот момент m_bRun должен быть false и действия из второго потока не выполняться (хотя не очень понятно из куска, что делает второй поток, если m_bRun == false?).

Так что просьба проверить, что действия из второго потока начинают выполняться после X502_StreamsStart(m_dev) в первом (я бы прям после этого вызова из первого потока бы из запустил второй)

вот спасибо! Этот вариант заработал. Сразу после

err = X502_StreamsEnable(m_dev, X502_STREAM_ADC);
    if(err < 0)
    {
        qDebug() << QString("error stream enable (%1)").arg(err);
        return;
    }

    err = X502_StreamsStart(m_dev);
    if(err < 0)
    {
        qDebug() << QString("error stream start (%1)").arg(err);
        return;
    }

я вставил

   app->dio_thread->start();
    emit startDio();

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

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

Ок. Отлично)
Ну с синхронным вводом я бы для начала вывел бы возвращаемые значения Recv, ProcessData и adc_size и inp_size (после ProcessData()) для нескольких первых блоков, чтобы проверить, что все нормально выполняется

сейчас приведу все в порядок (это замет немного времени) и сделаю...

сделал упрощенный вариант: только чтение 11 аналоговых каналов и 1 цифровой. Получил следующее

12 7 1
12 4 1
12 0 1
...
12 0 1

здесь первая цифра - то что возвращает Recv, вторая - adc_size и последняя - inp_size...
Куда делись данные с АЦП?

покрутил частоту X502_SetDinFreq.. чем меньше частота, тем ситуация меняется в сторону данных с АЦП. При 500 Гц получаю

12 11 1
12 11 0
12 11 0
12 11 1
ну так далее.. Но данные (якобы) с АЦП все равно неправильные идут, как случайные.
Если убрать разрешение синхронного ввода, то аналоговые данные в порядке.

Хм.... исчезнуть они по идее могут только если соотношение цифровых линий к количеству отсчетов АЦП не соответствует 1 к 11. Соответственно если цифровых линий больше 1, то их не сможет ProcessData положить в буфер...

Можете тогда для проверки сделать adc_size и din_size на входе равными 12 (и массивы тоже на соответствующий размер) и также указать, что вернули функции X502_SetAdcFreq в качестве f_frame и X502_SetDinFreq в качестве f_din. и вывести новые цифры количеств

В первом случае точно одинаковая частота f_frame и f_din?

нет конечно.. а что нужно точное соответствие?