някой случвало ли му се е при работа с ft232r или някой друг от фамилията, да получи син екран със следния код за грешка DRIVER_IRQL_NOT_LESS_OR_EQUAL със обяснение по-долу че грешката е във ftdibus.sys? чудя се, моя компот ли нещо не е наред, защото на работата същич чип със същия драйвер не е правил проблеми. грешката възниква когато се вика апито FT_Write и то върне 0 предадени байта (кода за грешка е 0, което е странно - няма грешка, но данните не са изпратени). ако след такава ситуация просто опиташ да пратиш данните отново, с определена вероятност системата забива. скоростта на предаване силно влияе на вероятността за забивка, като високата скорост е по-рискова. при забивката опашките за предаване и приемане са празни, проверено е. ситуацията не се наблюдава при спорадично предаване един байт нагоре надолу, а се случва когато се започне бърз двупосочен обмен с изчакване(пакет "дай данни", пакет "на данни").

Ами аз лично от доста време ползвам FTDI (BM а сега и R), това точно не ми е излизало.

Друг проблем изкочи при мен обаче. Mprog 3.0 не ще да програмира FT232BM. С FT232RL си работи ОК. Върнах някаква по стара версия на Mprog - програмира си BM-а. Ама не подържа RL. Та сега съм с двете версии. И аз не знам дали проблема не е в компота.

@zaphod, тоя проблем го имам и аз при FT232BM, не мога да хвана каква е точно причината за проблема, получава се след продължителна работа на устройството - около 2-3 часа почти постоянен трансфер на 1Mbps...в един момент виждам как светодиода за TX на чипа продължава да мига, обаче чипа закачен след FTDI-то нищо не приема...и по-големия проблем в случая е, ако решиш да извадиш USB куплунга след като спре приемането - или ти излиза тоя син екран с "DRIVER_IRQL_NOT_LESS_OR_EQUAL....ftdibus.sys" или направо компа се рестартира както при натискане на RESET-а на дъното. Ако опитам да затворя приложението, което ползва FTDI handle-а, не мога, просто програмата си стои Not Responding, a в Task Manager-a при процеси изчезва, а процеса, асоцииран с това забило приложение се показва като Explorer.exe. Проблема е адски изнервящ и още не съм измислил решение, но ще работя тези дни по заобикалянето му, мисля си нещо от сорта на "flush-close-open" периодично (през няколко минути), нямам точно в момента време да го пробвам, пробвай го ако искаш

Zaphod,
точно такова чудо не ми е излизало...

No на 245BM имах проблеми с трансфер на данни докато не намаля таймаута(по подразбиране е 16)за трансфер между пакетите. Значи боза има докато не се напасне времето за разпитване за статуса на чипа и таймаута.
последно за да не взимам 99%от ЦПУ-то на компа през 5милисек питам за статуса и таймаута ми е на 5милисек, на пакети от 4096байта. за съжаление това време даже и от фтди казват, че дизайнера сам трябва да го определи според дизайна си.
А разпитването за статуса повярвай ми трябва да се през определено време, защото иначе приожението яде до 100%от перформанца на ЦПУ-то и не може да се обработват други процеси.
е и отварям дивайса по description не го енумерирам(така ми е по-лесно не за друго).
и програмата ми е на борланд CBUILDER не майкрософт визуал Ц.мисля си, че има ралика....

Като гледам проблема щом ти излиза при "бърз двупосочен трансфер на данни" трябва да се насочиш към големина на пакет/таймаут за трансфер/време за разпитване за статус

това с ресетването ставаше и при мене, обаче изрових някакво меню във виндовса, което има чекбокс дали да се ресетва компа при фатална грешка, или да вади син екран. след като го сложих на син екран, тогава видях какво съобщение дава. учудва ме че при тебе и двете стават, да не би да говориш за различни компютри?

Бъгав USB драйвер е най-лесния начин за дистанционен рестарт на компа .

На един и същи компютър, с един и същи Windows XP, тая опция за син екран при мен е включена, един път ми вади син екран с тая грешка, друг път направо като хардуерен ресет на дъното.

