codavr1

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

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

Это какой длины была последовательность? при 130Мб/с получается что около 1.7Мб? И нашёлся такой мост, который эту последовательность не прервал сигналом STOP? После сигнала STOP предполагается, что арбитр посмотрит на желания других мастеров на шине, и передаст управление прерванному мастеру, если больше претендентов нет. А тот уже должен продолжать свою последовательность до следующего сигнала STOP. И так, пока последовательность не закончится.

Я и не говорю, что обходил. Думаю пока, как это сделать полегальнее, но ничего кроме своего шлюза в GDT не придумывается... Ну это так... полумера, хотя попробовать тоже придётся.. Надеюсь, что это сократит время ожидания готовности. Интересно, насколько быстр механизм этих эвентов?... Может и до этого дойти.. посмотрим. Единицы раз. Равняется количеству запусков апликухи. А больше и не надо.

Ну я тоже имел в виду, что при повышении частоты передачи сначала начнут искажаться данные, и уже потом, когда их будет уже совсем не узнать на приёмном конце, начнёт изменяться количество передаваемых байт (пропадать байты). Я правльно понимаю? Ну значит я почти не наврал, опираясь только на личный опыт. При выходном сопротивлении порта 5кОм и напряжении 12В на нагрузке 3кОм останется как раз 12/8*3 = 4.5В. Чуть меньше положенного.

Ну да... Только реальную скорость забыл померять... Если бы только жил... Выходное сопротивление компорта не лимитировано и варьируется где-то от 1го и до 5ти килоом. т.е. даже не биты? круто!

Да вроде бы можно и на дефолтных... Двух ендпайпов IN и OUT для почти любой задачи достаточно. Должны меняться. А откуда известно, что он заполняется? Научный тык в данном случае больше времени потребует, нежели перевод и изучение описания.

