2304000 в порту: миф или реальность?

[Andrey V.Panukov]

>либо не удавалось поймать момент, когда отключалась RTS.
Вот!

>А вот в старые времена Terminate умела отключать RTS, было видно
>невооружённым взглядом: идёт запись на диск, RTS гаснет...

Само собой, работа с регистрами реализовывалась в самой программе. Всё делалось последовательно, приняли, записали, приняли, записали и т.д.

В данном случае, если ПО не читает из порта(читает всегда, как правило), запись принимаемых данных осуществляется во внутренний буффер драйвера порта, если он переполнен и установлено аппаратное управление потоком - снимается RTS (программное - посылается XOFF).

В данном случае вырисовывается проблема другого характера, когда был принят новый байт данных, а предыдущий еще не был считан из UART. (Hardware overruns, а не buffer overruns).

Oxy,
Попробуйте увеличить/отключить FIFO на прием и на передачу.

[Technical Support]

[Andrey V.Panukov]

Еще раз:

Коротенько и на пальцах.
ПО читает из порта, устанавливает таймауты, организуя запросы на чтение(буффер).
Прерывание(RDA|CTI), драйвер читает данные из UART, если в данный момент есть запрос на чтение, данные записываются в буффер запроса, если нет - во внутренний буффер.
При следующем запросе, если есть данные во внутреннем буфере - читаются из него.
Если внутренний буффер заполняется полностью и установлено аппаратное управление потоком, снимается сигнал RTS.

И в нормальном состоянии, Alt-tab ну ни как не должен вызывать overruns. (в случае w98/me - маловероятно, но возможно, учитывая архитектуру ядра).

[Technical Support]

[Andrey V.Panukov]

Совершенно верно.

[Oxy]

2 Technical Support
Если быть точным, вопрос был именно по Hardware, а не по Serial Overruns (см. пост №5).

[Oxy]

.

[Andrey V.Panukov]

Oxy,
В данном случае под serial overruns предполагалось hardware.

[Oxy]

Еще замечено, что Hardware overruns в статистике обычно ровно (реже -- почти) столько же, сколько CRC errors

[Andrey V.Panukov]

>Еще замечено, что Hardware overruns в статистике обычно ровно
>(реже -- почти) столько же, сколько CRC errors
Естественно, пропал байт или два или ... - контрольная сумма пакета не сошлась.

>Кстати, при скорости порта 230400 и коннекте 28800 Hardware
>Overrans все равно наблюдаются.
Разумеется, увеличились?
Лучше посмотрите, в настройках порта буффера FIFO включены и на прием установлены в максимум?
Да и забейте на эти 230400, реально нафик не нужно, как припарка после бани.

зы. билли [800 кб]

[Oxy]

[Technical Support]

Hardware overruns и serial overruns - два названия одного и того же явления. Рассмотрим простейший последовательный порт, без буфера FIFO. В нём есть два регистра, сдвиговый и буферный. Данные бит за битом поступают в сдвиговый регистр, пока не "соберутся" все 8 бит байта. После этого байт поступает в буферный регистр и последовательный порт информирует о готовности "отдать" байт. В это время в сдвиговый регистр поступает следующий байт.

Задача драйвера - прочитать (освободить) буферный регистр до того, как будет завершена сборка следующего байта. Если этого не происходит, то новый байт теряется и выставляется (аппаратно) флажок ошибки (переполнение данных, overrun). Когда драйвер в конце концов добирается до порта, он видит этот флажок и фиксирует ошибку. Счётчик таких ошибок и называется Serial overruns (в журнале модема в Windows) или Hardware overruns в ModemSpd.

При наличии FIFO суть дела не меняется, просто буферный регистр способен запомнить не один, а 16 байт, и соответственно, у драйвера есть больше времени на реагирование.

[Oxy]

Понял, попробую уменьшть порог.
Кстати, как я обещал: работоспособность моей системы на 230400 с драйвером shsmod v.1.93b подтверждаю (shsmod говорит, что чип Winbond W83977TF)
Вот только геморой появился: после выхода из Sleep Mode нужно запускать shsmod вручную.
Может кто подскажет, как автоматизировать запуск какой-либо проги при выходе из спящего режима WinME

[Technical Support]

[Oxy]

Эт точно, оффтоп пошел
А с портом вроде разобрались. Всем СПАСИБО.