Терминална програма няма как да знае ти какво искаш. Компютъра ти предоставя хардуер, твоя грижа е да си го управляваш някак. Терминалната програма вижда това, което автора и е "казал" да вижда и съответно го показва. Ако това не ти е достатъчно трябва да си направиш твоя програма, която да следи вече каквото ти и кажеш и да се държи както ти искаш. По принцип хардуера го може това дето го искаш. Твоя грижа е да му "кажеш" кога и какво точно да прави.

Сигурен ли си, че не си омешал имената на сигналите?
CTS на PC-то е вход, RTS му е изход. Когато твоето устройство предава, то трябва да следи RTS на PC-то (7-ми пин на 9-пиновия конектор на PC-то) и ако се деактивира, спира предаването докато сигналът не се активира наново.

Другото - къде точно ти се губят байтовете? Аз съм забелязал, че по време на скрол на екрана хипертерминала на уиндоус при високи скорости понякога губи байтове. Обаче ако си му задал едновременно с това да логва всичко и във текстов файл, във файла всичко си е наред, изгубеното е само на екрана, т.е. това е проблем на самия терминал, не на драйвери или на хардуера.

Иначе, RTS-CTS flow control си му работи както се очаква, с него не съм имал особени грижи.

Предполагам, че всичко е свързано като хората / жиците де/.
Но Бозата има едни буфери - пробвай да изключиш FIFO буферите от девайс менаджера.
//Хардуерно - това си е стек, ама софтуерно не работи като хората...

От отговорите които виждам, значи нещата вървят към писане на GUI . Не бях сигурен в това и затова отворих темата, .... от страна на ПС-то се надявах нещата да работят, но все пак човек нетрябва да е напълно сигурен. Само да дам малко уточнение на част от колегите които поставят някои въпроси, които и аз съм се чудил преди време- 741 това което казваш за RTS че е изход а CTS-а вход съм съгласен, поне тако и аз го бях прочел в теорията. Но въпросният терминал с който работя, използва RTS-а като вход. Защо, не бих могъл да ти кажа понеже аз не съм писал неговият скрипт и поведение. Но от страна моят дивайс, като стигна до частта в която да го вържа с устройството с което ще си работи напрактика, знам как лесно да оправя този проблем. Иначе терминалът използва такива ЛОК текстови файлове в който проверявам дали имам загуби. На панелът изобщо неразчитам, понеже там данните доста бързо се трасират, и поне аз немога да хвана загубата. Освен това знам чек сумата на данните които пращам и изчиславам същата такава на приетите данни във въпросният ЛОК файл.
Както каза и Wise - "ама софтуерно не работи като хората", така че въпросният терминал върши работа, но може още какво да се иска .

RTS на компа е физически/хардуерен изход.
Няма как да се ползва като вход.
Темата става все по-объркана. Хардуерен флоу контрол е безсмислен, ако губиш байтове.


Какво искаш да направиш? За какво са ти тези терминали ?
Ако по някакви причини не ти се отговаря на тези въпроси, почни да задаваш по-конкретни въпроси.
9600 бода трябва да е достатъчно за всяка система, както би казал Бил Гейтс .

ко?
гаечни ключове ще ти трябват ли? или руски уред за измерване на хармонични изкривявания?

нещо ти е голяма мъгла в главата май.
не знаеш нито за къде си тръгнал, нито от къде идеш. питаш за пътя, ама и това го правиш на някакъв неразбираем диалект и половинчато.

кажи:
имам от една страна win/XP, от другата страна PIC12 на 4MHz.
в РС-то ползвам хипер терминал, пути или квото е там, в ПИК-а съм си писал софта сам на голо канче, без прекъсвания и таймери.
губя байтове в еди-каква-си ситуация (последователност, дължина на фрейма, отдалеченост от синхронизацията)
работя на 9600 8N2, какви буфери си сложил и дали всичко е ОК при тях (захранванията пулсират ли)
ако е по ТТЛ - на какви нива5V, 3.3, 2.5, 1.
жицата ми е ВКШ, 2км, навита на военна макара.

e, може и да драснеш едно GUI, щом те влече - няма да помогне. после пробвай на РНР, питон или луа. пак няма нищо да стане.

