Здравейте и за много години на всички , желая здраве и късмет!
Поводът по който отварям тази тема лежи на следната хардуерна конфигурация:
1. Device -> PC
2. Device <- PC
На РС-то използвам една терминална програмка WTerm, която има опция за разрешаване на Hard Flow Control с линиите съответно CTS и RTS. Освен това този контрол съм го разрешил и от Device Manager на РС-то. Скоростта с която работя е 115 200. В Device пиша мой код в който съм конфигурирал 2 GPIOІта да работят като CTS и RTS. В случай 2 по-горе (когато пращам данни от РС към Device),в моето устройство СТS се явява изход, и чрез него казва на предавателя в определени моменти (PC) "спри да предаваш" и съответно "продължи да предаваш". Обаче при случай 1, когато моето устройство предава към комп-а, комп- а не мърда нито една от двете линии (CTS или RTS). На осцилоскопът не наблюдавам никаква активност на двете линии. В резултат на което естествено губя малки порциики данни.
Въпросът ми е има ли начин или терминална програма, с които да се разреши този Hard Flow Control, от страна на PC-то, и да работи така както се очаква и така както го пише в учебниците. Операционната ми система е Windows 7 x32. Понеже пак казвам, аз този контрол го разрешавам първо от Device Manager на РС-то и след това го активирам и от wTerm терминалът, който ползвам. Благодаря!

Предполагам че ползваш някакъв преходник USB - Serial. В него следва да се търси проблема предполагам,а не в PC осфтуера.
Старите FTDI чипове при голям трансфер на данни,нещо се омазваха и или забиваха или се губеха порции данни.
В общия случай ако когато компютъра предва,се съобразява с флоу контрола,значи си е включен.

Здравей, ами не на местото на преходникът който предмопагаш че ползвам имам MAX3238E, който представяла многоканален драйвер на 3-5,5V и след него ми е веднага кабелът RS, след което той отива в КОМ портът на РС-то. Нямам USB кабели и FTDI конвертори.

При някои от новите дъна компорта не е истински. Пак се явява някакъв преходник и не работи както стандартния.
Другия проблем може да ти идва от хардуера. Имаше тестови програмки с които може да комутираш пина и да видиш дали сигнала стига до твоето устройство.

В учебниците май-пише и 4 жици за такъв контрол, DTR/DSR CTS/RTS, та сигурно има вариации.

Да в учебниците са 4 линиите, аз ги преслушах и 4-те с цел да открия някаква активност по DTR или DTS за мога да го оправя. Но по на сички пинове от DB9 къплунгът за RS232, няма никаква активност повреме на трансферът, а в изходният ЛОГ виждам че пак се губят байтове. Никола можеш ли да дадеш име или линк на такава програма (за която говориш в твоя пост) за да видя да разклатя CTS/RTS пиновете в РС-то.

Като го разучавах серийния порт някога бях ползвал нещо готово. Но вече не си спомням какво. RealTerm имаше като че ли такива неща,провери.

А когато предава ПК има ли някаква активност?

Всъщност HyperTerminal /WinXP/ активира плюс на перо 7 и перо 4.
Като натискам бутони , броячът на време заспива , докато не окъся 7 и 8 перо.

Намерих терминална програмка с която мога да клатя ръчно CTS на РС-то. Като го разцъкам, виждам на RTS пинът на моето устройство че достига сигнал. Това говори че като пусна трансферът от устройството към PC-то, терминалити които ползвам немогат да активират CTS на PC-то когато загубя байт. Въпросният терминал който намерих, лошото му е че само като цъкам един бутон от неговият панел мога да активирам CTS на РС-то, а ми се щеше то само да може, автоматично да го прави, когато неможе да смогне с трансферът......

Когато предава РС-то, устройството клати своят CTS (който е вързан към RTS-а на PC-то) и до куплунгът на РС-то достига този сигнал. Така че има активност в случай 2.

Няма как ПК да активира сигнал, когато загуби байт - не е логично.
По-скоро шв го активира , когато приемният буфер наближи препълване.
Това обаче зависи от софтуера,буферът е софтуерен, оригиналният хардуер няма такава автоматика.
Загубването на байт се следи на логическо/пакетно ниво.
Всъщност какво ти трябва, софтуер за лог докато се бориш от другата страна ?

Както ги обясняваш нещата, а и както ги проучих тези няколко дни, стигаме до едно и също твърдение. Или както го казваш ти "Това обаче зависи от софтуера,буферът е софтуерен, оригиналният хардуер няма такава автоматика.". Понеже аз разчитам от другата страна (в случая от страна на РС-то )този контрол да става автомотично. С една дума буферите в ком-па са достатъчно големи да поемат целият поток, а самият контрол (предполагам) се активира когато FIFO буферите на РС-то са напълнени примирно на 70 %. От страна на моето устройство такъв алгоритъм имам и знам точно на какъм процент да разклатя CTS-а. Но в РС-то нямам софтуер в който мога да пипам. Така че предполагам че ако направя някакво GUI за сериина комуникация, в кодът зад това GUI, мога да окажа когаточно да ми се клати CTS-a от страна на РС-то. Поне аз така ги виждам нещата - софтуер от страна на РС-то с който да оказвам кога да ми се активира хард флау контролът и при какви условия....

Мисля , че трябва да промениш малко мисленето си. "Класическото" PC има примитивни
серийни портове без FIFO. Подобрената версия има чипове с 16 байта FIFO, но такава автоматика не е заложена. Модерните PC ,каквото и подобрение да имат, то е "нестандартно", ще се поддържа но ниво специализиран драйвер и т.н... Тоест, според мене,
не очаквай такава логика откъм PC. Трябва да решаваш проблема по друг начин - или на протоколно ниво, или минаваш на УСБ или каквото там може да ти свърши работа. Лично аз съм скептичен към система, която разчита на безгрешен 100% трафик. Тоест наличието на грешки и пропускането на байтове трябва да го заложиш в поведението на системата си.

От друга страна - това ,че в момента PC изпуска байтове е проблем, с който също трябва да се пребориш. Има разни софтуерни логери/монитори дето проследяват трафика по серийния порт - та пусни един такъв - може да помогне в търсенето на проблема.