CY7C68013A постоянная булочная передача, прога для компа Опции

[torik]

Снова привет!

Ковыряюсь с этой платой CY3681, драйвер CyUSB....

Состряпал девайс - точка 1 IN интераптовая а также точки 2 OUT и 6 IN по 512 байт.
Пока зациклена точка 2 на точку 6, т.е. чо передаем с компа то обратно отсылаем...
Все это проверяется с помощью CyConsole... и вот какая проблема: в этой программе нельзя непрерывно принимать данные и записывать их в файл.

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

[torik]

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

[jur]

А как контроллер будет определять что PCKTEND получен, успеет он?

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

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

Код

if (dlg->InEndPt->FinishDataXfer(buffers[i], rLen, &inOvLap[i], contexts[i], isoPktInfos[i])) {
.......

ждет себе заполнения буфера до размера 640*480! А берет он их ясен пень из следующего кадра и, получаем сбой синхронизации.

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

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

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

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

[torik]

А как контроллер будет определять что PCKTEND получен, успеет он?

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

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

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

Код

if (dlg->InEndPt->FinishDataXfer(buffers[i], rLen, &inOvLap[i], contexts[i], isoPktInfos[i])) {
.......

ждет себе заполнения буфера до размера 640*480! А берет он их ясен пень из следующего кадра и, получаем сбой синхронизации.

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

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

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

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

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

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

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



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