Абе хора вие сте голяма работа , гаечни ключове и военни макари ти да не работиш в някакъв концентрационнен лагер или си израстнал в такъв. Щом мислиш че говоря неразбираемо, помогни това да стане разбираемо. Ако проследиш внимателно какво съм казвал, според твоят коментар само дето не съм добавил контролерът с който работя - Кортекс М4. Ако те интересуват нивата, споменал съм за един МАХ на предната страница ... Разчитам на хората които имат културата и уважението да отговарят на въпроси, на хора които имат желанието и нагласата да се научат, какъвто съм аз самият.
stefan63 задачката ми е проста трябва да предавам от ТСР към RS и обратно. Нещата съм ги направил, но естествено не на 100%. От RS към ТСР работи комуникацията. Обратно обаче стои проблемът който описвам тук. От RS към ТСР съм пуснал трансферът с въпросният контрол, и с негова помощ мога да казвам на предаващият (ПС-то) кога да спре и кога да продължи с пращането на данни. В обратният случай обаче (когато моят диваис почне да предава, най-грубо казано) този който приема (ПС-то) не ми указва кога да спра и кога да продължа. Причината да използвам този контрол е по препоръка на ....... аз съм изпълнител в случаят. Просто идеята на въпросната препоръка е с този контрол, допърнително да се спомогне за това при комуникацията да не се губят данни. Нещата съм ги пробвал и на 9600, ката работи и в двете посоки, но оптималната скорост която ще се ползва е 115200. А и още нещо незнам какво е точно обърканото, терминал - имам предвид GUI-то което ползвам -wTerm. Има хора по-горе които дадоха отговори които и очаквах, ако ми кажеш какво е объркващото, ще се опитам да го разясня, поне за хората които идват след мен тук във форумът и надявам се темата да им е полезна.

Объркващото е, че според теб РС-то изкарва сигнал на CTS, а очаква да му казваш кога да предава на RTS. Няма значение какво ти твърди терминалът, или какво си мислиш, че твърди. Посоките на тези сигнали са физически заковани и не могат да се обръщат. CTS е вход, RTS е изход. Ако очакваш друго и си навързал жиците като за другото, естествено RTS/CTS flow control няма да ти работи.

Сложи 2 стопбита,
провери с осцилоскоп захранването и помпите на MAX-а и линиите при предаване - тоя MAX му дават 250 кбс при една активна линия - при 2 линии може и 115 да му е много.
RTS/CTS е излишен на този етап - не ти е там проблемът.

Колега, защо не покажеш как си свързал двете устройства (pc-то и другото) и как протича комуникацията между тях ? На 115k на съвременен компютър да има някакви загуби - нещо много е объркано. Тоя wTerm какво е ? Сигурно ли е, че се държи както трябва ? Историята познава случаи, когато от даден софтуер се очаква едно, а той прави нещо съвсем друго .

Що за глупости се изписаха тука? Хардуерен флоу контрол си има по дефоулт заложен в бозата и си работи. Стандартните АПИ та на бозата си имат интерфейс за управлението му. Хипер терминала на ХП-то си го подържа без ядове, а на 7+ не съм пробвал, щото машините със сериен порт вече са рядкост.

В добавка - на 115200 сериен порт на нормално ПЦ не можеш да му докараш задръстване, та да трябва и флоу контрол.

И на 7-ца си работи безпроблемно флоу контрола. Само дето самия хипертерминал го изхвърлиха от 7-цата, та го копирам от ХР-то.

Аз друго се чудя, дали терминалите пропускат всичко или орязват някои от контролните символи. За екрана е ясно, въпросът е в лог файла какво вкарват. Непрекъснато ги ползвам, ама винаги за текст. Не ми е минавало през ума да прекарвам binary през терминал без x- или z-modem протокол, а човекът май точно това опитва да прави.

Няма проблем да му пуснеш binary data. Ако имаш някаква емулация - ansi, vt100 и т.н. става интересно, иначе в dumb mode показва всичко, или почти всичко . В hex mode е най-добре.

Ще ви изпратя файлът които изпращам и резултатът от това което получавам. File1.txt е този който го пускам LAN-a, устройството ми приема данните от отделните TCP пакети и ги пуска по RS-а. И в двата случая и при приемане и при изпращане работя с unsigned char буфери с големина по 1024 байта. След като ми свърши трансферът, получените данни погат да се видят в File2.txt. Ако се разходите по този файл ще видите че някои от редовете не са със същата дължина както останалите. Всеки един от тези редове е с по 1024 байта (ASCII). x- и z-modem протоколите не съм ги разглеждал и незнам за какво иде реч там. Неизползвам никакви емулатори . Може да прозвучи глупаво но накраят на тестът проверявам дали редовете са продравнени и след това изчислявам чек сумата с HxD, за да видя дали не са се разместили байтове или нещо друго не се е омазало.
wTerm го ползвам наготово, незнам кой го е писал ,но като ми го връчиха казаха че поддържа флоу контрол и покозаха как се активира. От там насетне тествам, наблюдавам и според поведението му (имам предвид на CTS/RTS линните) имплементирам в моят дивайс.
Това което казва stefan63, е интересно за МАК-са, ако линиите са повече от 2 да неможе да се пребори със скоростта...
Абе то работите са остаряли - RS с флоу контрол - едно време в модемите се е ползвало ...... но трябва да ги добутам нещата някак .

От двата файла се вижда ,че първите 500 байта се приемат коректно.
Няма неразбираеми символи.
Нямаш пропуснати байтове.

Имаш някакво омешване на указатели и буфери. Дали в компа или в твоето у-во тепърва ще разбереш.