-
- На машине МСВС (Linux 2.4): ++(154 знак., 28.02.2011 16:39 - 16:43)
- <blockquote>ftdi full_speed/hight_speed?</blockquote> full_speed cvv(28.02.2011 17:01)
- Извлеките преобразователь. ++(321 знак., 01.03.2011 10:03)
- поток отладочной инфы настолько большой что dmesg обновляется каждые несколько секунд. я не успею сохранить в файл актуальный фрагмент. Сюда зашлю лог syslog-а - cvv(01.03.2011 12:08 - 13:33)
- На этом участке лога было задержано два пакета гдето на две секуды (идущие от удаленной машины к нам). У меня впечатление что надо более подробный лог. cvv(3945 знак., 01.03.2011 16:08)
- на 49й секунде был затык с записью в юсб. Это , наверное, и были те 2 секунды что пакет застрял. Но это не 10 секунд о которых вы в начале писали. Подобные задержки я наблюдал в Виндах с дровами F2XX, правда у меня был большой поток данных в ПК на GDI(158 знак., 01.03.2011 16:34)
- Это можно проверить также: проверив драйвер и аппаратуру Win машины отдельно. ++(184 знак., 01.03.2011 16:53)
- надо будет подумать над этим. - cvv(01.03.2011 17:15)
- из чего это видно? - cvv(01.03.2011 16:40)
- <pre>last message repeated 39 times</pre> и так 2 раза на протяжении 49й секунды, т.е. всего было 78 повторов за секунду, при том что остальные пакеты проходят с повторением 25-26 раз раз в секунду. Кстати, и для остальных пакетов это не очень GDI(70 знак., 01.03.2011 17:01)
- тоесть каждый "serial_write_room" - это транзакция записи по шине USB? cvv(198 знак., 01.03.2011 17:12)
- select это на приемной стороне, а я про передающую честь говорю, она же постоянно пытается писать в порт, если я правильно интерпретировал лог. - GDI(01.03.2011 17:17)
- приложение каждые 500 ms пишет в порт 4 байта. select делается между записями в порт. на случай если чтото придет. - cvv(01.03.2011 17:22)
- У меня тут возникла бредовая идея, вы же с внешним кварцем FTDI используете, может там велик разброс частот на разных сторонах? Там вроде есть возможность внешней синхронизации, можно попробовать их засинхронизировать между собой. Или с одного GDI(32 знак., 01.03.2011 17:30)
- при разбросе частот мы бы получили битые фреймы, неправильно принятые байты, и подобное - ниразу не наблюдали. cvv(144 знак., 01.03.2011 17:34)
- У меня тут возникла бредовая идея, вы же с внешним кварцем FTDI используете, может там велик разброс частот на разных сторонах? Там вроде есть возможность внешней синхронизации, можно попробовать их засинхронизировать между собой. Или с одного GDI(32 знак., 01.03.2011 17:30)
- приложение каждые 500 ms пишет в порт 4 байта. select делается между записями в порт. на случай если чтото придет. - cvv(01.03.2011 17:22)
- select это на приемной стороне, а я про передающую честь говорю, она же постоянно пытается писать в порт, если я правильно интерпретировал лог. - GDI(01.03.2011 17:17)
- Похоже, что тестится самодельным тестом. Там 4-байтовые посылки: ++(390 знак., 01.03.2011 17:10)
- тоесть каждый "serial_write_room" - это транзакция записи по шине USB? cvv(198 знак., 01.03.2011 17:12)
- <pre>last message repeated 39 times</pre> и так 2 раза на протяжении 49й секунды, т.е. всего было 78 повторов за секунду, при том что остальные пакеты проходят с повторением 25-26 раз раз в секунду. Кстати, и для остальных пакетов это не очень GDI(70 знак., 01.03.2011 17:01)
- Это можно проверить также: проверив драйвер и аппаратуру Win машины отдельно. ++(184 знак., 01.03.2011 16:53)
- Вроде бы, ошибок usb нет. ++(512 знак., 01.03.2011 16:22)
- без no_hardware_flow_control эхо имеем без проблем. включить hardware flow control - проблемно. - cvv(01.03.2011 16:44)
- Также терминал и аппаратная перемычка на Win машине. ++(136 знак., 01.03.2011 16:56)
- работает, только если работать долго, ну с пол-дня, то можно нарватся на ситуацию что на одной машине нажал энтер и сидиш ждешь пока оправленная строка появится на другой, в то время как остальное время задержки на глаз не заметны ... - cvv(01.03.2011 17:06)
- Такое происходит в обе стороны Win->Lin/Lin->Win? - ++(01.03.2011 17:15)
- В обе. - cvv(01.03.2011 17:16)
- Если разъединить машины. На каждой машине использовать перемычку rxd-txd, такое случается? - ++(01.03.2011 17:20)
- не наблюдали ни разу. ну по крайней мере заметных на глаз задержек небыло. 200-300 ms максимум. cvv(46 знак., 01.03.2011 17:26)
- Можно ли соединить корпуса машин толстым проводом по земле, временно выкинуть развязку(соединить rs_ftdi_Lin<->rs_ftdi_win) и протестить? ++(210 знак., 01.03.2011 17:42)
- mmm. корпус одной из машин платсковый + опломбированй + без ком-порта. так что даже не знаю что из этого можно сделать. - cvv(01.03.2011 18:05)
- развязка: одна между машинами на микросхеме ADUM. rts-dtr весят в воздухе. Спасибо за идеи, буду пробовать. - cvv(02.03.2011 10:23)
- Развязка внутри машины? Если отсоединить машины, замкнуть на выходе опто (изолированную (наружную) часть) развязки rxd-txd- точно всё ok? ++(623 знак., 01.03.2011 19:52 - 02.03.2011 08:28)
- mmm. корпус одной из машин платсковый + опломбированй + без ком-порта. так что даже не знаю что из этого можно сделать. - cvv(01.03.2011 18:05)
- Можно ли соединить корпуса машин толстым проводом по земле, временно выкинуть развязку(соединить rs_ftdi_Lin<->rs_ftdi_win) и протестить? ++(210 знак., 01.03.2011 17:42)
- не наблюдали ни разу. ну по крайней мере заметных на глаз задержек небыло. 200-300 ms максимум. cvv(46 знак., 01.03.2011 17:26)
- Если разъединить машины. На каждой машине использовать перемычку rxd-txd, такое случается? - ++(01.03.2011 17:20)
- В обе. - cvv(01.03.2011 17:16)
- Такое происходит в обе стороны Win->Lin/Lin->Win? - ++(01.03.2011 17:15)
- работает, только если работать долго, ну с пол-дня, то можно нарватся на ситуацию что на одной машине нажал энтер и сидиш ждешь пока оправленная строка появится на другой, в то время как остальное время задержки на глаз не заметны ... - cvv(01.03.2011 17:06)
- Также терминал и аппаратная перемычка на Win машине. ++(136 знак., 01.03.2011 16:56)
- без no_hardware_flow_control эхо имеем без проблем. включить hardware flow control - проблемно. - cvv(01.03.2011 16:44)
- на 49й секунде был затык с записью в юсб. Это , наверное, и были те 2 секунды что пакет застрял. Но это не 10 секунд о которых вы в начале писали. Подобные задержки я наблюдал в Виндах с дровами F2XX, правда у меня был большой поток данных в ПК на GDI(158 знак., 01.03.2011 16:34)
- На этом участке лога было задержано два пакета гдето на две секуды (идущие от удаленной машины к нам). У меня впечатление что надо более подробный лог. cvv(3945 знак., 01.03.2011 16:08)
- поток отладочной инфы настолько большой что dmesg обновляется каждые несколько секунд. я не успею сохранить в файл актуальный фрагмент. Сюда зашлю лог syslog-а - cvv(01.03.2011 12:08 - 13:33)
- Извлеките преобразователь. ++(321 знак., 01.03.2011 10:03)
- <blockquote>ftdi full_speed/hight_speed?</blockquote> full_speed cvv(28.02.2011 17:01)
- Надо бы прежде всего проверить воспроизводимость эффекта на USB/COM-конвертере другого типа (другой фирмы), благо они дешевы, или взять у кого-нибудь взаймы. - Ксения(18.02.2011 11:40)
- хоть бы написал, в какую сторону замирает, и какой FT232 - B или R koyodza(63 знак., 17.02.2011 17:09 - 17:12)
- замирает в обе стороны. FTDI-232BL. обмен через VCP. - cvv(18.02.2011 10:20)
- Байты не теряются? Vallav(89 знак., 17.02.2011 09:04)
- не теряются. возможно что-то. но что и почему? я давно пользуюсь FTDI но ничего подобного не видел. - cvv(17.02.2011 11:29)
- То есть, у Вас за 10 секунд меньше 64 байт? Vallav(132 знак., 17.02.2011 14:35)
- А это у вас вся связь замирает на 10 секунд или просто какая то часть данных выпадает из потока и потом через 10 секунд приезжает? Приложение со стороны ПК сами писали или что-то готовое используете? - GDI(17.02.2011 16:26)
- вся связь замирает. приложения писали сами. - cvv(17.02.2011 16:58)
- Так может это само приложение умирает? Ждет где-то чего-то, типа записи в FTDI, а потом по таймауту оживает. Дрова FTDI не пробовали другой версии ставить? И какие драйвера собственно используете VCP или F2XX? Да у Вас там еще и ОСи разнородные, GDI(35 знак., 17.02.2011 17:12 - 17:15)
- не приложение - однозначно. или дрова или FTDI. Дрова VCP - последняя версия для ветки 2.4 - cvv(17.02.2011 17:50)
- меня всегда веселят подобные утверждения :=) - koyodza(17.02.2011 18:33)
- не приложение - однозначно. или дрова или FTDI. Дрова VCP - последняя версия для ветки 2.4 - cvv(17.02.2011 17:50)
- Так может это само приложение умирает? Ждет где-то чего-то, типа записи в FTDI, а потом по таймауту оживает. Дрова FTDI не пробовали другой версии ставить? И какие драйвера собственно используете VCP или F2XX? Да у Вас там еще и ОСи разнородные, GDI(35 знак., 17.02.2011 17:12 - 17:15)
- вся связь замирает. приложения писали сами. - cvv(17.02.2011 16:58)
- у меня за 10 сек порядка 96 байт. плюс если бы проблема была в этом то это бы имело место каждые 10 сек а не иногда ... - cvv(17.02.2011 15:02)
- А это у вас вся связь замирает на 10 секунд или просто какая то часть данных выпадает из потока и потом через 10 секунд приезжает? Приложение со стороны ПК сами писали или что-то готовое используете? - GDI(17.02.2011 16:26)
- То есть, у Вас за 10 секунд меньше 64 байт? Vallav(132 знак., 17.02.2011 14:35)
- не теряются. возможно что-то. но что и почему? я давно пользуюсь FTDI но ничего подобного не видел. - cvv(17.02.2011 11:29)
- USB на уровне его протокола. Драйвер /dev/ttyxxx, приложение, собственно сам FTDI. На виндах аналогично. Для начала стоило бы посмотреть посередине -- кто тормозит. - fk0(16.02.2011 19:42)
- На машине МСВС (Linux 2.4): ++(154 знак., 28.02.2011 16:39 - 16:43)