EvgeniyM

В 2010 году разработали софт под Win7, работающий с картой CP-132EL. Смотрите мой древний топик: http://www.moxa.ru/forum/index.php?/topic/1036-%D0%BF%D0%BB%D0%B0%D1%82%D0%B0-cp-132el-i/ Эта карта работает в системе с нестандартной скоростью 500 000 bps. После того, как получили драйвер для Win7, v1.19, поддерживающий линейную установку скоростей - вопрос с нашей нестандартной скоростью ( 500 kbps) был полностью снят: выпустили много изделий. Сейчас софт переводим на Linux. Взяли драйвер Linux v1.16 . В release notes на этот драйвер указано, что поддерживается установка нестандартной скорости: Release Note: ============= ver1.16 Build 14030317 (03/03/2014) ........ ....................... 5. New: Support linear baud for MUE250/MUE450/MUE850. ....................... Далее - лезу в текст драйвера (благо он идёт с исходными текстами) - вижу, что есть там код, который устанавливает нестандартную скорость: mxpcie.c, строка 3269: static int set_linear_baud(unsigned char *base, long newspd) { unsigned char scr, cpr; unsigned short div; int i, j, divisor = 0, sequence = 0; .............. ............. Но когда начинаю работать с устройством - натыкаюсь (вижу это на осциллографе), что скорость устанавливается - только стандартная: 4800, 9600, 19200,...,115200,230400,460800,921600 При попытке открыть порт на 500000 bps после включения - имею на осциллографе 921600. Как с этим быть?

Сегодня установил новый драйвер версии v1.19 Те проблемы, которые были с v1.18.11 вроде бы испарились(!!!!). По крайней мере, те установки, которые намертво ложили обмен - сейчас очень даже нормально работают! Как оттестирую на большой системе - сообщу результат. Похоже, что моховцы ввели в новой версии драйвера какие-то координальные исправления!

Выкладываю исходники и файлик описания (ProblemWmoxa.docx) . Спасибо за любые советы. problem_with_moxa.RAR

Можно, конечно. Только я сейчас еду в командировку, 25-го апреля - выложу.

Завороты остались. В среднем из 2000 пакетов в секунду ( по 4 портам ) где-то 30 пакетов заворачиваются на себя. Причём новый драйвер даёт больше заворотов чем старый. Обмен происходит пакетами. У каждого пакета - адрес-получатель, адрес-отправитель, тело и CRC. Отправитель отправляет пакет и ждёт, пока получатель на него не ответит. Отправка - это запись в порт, получение - это - чтение из порта. Получается так, что иногда ответ (то что я аппаратно читаю из порта) - это только что отправленный пакет (это я вижу из адреса отправителя - это я сам) + ещё какой-то мусор, который надо чистить. Пока что эту ситуацию не победили.

Новый драйвер пока работает хорошо. 8N2 теперь работает как и должно быть - с двумя стоповыми битами. 8N1 - заработал тоже как - следует с одним стоповым битом. Соответственно сразу пришлось подправить софт. По поводу заворотов "на себя" - хорошенько протестируем - сообщу. (У нас на компе 3 мохи (132EL), т.е. 6 портов, на каждом порту где-то по 8 "доморощеных" контроллеров на микросхемах PIC. Скорость обмена сейчас 500000. Пакеты от 100 байт до 4K) Т.е. где-то 50 устройств, с которыми головной компьютер обменивается информацией.

Недавно пользовался CP-132UL - там спокойно устанавливалась скорость 500 000 bps Теперь надо запустить CP-132EL-I - там я не могу установить скорость 500 000 bps. Могу только установить стандартную скорость. Как обойти это ограничение? 460 800 либо 921 600 bps - не годятся. Надо, чтобы можно было установить произвольную скорость. Есть ли где-либо на сайте "моха" список плат, поддерживающих нестандартные скорости?

Ситуация с большего прояснилась. Дело в самой винде.

У нас сеть - RS485. Головной контроллер на ПК на скорости 500000 bps кидает короткие пакеты (типа запросов) - 30 байт, слэйв-устройства отвечают длинными -- 100 байт. (Отвечает тот, к которому запрос отправлен). Обмен по принципу: запрос-ответ-запрос-ответ-и.т.д. Обмен устойчивый, но прикладная программа видит ответ на запрос только через секунду, после отправки этого запроса в порт, в то время как реальное время ответа (видим на осцилографе) - в районе 1 миллисекунды. "Видит ответ" - это значит - винда выдаёт ненулевое значение bytesAvailable после запроса к стандартной API-функции Win к драйверу COM-порта. Почему такое возможно? Или драйвер надо правильно настроить (установить другой RTL или TBL)? Или после каждой записи в порт делать flush?