Опитваме се да пратим данни по RS232 към устройство, което има определен буфер за данни. Тъй като данните се обработват бавно, реализираме контрол на потока. Xon/Xoff работи без проблем.
Хардуерния обаче има проблеми - след като се забрани CTS сигнала, Windows продължава да праща данни още известно време.
Питам аз - що за хардуерен контрол е това, след като хич не се държи като такъв?
Проблема в Windows ли е, някой сблъсквал ли се е с него и може ли да се реши?


PS Буфера на PC UART-a (хардуерния) е само 16 байта, а данните които получаваме в излишък са около 1к...

за каква серийна порта става въпрос?
на чипсета, на PCI или на USB?
моя опит се изчерпва с проблеми при приемане (към win)

PC - COM1 (RS232) -> RS232 - MCU

TX -> RX
RX <- TX
CTS <- CTS

CTS би трябвало да паузира предаването (поне според мен)...

ЕDIT:
Офф, сега разбрах какво ме питаш - порта е на дъното (чипсета може би?)

@ex-man
мисля, че не е точно така. Смисъла на RTS - CTS e че едното устройство подава
заявка за предавне към другото и то му отговаря, когато е готово, но това
касае само началото на предаването, т.е. след като веднъж е казало - "Готов съм, давай"
то трябва да си приеме пакета, а не да си спира когато му скимне.
Предполагам, че ти липсва дотатъчно буфер. Пробвай със сигналите DSR и/или DCD.

Изключи хардуерния буфер и ще се оправи.
(ХР иска да си с администраторски права.)

///(Често ми се е случвало при връзване машини с ЦПУ към комп, примерно.)
///DSR и DCD не може да са причината. От тях може да не тръгне комуникацията, ако се изискват
от устройството, но не може да се следят по-бързо от CTS. Не се занимавай с тях.

Ако говориш за това (картинката долу) - изключен е ...

странно... би трябвало да работи нормално, т.е. да ти даде най-много още 2-3 знака при големите скорости
не е хардуерен проблема, нещо във софтуеризъма е.
мога да ти препоръчам да поекспериментираш с други видове порти - PCI, USB и ако има същия резултат да го умуваме пак

Преди мисля съм пробвал с USB към сериен (преходник) и ситуацията беше същата (по спомени). За момента изделието е замразено, та експерименти - по-нататък...
Скоростта при която пробвахме беше 115200..
Според мен е проблем на прозорците - вероятно управляват софтуерно серийния порт, съответно регистъра на състоянията се чете през някакъв интервал и т.н..

Проблемът е прозоръчен и май няма решение при по-високите скорости. Flow Ctrl се прави софтуерно, независимо че сигналните линии се наричат "хардуерен контрол". Би следвало всяка промяна на такъв вход да генерира прекъсване на OS и тя да си знае какво се случва и съответно да престане на праща повече знаци за предаване. Да ама не. Явно й трябват няколко десетки микросекунди, докато се усети, а дотогава си приказва като папагал.
Възможните решения на твоя проблем са:
1. Да ползваш по-ниска скорост на предаване.
2. Да казваш, че устройството ти се е напълнило с няколко знака по-рано.
3. Да експериментираш с някои USB преходници. Има модели, които при съответна настройка правят контрола с фърмуер, независимо от ОС.

Преди известно време и аз имах подобен проблем, само че в обратна посока.
Предавах към PС - то переодично (0.1s) пакети на 115200, които малко
надхврляха хардуерния му буфер. бат Бил се задъхваше и тук-таме изтърваше
нещо. Сложих USB-RS232 и нещата заспаха. Както знаете, те си имат буфери,
в моя случай не си спомням точно колко бяха, но свършиха работа.

хардуерния flow-control не може да забранява данните които са вече в Tx фифото!
щото на асиа-то това си е просто един сигнал нямащ нищо общо с фифото!

между другото Xon/Xoff също не може да забранява данните в Tx-buffera - тъй че най-вероятно проблема е че твоето у-во НЕ работи с hard-control (а само с Xon/Xoff)

другото е да пращаш байт по байс с времезадръжка (1ms) - бавно но сигурно!