FT232

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Olga Nonova! You wrote in conference fido7.ru.embedded to Alexandr Torres on Tue, 16 May 2006 08:41:44

+0000 (UTC):

MB>>>> таковым. Сyнyл дискетy, потом воткнyл зyбастый

PG>>> Вот где ошибка: ^^^^^^^^^^^^^^^, а не следовало. :)

AT>> Очень даже следовало, и не только для ребенка - блютус просто AT>> незаменимая вещь для hands-free, чтобы шнурки не путались.

ON> Для мультимедийных игрушек на диване, может, и "незаменимая". ON> Для серьезных же целей wireless управления- наплевать и ON> забыть. Да и жрет немерянно.

Жрет оно как раз мерянно, но не для industrial применений безусловно.

dima

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Alex Mogilnikov! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Tue, 16 May 2006 15:12:51

+0400:

DO>>> А с UART вообще-то можно было и не заморачиваться, для VDM DO>>> винда стандартный 16550 виртуализирует не плохо.

AM> Хуже чем хотелось бы. Есть ДОС-программа, которая передает AM> пакет данных и ждет подтверждение приема. Если подтверждения AM> нет, повторяет передачу. В настоящих ДОС все работает AM> нормально, в большинстве эмуляторов тоже. А вот в виндовом AM> эмуляторе она работать отказалась. Если я правильно помню, там AM> проблема была в том, что эмулятор не отрабатывает временные AM> задержки передачи: AM> при передаче длинного пакета он записывался в порт мгновенно, AM> и программа начинала отсчет таймаута, который успевал истеч до AM> того, как пакет реально передавался.

Вообще, подобные проблемы я встречал и в нативной win32 программе, начиная с ее родного гипертерминала. Выставляешь 1мс задержку между байтами, делаешь paste в него, смотришь скопом на Tx и видишь, что байты идут с плавающей задержкой в районе

10мс. Ставишь эту задержку в 0 - идут сплошняком. Чтобы в своей программе это сделать, да еще и так, чтобы это не ставило колом все остальное, приходится довольно нетривиальные вещи делать, пользоваться multimedia taimer'ом и все равно не без проблем. Что с одной стороны понятно - это ведь многозадачная и не реалтаймовая система, а с другой стороны не очень, ведь та же мультимедиа вполне себе успевает в реальном времени делать в сотни тысяч, если не в миллионы раз более ресурсоемкие вещи, и еще и время остается.

dima

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Aleksandr Konosevich! You wrote in conference fido7.ru.embedded to Michael Belousoff on Tue, 16 May 2006 17:03:52

+0400:

AK>>> Мне пpосто любопытно было бы поглядеть на моpдочкy г-на AK>>> фельдфебеля в тот самый момент, когда с гейта в эхy пойдyт AK>>> письма "якобы от стаpых подписчиков", *но* с тем же magic AK>>> number & e-mail ... ЖB}}}

MB>> Следyет ли это pасценивать ка пpямyю yгpозy?

AK> Hапомню, что началось всё с того, что Василевский обхаял AK> Плотояда ;-)

AK> PS Ежели Плотояд *решит* *действовать* - ни ты, ни я его не AK> остановим, можешь не сомневаться !

Классический случай неуловимого Джо, этот твой виртуальный плотояд, он же киллер задрипанный.

dima

Здравствуйте, Уважаемый All!

Tue May 16 2006 15:50, Dmitry Orlov wrote to Alex Mogilnikov:

DO>>>> А с UART вообще-то можно было и не заморачиваться, для VDM DO>>>> винда стандартный 16550 виртуализирует не плохо.

AM>> Хуже чем хотелось бы. Есть ДОС-программа, которая передает AM>> пакет данных и ждет подтверждение приема. Если подтверждения AM>> нет, повторяет передачу. В настоящих ДОС все работает AM>> нормально, в большинстве эмуляторов тоже. А вот в виндовом AM>> эмуляторе она работать отказалась. Если я правильно помню, там AM>> проблема была в том, что эмулятор не отрабатывает временные AM>> задержки передачи: AM>> при передаче длинного пакета он записывался в порт мгновенно, AM>> и программа начинала отсчет таймаута, который успевал истеч до AM>> того, как пакет реально передавался.

DO> Вообще, подобные проблемы я встречал и в нативной win32 программе, DO> начиная с ее родного гипертерминала...

Решение проблемы виндовского COM-порта такое. Отказаться навсегда от таймаута в качестве признака окончания пакета. Системы типа MODBUS в виндах работают непредсказуемо. Взамен, в состав пакета, где-нибудь в заголовке, вставляется поле- длина блока данных. Затем, на примемной стороне просто ждут, когда будет принято число байт, указанное в заголовке. Таймаут использовать только в качестве аварийного выхода. Проверено. Винды с нерегулярными посылками по СОМ порту- отдыхают.

Всего Всем Хорошего Ольга

X-Virus-Scanned: amavisd-new at bezeqint.net

Hello, Olga Nonova! You wrote in conference fido7.ru.embedded to All on Tue, 16 May 2006 14:42:09 +0000 (UTC):

DO>> Вообще, подобные проблемы я встречал и в нативной win32 DO>> программе, начиная с ее родного гипертерминала...

ON> Решение проблемы виндовского COM-порта такое. Отказаться ON> навсегда от таймаута в качестве признака окончания пакета.

На самом деле, нужно просто уметь их готовить. Другое дело, что это не так просто, как хотелось бы.

dima

Здравствуйте, Уважаемый Ruslan!

Tue May 16 2006 22:06, Ruslan Mohniuc wrote to Olga Nonova:

ON>> Решение проблемы виндовского COM-порта такое. Отказаться навсегда от ON>> таймаута в качестве признака окончания пакета. Системы типа MODBUS в ON>> виндах работают непредсказуемо.

RM> Во-первых, есть еще MODBUS-ASCII. Во-вторых, и MODBUS-RTU тоже работает RM> нормально.

У меня печальный опыт использования таймаута в качестве сигнала о завершении пакета. Винды отучили надеятся на воспроизводимость и регулярность посылок по COM-порту. Поэтому я перешла на пакеты типа IP-пакетов, только значительно проще и экономнее.

Всего Вам Хорошего Ольга