МУХА, с това време за таймаут на статуса и пакетите съм си играл, не виждам абсолютно никаква разлика в трансфера, скоростта е същата, ресурсите, които се използват са същите. Незнам как ги докарваш тия 100% CPU, в мои програми при пълен трансфер на 232BM (и в UART режим и в Bit-Bang) виждам най-много 1-2% при абсолютно постоянен двупосочен трансфер имам функция ping в устройството си и виждам разликите и отклоненията в проценти и съм по-склонен да мисля, че имаш грешка в програмирането, отколкото бъг във FTDI. Първото, което ми идва на ум е, че вероятно проверяваш прекалено често какво има в RX_Queue на драйвера, там задължително се слага някакъв delay поне 4-5ms (между проверките)...второто е, че правиш проверките в главния thread на програмите си, което води до забиване на визуалния й интерфейс и естествено по-голям CPU usage

ooo
за мойто програмиране спор няма-> бъговете лазят някъде между бъговете се появява взаимосвързаност и програмата заработва
но не съм казал че в чипа има бъг
а драйвера не ми прави проблеми също!

ХВАНАХ ГО!!!!
когато се усетя че драйвера се кани да ме преебе, извиквам функцията ResetDevice и всичко спи


оказва се че тая функция само снижава вероятността за появяване на проблема, но след достатъчно опити пак заби.

e, последните новини са добри - сложих на ХРто драйвер за 98 и заспа ))))
всъщност, пак се появява тоя спонтанен отказ от предаване, но както казах FT_ResetDevice го лекува много лесно, но забивания няма

А как го усещаш кога се кани ?

Zaphod,
не мога да не изразя учудване и лек конфуз от това дето го написа....
искаш да кажеш, че с последните драйвери от фтди за ХР имаш проблем, а с драйвера на вин98 работиш.....
и за трансфери от мегабит с междинно ресетване на устройството
все си мисля, че има боза и тя не е в ХР .....

между впрочем.....на сайта на фирмата пише че за някои нови дъна или УСБ хъбове при вин ХР има проблеми с опознаване на дивайса, и препоръчват между куплунга и ресисторите 27ома да се сложат кондензатори 47пико към маса:!: аз ги турнах и проблеми нямам вече. иначе преди нема нема и "unrecognized USB device".....

А случайно дъното на компа ти да е с нвидия чипсет ?

Ако е така проблема се решава с PCI - USB платка....

Така и не го оправиха този драйвер.

абе Тишо ти направо се изходи по въпроса!

Що бре ? Над 60 устройства с FT245BM имаме работещи. Този проблем с рестарта го прави основно когато чипсета на компа е нвидия (поне на други нямам наблюдения да е правило такива номера). USB-то си го намира инсталира си драйверите, устройството го има в дивайс менъжера , но се рестартира (или посинява) като тръгне да праща данни към чипа...

С програмата на компа нямам нищо общо, писа я един програмист, това са ми наблюденията от работата и...

Проблема го решавахме по мързеливия начин с платка PCI - USB. и преставаше да се рестартира.

дъното на което се проявява не е ново, от преди 6 години е. освен това говорим за съвсем друг казус, а не за откриване на устройството, което ти намесваш.
а че бозата не е в ХР не е, в драйвера на фтди е. че проблема е в драйвера, това е по презумпция, няма какво да се мисли. каквито и глипости да прави програмиста, драйвера НЕ ТРЯБВА да забива. иначе за какво са ни драйвери? просто ще ни дават един пдф със описания кой и/о регистър за какво служи, както беше преди 20 години, и шапка на тояга. драйвера това му е функцията, да служи за буфер между некадърния програмист и желязото. драйвера трябва да свежда евентуалните глупости които програмиста прави до простичко съобщение за грешка, а не да ресетва системата. всъщност, и микрософт донякъде носят отговорност, защото драйвера за ХР е сертифициран. това още повече подсилва убеждението ми че сертификатите са нещо абсолютно ненужно, и който ламти за сертификати е първо глупак и второ брократопоклонник.
между другото, устройството още не е забило компота със 98 драйверите.