Пытаюсь пока обходиться одним абортом - дабы прибить читающий поток при выходе из приложения. Не такую уж и кучу, но есть немного. процентов 5 от суммарного времени кручения в диспетчере ВВ, шинном драйвере и драйвере хоста. Читающий поток висит непрерывно. Ожидание входного пакета в другом потоке - прерывается по таймауту в случае чего. Единственный момент, когда нужно прервать висящий читающий поток - это выход из приложения. Для чего использую аборт. Синих экранов пока не видел. С этим бился с неделю... Пока понял, что и правда нельзя. Виснет отправляющий вызов так, что аборт не помогает. Причём виснет где-то в шинном драйвере. Пришлось забирать данные в устройстве, даже если у него их не забирают. Данные, естественно, при этом теряются, но если приложение умное - оно такого не допустит. Т.е. не будет писать в устройство, не запустив читающий поток. И ещё про латентность. Она, как и ожидалось, сильно зависит от производительности компа. 0.9мс было на 4м пне 2800МГц. А на ноутбучном целероне-633 оказалась аж 4мс. Причём около 3.5мс висим в шинном драйвере Т.е. обхождение IO-манагера выигрыша в скорости не даст :(

Возможно.. Вы говорили, что надо запускать чтение раньше записи и делать это в отдельном потоке. Так я и сделал. И по логу видно, что я сделал именно так. Прошу прощения. Поставил sleep(0) в цикл ожидания готовности приёма и всё стало гораздо лучше. Среднее время отклика = 0.9 мс. Спасибо. Я наверно, и с CYUSB-драйвером погорячился, когда его обругал... надо будет ещё раз попробовать когда-нибудь...

Проверил ваше утверждение. Результат отрицательный. Время от 20 до 60мс. Вот лог: 0.00001145 IRP_MJ_DEVICE_CONTROL 0.00002458 enter Ezusb_Read_Write() 0.00003716 enter Ezusb_CallUSBD 0.00004973 Calling USB Driver Stack 0.00013410 return from IoCallDriver USBD 103 0.00014499 Wait for single object 0.00033300 Wait for single object, returned 0 0.00034557 URB status = 0 status = 0 irp status 0 0.00035703 exit Ezusb_CallUSBD (0) 0.00036876 Successfully transfered 0xa bytes 0.02320407 Wait for single object, returned 0 0.02321692 URB status = 0 status = 0 irp status 0 0.02322837 exit Ezusb_CallUSBD (0) 0.02324066 Successfully transfered 0xa bytes 0.02806977 IRP_MJ_DEVICE_CONTROL 0.02808374 enter Ezusb_Read_Write() 0.02809603 enter Ezusb_CallUSBD 0.02810888 Calling USB Driver Stack 0.02820191 return from IoCallDriver USBD 103 0.02821308 Wait for single object

попробовал EZUSB. сразу получилось около 1.9 мс, но иногда (достаточно редко) бывает и до 4мс. Т.е. по латентности этот драйвер шустрее CYUSB в десятки раз.. Этот результат получен при включенном отладочном протоколировании. Вот протокол драйвера: 0.00001090 IRP_MJ_DEVICE_CONTROL 0.00002403 enter Ezusb_Read_Write() 0.00003632 enter Ezusb_CallUSBD 0.00004889 Calling USB Driver Stack тут ок. 70 мкс передаём запрос на запись шинному драйверу 0.00012599 return from IoCallDriver USBD 103 0.00013689 Wait for single object тут 140 мкс ждём, когда шинный драйвер обработает запрос 0.00027797 Wait for single object, returned 0 0.00029026 URB status = 0 status = 0 irp status 0 0.00030143 exit Ezusb_CallUSBD (0) 0.00031373 Successfully transfered 0xa bytes тут где-то 650мкс мы пребывали в диспетчере ВВ (в приложении между двумя DeviceIOControlами находятся с десяток ассемблерных команд (PUSH в основном)) И это при прямом методе (METHOD_IN_DIRECT, METHOD_OUT_DIRECT) общения с драйвером. 0.00095990 IRP_MJ_DEVICE_CONTROL 0.00097191 enter Ezusb_Read_Write() 0.00098281 enter Ezusb_CallUSBD 0.00099482 Calling USB Driver Stack ок. 90 мкс передаём запрос на чтение шинному драйверу 0.00108338 return from IoCallDriver USBD 103 0.00109427 Wait for single object 180 мкс ждём, когда шинный драйвер обработает запрос 0.00127390 Wait for single object, returned 0 0.00128620 URB status = 0 status = 0 irp status 0 0.00129709 exit Ezusb_CallUSBD (0) 0.00130855 Successfully transfered 0xa bytes и где-то 170 мкс находимся в драйвере EZUSB (в основном выдаём отладочные сообщения) Плюс в лог не вошло время входа в первую функцию и выхода из второй - ещё 650 мкс в дисп. ВВ. Итого получается 1.95 мс, как и измерилось приложением. По итогам данного измерения можно резюмировать, что основную задержку даёт микрософтовский диспетчер ввода-вывода... Осталось его как-то обойти и латентность уменьшится ещё в несколько раз. до полмиллисекунды.

Да не так уж и редко.. Но вот мне попалась на чипе VT6212 от VIA. так на ней питание заведено 3.3В с матери. А такое питание есть только на новых матерях, на которых USB2.0 и так уже имеется. А воткнуть хотелось в старую, чтоб побыстрее USB работал. Ну, пришлось припаять микросхемину-преобразователь из 5ти в 3.3В. Заработало... Мать: AT-формфактор слот-1, проц: целерон-633 в переходнике :). И ещё одна конфигурация: промышленная мать с P3-1200 в промышленной же кросс-плате. Не знаю почему, но USB там вообще не было, наверно не влезла - плата полноразмерная (ставится в слот кроссплаты) и забита под завязку. Пришлось ставить PCIный USB. С питанием решилось точно так же.

Версия драйвера CYUSB 1.07.0000.0, но пробовал и с более старыми - результат такой же. Команда IOCTL_ADAPT_SEND_NON_EP0_TRANSFER директовую команду не пробовал, но кажется, результат не изменится... Попробую EZUSB...

Непонятно, что мешает драйверу при свободной шине отправить запрос на чтение сразу при получении этого запроса от приложения? Зачем ждать 40мс?