С одной стороны - это так, а с другой стороны, применил флаг THREAD_PRIORITY_TIME_CRITICAL и все! Ни тебе перерабатывать аппаратную часть надо, ни вводить дополнительный буфер. Дешево и сердито :-)

AL, "6500 тактов камеры" - это значит чуть более 10 строк (т.е. почти 500 мкс)...
Спасибо, учту замечания по поводу прерываний (хотя я не вкуриваю, почему нельзя в прерывании заполнить к примеру буфер точки 1 in)...

А ПЛИС - ну и что если ее постаить - синхронизация то все равно должна быть!!!! Комп как-то должен узнать о начале кадра.

Вы никогда не задумывались над тем, что в системе могут быть другие устройства, не менее требовательные к ресурсам, и что тогда????


Насчет обработчика прерываний... не забывайте, во время выполнения прерывания Вы монопилизируете ресурсы контроллера, тем самым рискуете потерять другие прерывания.
На ПЛИС достаточно просто вставить в поток от камеры маркерное слово, которое и будет означать начало кадра/строки

Аха, понял про прерывания, это учитываю.

Что касается ПЛИС - это будет следующий шаг, т.к. их только еще осваивать буду

Почему цепляюсь просто за камеру+сайпрас, хм... видел готовый продукт ... Очень привлекательно то что это всего лишь дешевая цифровая камера и махонький контроллер, очень получается все дешево и хорошо...

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

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

И кстати, попробовал сделать точку размером 640 байт (как строка) - чото нифига не хочет комп с ней работать, а когда через консоль смотрю - последние (640-512) байт забиваются какойто лажей...

А тогда - в точности то, о чем я и написал: "Правда, зависит от всего остального. Если на компьютере выполняются другие важные задачи, то пакеты могут пропадать..." :-) Т.е. зависит от задачи. От этой печки и следует плясать. Очень может быть, что других высокоприоритетных задач в это время выполняться не будет.
А он и не может работать с ендпойнтой размером 640 байт, IMHO. Из этого диапазона только 512 или 1024.

Кстати. А ведь можно передавать одну порцию (начальную часть строки) размером 512 байт, а остаток - сколько получится (используя PKTEND). Тогда можно и маркерный байт без труда добавить (да хоть даже слово: например номер строки в диапазоне 0...639), т.к. места - 2 х 512 байт - предостаточно. А программист всегда сможет определить начало строки по полученной величине пакета ровно 512 байт. Или добавить номер строки в конец (т.е. во второй, укороченный пакет). Тогда на передающей стороне проще получится, а на компьютерной стороне - вообще пофиг. Стоит подумать, IMHO. Тогда задача решается вообще элементарно. И не нужно никаких ПЛИСов и прочей усложненности городить.

А как контроллер будет определять что PCKTEND получен, успеет он?
И кстати тоды по пктенду записать один байт в точку а остальные 640 допишутся...

Короче, вот такой будет вопрос...

Кадр = 640*480, енто мы принимаем по булочной In точке в виде 5-и буферов по 120*512 байт (т.е. = 640*480 = 512*600). Это все в одном потоке с высоким приоритетом. Как приняли эти 640*480 байт, передаем их в ф-ю вывода на экран.
в параллельном потоке принимаем по второй булочной In точке 3 байта, которые сайпрас передает каждый кадр (1/30 сек)

Иногда во время приема почему-то (дело вроде не в железе) пропадают пара-тройка пакетов по 512 байт. Но вот тут-то


ждет себе заполнения буфера до размера 640*480! А берет он их ясен пень из следующего кадра и, получаем сбой синхронизации.
Т.е. после запуска программы пару секунд фсе нормуль, а потом сбой, еще через 1-2 сек опять и т.д. иногда даже раз в 0.5 сек (примерно)

Чтобы синхронизироваться надо бы при приеме кадровой синхронизации (иными словами по приему от второй In точки) делать как-то так чтобы буфер поновой заполнялся!!


КАК??

Во блин дела... Тока заметили - пакеты 512 байт мы теряем не в железе. Я это по флагу переполнения смотрю (он не устанавливается)!
Пакеты теряем в компе. Щас выбросили с проги все лишнее - стал терять 1-2 пакета в начале (или конце фиг пойму) кадра. Уже стало лучше.

Причем теряет не целиком пакет 512 байт! А лишь кусочек :0

Подскажите, где тут может быть собака зарыта?

Посчитать надо. Во всяком случае, микроконтроллер - штука достаточно быстрая, импульс длительностью порядка десятка/двух микросекунд должен увидеть лёгко.

Конечно. Все дело в негарантированности доставки булочных пакетов. IMHO, тут единственная надежда - запуливать в очередь прием только двух пакетов и не больше (т.е. одной полной TV строки: 512+128 байт). А число очередей взять по-больше (8-16 штук). Но все равно, я не очень представляю, как без маркерного байта полностью избавиться от сбоев синхронизации...

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

Кстати, тут может выручить тот факт, что временной промежуток для кадрового синхроимпульса заметно дольше (несколько строк). За счет этого можно как-то поиграться с синхронизацией... Думаю, стоит обдумать этот момент. Можно, к примеру, очень точно измерять время прихода строк и когда очередная строка придет сильно позже обычных - это и будет сигналом начала кадра. Тогда даже кадровая синхронизация через другую булку будет не нужна! :-)

