Здравейте, става дума за комуникация между линукски компютър и ПИК18Ф45К50.

Случва се понякога, например след седмица работа, компютърът да спре да приема данни от ПИК-а. Изпращането си върви. Затваряне и отваряне наново на КОМ-порта не помага.

От страна на ПИК-а всичко изглежда да си е наред - състоянието на УСБ е attached (0x20 в библиотеката на Майкрочип), приема си и си изпраща успешно данни.

Някой дали има идея какъв е проблемът?

Как хем пик-а изпраща и приема успешно, а в същото време компа не приема? Отделно аз лично не бих разчитал че усб комуникация ще работи перфектно със седмици и месеци, дори всичко да е перфектно

Ако знаех как става това, нямаше да пускам тема. Не съм знаел иначе, че USB е толкова ненадеждно.

Едно разклащане на усб съединителя след много включвания и изключвания и комуникацията е заминала...

Не може ли ПИКът да ресетне усб-то си, ако няма валиден трафик 5 минути?

Да, може, това е добра идея! Дано помогне нещо подобно.

По принцип като забие драйвера, трябва да се изключи PIC-а и да се енумерира наново. Направи му някакъв фийдбек от компа че е приел успешно данните. Като спре фийдбека, накарай контролера да си изключи за момент USBто. Би трябвало да стане.

Ползвам ПИКове, но не и такива с УСБ. Когато требва FT230XQ, свършва работата...

Това, което може да ти причини проблеми, са части от програмата, които не са изградени като стейт машина т. е. като влезе там му отнема много време за обработка! Това чупи USB-то, но реално получаваш някакви данни от буфера, понеже ги пълни в прекъсване. Освен това ги и изпращаш, но реално понеже вече се е строшила връзката, компа не ги получава(приложението, което си пуснал, не ги получава!). Ситуацията с attach-deattach също беше много тънка, но нещо в момента не помня...
Поздрави!

Девайса може да се откаче като си изключи пулъпа и после да се закачи отново. Това обаче не е добра идея, освен ако софтуерът не е достатъчно добър. А поне на бозата повечето не е. След разкачане на девайс, приложенията трябва да си затворят всички хендъли иначе СОМ порта и драйвера му си стоят и при последващо закачане на устройството не се монтират.

Да се губи само едната посока досега не съм виждал никога нито под боза, нито под лайнукс. Най-вероятно пик-а си е омазал я прекъсване, я фифо, я нещо друго та затова се губи само един ендпоинт. По стандарт може да се stall-ва и да се забранява отделен ендпоинт, обаче това не ползва при хендшейк. Вместо това обикновено ако контролера не е готов да предава или получава просто си остава празно или съответно пълно фифо-то и си изключва прекъсванията за този конкретен ендпоинт. За хоста този ендпоит изглежда busy и той само си го полира периодично. Няма трафик обаче.

Как тогава трябва да се излезе от ситуацията, без човешка намеса ?

Ситуацията в случая не е ясна... Изглежда като да е проблем от страна на пик-а, а не на хоста.

Иначе ако трябва да се рестартира връзката с хоста, приложенията под windows трябва да слухтят за PnP нотификациите за device disconnect и да си затварят хендълите преди девайса да се е закачил отново. Под лайнукс няма нужда да се реагира незабавно, но за да се възстанови комуникацията също трябва да се мине през затваряне/отваряне.

Ами те пиковете се шашкат много лесно. Случвало се е дори поялника като си пускам да ресетва от смущения.
По принцип е така както е написал miro_atc трябва и windows приложението да се дисконектне. Понякога обаче поради калпава програма от моята страна комуникацията забива и се е случвало програмата да не може да се откачи. Става дума за терминална програма Docklight Давам и дисконект и чак като откача буксата тогава дисконектва. Така че за мен правилния ред е: установяване на липса на комуникация -> ресет на PIC-а и изчакване няколко сек. -> Disconnect на windows приложението, от съответния витуален COM, -> и след малко повече секунди от на PIC-a reconnect към същия COM.

Пиковете се смущават ,колкото другите, може би - и по-малко, обикновено е проблемна ниво устройство/проект.

Звучи почти достоверно.
Добрата система би трябвало да допусне и ресет на комуникационния канал по инициатива на коя да е от страните.
При УАРТ това е относително лесно , системните функции са достатъчни - и без да имаш достъп до регистрите и битовете. Виртуалният порт дава ли допълнителни функции с които да ресетнеш УСБ порта по-надълбоко?

Не съм човъркал толкова навътре. Моето приложение не показва дали се е дисконектнало, реално (имам си и моя програма). Това което ти казваш явно го няма в тази терминална програма (Docklight). Тя все пак е направена да работи и с COM1 хардуерния.
А иначе COM порта си остава в списъка, докато не се дисконектне. Т.е. ако откача PIC-а ако не съм се дисконектнъл го има като наличен. Има си го в device manager. Драйвера за FTDI или други чипове не зная как се държи.