Здравстуйте, сотрудники l-card.
При сборе данных при по кадровой синхронизации у меня возникают пропуски данных.
период синхроимпульсов 16 мкс
частота АЦП 2600 кГц
должно вполне хватить на 32 канала?
t= 1/2600 = 0,38 мкс
T = 0,38*32 = 12,4+500нс = 13 мкс
Т время зстраченное АЦП на опрос все 32 каналов от одного синхроимпульса.
fifo = 3072
irq step = 3072
page = 500
НО!!! вот здесь у меня возникает вопрос!!
n =3072/32 = 96
Tim = 96*16 мкс = 1,5 мс время за которое моя половинка буфера заполнится...
И так как она заполнилась произойдет изменение
значение параметра sync и я должен буду забрать
эту половинку в большой кольцевой буфер.
а значит все время программа тратит на отслеживание быстоменяющегося sync и подостижение
halfBuffer = adcPar.t1.Pages*adcPar.t1.IrqStep/2;
я могу забирать данные и с половинки большого кольцевого буфера...
А муществует возможность, что бы драйвер сам следил за наполняемостью большого кольцевого буфера и выдавал событие по заполнени???
тогда бы программа не тратила огромное кол-во ресурсов..
Есть такие функции в драйвере?

Такого события нет. Событие ходит медленно и при загрузке системы будет еще медленнее. Опрос счетчика самое быстрое. А если опрос невозможен с sleep в цикле опроса, то шанс на потерю данных очень высок...

Спасибо большое, за оперативный ответ.

То есть я правильно понимаю, что увеличением
page, скажем до 1000,  я не решу проблему пропуска данных, потому что все равно придется сидеть на опросе sync, и он будет грузить систему
и примение Sleep лишь ухудшит ситуацию?
Sync нужен же для двух случаев?
когда он еще меньше halfBuffer
и когда он уже больше его???
Я правильно понимаю?

типа да. sync на таких скоростях жедательно отслеживать по halfbuffer. 783 на высоких частотах сама по себе сильно грузит комп тк программная вычитка данных не сильно больше сорости заполнения буфера в плате... встречались мат.платы где 783 на всю скорость работать не могла. такой медленный там программный PCI был...

да уж....
Спасибо за ответ.