Чатота тактов с камеры почти 10 Мгц - о счете речи быть не может

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

Если ща у меня 5 раз принимается 120*512, то принимать скажем так 480 раз 512+128 не рулит, не принимает комп

хм... я глядел - наложения кадровой синхронизации (данных по второй токе) на строчные данные НЕТ. Просто когда мы ловим этот кадр - не понятно (да и можно ли), как начать прием совсем сначал. Разве что сделать Abort() и далее BeginXferData? корректро ли это....



Вот так, думается мне что проблема в правильности, грамотности написания кода на СИ. Делали переписывание полученных данных тупо циклом for, указатель=указатель. Были сбои в конце каждого из 5-и пакетов, когда заменили на memcpy - эти сбои почти ушли. Теперь стабильно теряется около 128 байт в последнем из пяти пакетов...

Это не важно. Важно то, что кадровая синхронизация происходит достаточно медленно. Скажи, какая длительность кадрового синхроимпульса? Может быть его все-таки можно зафиксировать?

И еще. Почему нельзя синхронизироваться по периоду следования строк? В твоей системе нет временного промежутка для кадрового синхроимпульса? (Ведь в случае временной синхронизации отпадают проблемы с кадровым синхроимпульсом!)

Ты не понял, в булке гарантируется доставка пакетов, но не время их доставки! Тут запросто может возникнуть рассинхронизация... (Насколько я понял, именно рассинхронизация и имеет место быть.) А почему пропадают пакеты - Бог весть... Может программисты чего-то не того замутили?...

Странно... Вот этого момента я не пойму...

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

Тоже верно... Тут запросто могут быть подводные камни... Думаю, следовало бы промерить точный тайминг. Пошагово. Это часто помогает.

(Прошу прощения, что мои советы выглядят как-то нелепо. Просто дистанционно понять проблему достаточно трудно :-)

Интересно получается, пакеты пропадают. Для начала необходимо разобраться именно с этим, а потом уже с синхрой. Я генерил плисой поток, счетчик 16бит, и гнал на комп булочной передачей. А на компе проверял этот счетчик. Так вот, при скорости порядка 37МБ/с за 5 минут тестирования счетчик ни разу не сбился т.е. небыло ни одного потерянного пакета. Булочная - пакет гарантировано будет доставлен драйверу. Если драйвер попросит у железки 600 пакетов по 512 байт, и выделит достаточно места, то железо передаст именно 600 пакетов, а не больше и не меньше. Дальше уже дело аппликухи достать эти данные и обработать. Вполне вероятно вы просто не успеваете это делать, или делаете некорректно, особенно если учесть что используется больше одной очереди. Насчет синхронизации, использовать вторую булочную - не есть правильно. Частота 1/30 - 33мс период. Windows не ОСРВ, ее квант как раз и примерно 30 мс, и никто не гарантирут, что эту саму синхру вы будете получать каждые 33мс. Поэтому так поступать просто нельзя. Очень хороший вариант был уже озвучен - это маркер-пакет, пакет с известным "уникальным" содержимым или уникальной длины (pkend тоже хорошая штука). Если хотите получать "чистую" картинку, то между камерой и мк, просто необходимо ставить плису, она займется и синхронизацией, и забивкой фифо и всеми остальными делами.

Потерю пакетов устранили! Картинка получилась, за несколько минут сбоев не происходит...

Теперь думаю над кадровой синхронизацией, ведь если все же за длительное время работы произойдет сбой, к примеру железа, происходит однократный сбой синхронизации и картинка становится разбитой на 4 части. Это я проверял искуственно создавая сбой... Этот случай надо предусмотреть.
Но, если я буду посылать компу, к приму в начале кадра "уникальный" пакет на 512 байт, то что с ним будут делать на компе-то? Чо весь буфер сканить на соответсвие, это же долго?

Т.е. из драйвера прямиком на вывод, полагая, что первый байт буфера есть первая (верхняя левая) точка. Если сбоев нету, то все нормально, буфер размером 640*480=307200 байт содержит один кадр. Но если произойдет сбой, то как пример, первая точка может начаться где угодно, быть хоть первым байтом последней пачки(512 байт). Поэтому, для восстановления синхры, надо эту точку найти, можно, например, увеличить буфер на 512 байт (307712) и в первой пачке передавать какую-нить комбинацию, например первый, семнадцатый, 137 и 471 байты сделать известными. Тогда после приема 512+600*512 байт, надо глянуть в первые 512, найти все 4 байта, сделать вывод о наличии синхры. На это потребуется с десяток команд ПК. Если синхра потеряна, то просмотреть ВСЕ пачки по 512 байт и найти нужную. На это потребуется в худшем случае порядка 3000 тактов что на 600Мц ПК составит всего 5мкс, при периоде в 33мс.

Хы... тоже верно, спасибо.

Но я всетаки сделал как и говорил - прием данных 640*480, после чего вывод их на экран, а затем ожидание приема от второй булочной точки. Далее цикл повторяется.

Получаем стабильную картинку, а в случае сбоя синхронизация востанавливается за 1 кадр!
Глюков пока не выявлено.
На Пне 3 ГГц, работа с полученным девайсом жрет менее 4% ресурса.

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