USB->Isochronous или Bulk, что выбрать посоветуйте... Опции

[alexkarnaukhov]

Здравствуйте,

Стоит задача непрерывного чтения данных с 16-бит ацп с частотой не менее 64 кгц. Передача организована через микроконтроллер с usb full-speed(AT89C5131). Получается необходимая средняя пропускная способность - минимум 128 кбайт/с. То есть передача через Interrupt уже не годится.

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

Собственно вопрос в том что будет работать надежнее: Bulk или Isochronous и имеет ли смысл заморачиваться с Isochronous?
В данный момент имею Bulk точку по которой стабильно гонится около 1 МБайта/с, причем во фрейм укладывается примерно по 16-17 пакетов, и тормоза ПО и операционки на это не влияют, только втыкая флешку в другой юсб-порт появляются фреймы с меньшим количеством пакетов, и даже вобще без них(совсем редко), но, вообще, это уже не штатный режим, поскольку расчет делается на то, что во время чтения комп дергать никто не будет.

PS. Еще вот думаю а нельзя ли сделать 2-3 конечные точки типа Interrupt и распределить поток данных между ними? Либо тоже радикальный вариант - сделать буфер из имеющихся на кристалле 1024 байт ERAMa, что на 8 кадров позволит буферизировать данные.

[galjoen]

В данный момент имею Bulk точку по которой стабильно гонится около 1 МБайта/с, причем во фрейм укладывается примерно по 16-17 пакетов,

В 1 мс кадре на full-speed строго 16 64-х байтных пакетов (не считая 0-ю EP, где ещё 1 пакет)

PS. Еще вот думаю а нельзя ли сделать 2-3 конечные точки типа Interrupt и распределить поток данных между ними?

Можно без проблем - нужно сделать составное устройство из 2-х HID-ов. Можно и из 16-ти, если железо позволит.

[Oldring]

Стоит задача непрерывного чтения данных с 16-бит ацп с частотой не менее 64 кгц. Передача организована через микроконтроллер с usb full-speed(AT89C5131). Получается необходимая средняя пропускная способность - минимум 128 кбайт/с. То есть передача через Interrupt уже не годится.

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

Собственно вопрос в том что будет работать надежнее: Bulk или Isochronous и имеет ли смысл заморачиваться с Isochronous?
В данный момент имею Bulk точку по которой стабильно гонится около 1 МБайта/с, причем во фрейм укладывается примерно по 16-17 пакетов, и тормоза ПО и операционки на это не влияют, только втыкая флешку в другой юсб-порт появляются фреймы с меньшим количеством пакетов, и даже вобще без них(совсем редко), но, вообще, это уже не штатный режим, поскольку расчет делается на то, что во время чтения комп дергать никто не будет.

PS. Еще вот думаю а нельзя ли сделать 2-3 конечные точки типа Interrupt и распределить поток данных между ними? Либо тоже радикальный вариант - сделать буфер из имеющихся на кристалле 1024 байт ERAMa, что на 8 кадров позволит буферизировать данные.

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

Да, есть одна тонкость. За фрейм можно передавать только один изохронный пакет, так что если ваш микроконтроллер не поддерживает 256-байтные буфера - лучше поменяйте микроконтроллер.

[galjoen]

Для такого реалтайма правильно делать изохрон.

А почему не интеррупт? Компромисс между изохроном и бульком. Тоже, что и изохрон, но с трёхкратной попыткой перепередачи в случае повреждения пакета. ИМХО для данного случая очень хорошо подходит. Но тоже от железа кое что требуется, только не размер буфера, а кол-во EP.