проблем с rs232+XP

Значи, имам едно устройство, което в непрекъснат режим праща данни по rs232. Приемника е едно PC с XP на него. Значи, програмата, която обработва данните, понякога работи, понякога не. Причината е, че след инициализацията на com-порта, данните, дето идват, нямат нищо общо с истината. След няколко експеримента установих, че причината по всяка вероятност е факта, че инициализацията се преебва по някакъв начин, ако по време на извършването й на порта идват сигнали. Ако устройството почне да праща данните след инициализацията, то програмата работи винаги, т.е. данните са това, което трябва.
Не мога да си обясня защо така става.

Няма връзка между това, какво идва по порта и инициализацията.

И аз съм се сблъсквал със същият проблем, но така и не разбрах как да го разреша,
Пиши като разбере6 каква е причината

probval li si s drug windows (98 primerno) na sastia komputer?
probvai i da namalis bodreida ako moje.

razsinhronizacia moje da se poluci ako ustroistvoto prasta neprekasnato danni bez pauzi i to edin i sasti bait! togava RS_a moje da se sinhronizira pogresno.

inace i a sam vijdal podobna situacia!
prosto novite dana i novite windowsi vece nemogat da rabotat s COM portove kakto trebva.
veroiatno nikoi ne gi misli i testva! sled godina-dve veroiatno voobste nema da raboti!

пробвал ли си с друг win програмата при същите условия?

За сега не съм го пробвал под друга ОС, но не ми и трябва, целта е да работи под XP.
Иначе и това забелязах - колкото са по-еднообразни данните, толкова е по-голяма вероятността да се прецака инициализацията.
Това явление изглежда е бъг на М$. И явно ще се наложи workaround. Може да се работи със заявки за всеки пакет, но тогава пада скоростта. Може да се се използва сигнал за стартиране на потока, но тогава устройството няма да се знае кога да спре и да чака пак сигнала (ако е настъпило прекъсване на връзката, което е възможно, имайки предвид, че в бъдеще няма да има null-modem, ами IrDA). Най-читаво ми се струва пускането през равни интервали на keep-alive сигнали.
Някой да има някакви идеи по въпроса?

1. Да не се сбърква устройството? Ако са на хардваре протокол, и ПЦ не е готово в даден момент, устройството може да не знае на кой свят е.
2. На какъв порт го ползваш? Ако е някаква идиотска USB цом порт може да имаш големи, и случайни проблеми.
3. Ако имаш повечко порти направи си подслушвалка и подслушай сигнали, данни и т.н. и виж къде точно е проблема. Имам подобна конфигурация в работата и мога да ти свърша тази работа, ако те интересува.

много подвеждащо си дал заглавието - не бачка под ХР.
аз съм писал програми за ползващи портове под 98 и 2000, и не съм имал проблеми, пробвай под 98 или 2000, ако и там не става, проблема е в програмата ти.

Слушай пич, от това което си написал разбирам, че не си много в час с това с което си се захванал. И понеже молиш за съвет, моят съвет е да вземеш малко да попрочетеш по въпроса, ако мислиш да продължаваш да работиш по въпроса.
Аз мога да кажа само, че имам програма (писана на VB), която управлява разни други "устройства" (слагам го в кавички, защото става въпрос за големи машини) по null-modem. И чрез интернет успях да я разпространя много до различни точки на света. Но досега не съм имал почти никакви проблеми със инициализация, синхронизация, комуникация и т.н. Независимо от разнородността на устройствата и независимо от операционната система (от 95 до ХР).
Така, че според мен проблема ти е в това, че не можеш да синхронизираш устройството с компютъра. А за null-modem това е елементарно - използват се XOn и XOff. И всяко едно устройство, което комуникира по null-modem е задължено да се подчини на XOn и XOff, независимо какво е. И аз не съм виждал устройство което да не го прави. Е, ако устройството ти работи по null-modem и не използва XOn и XOff, значи е пълен боклук и не струва (да не казвам че не отговаря на световните норми). И по-добре го изхвърли.
Ако пък работи с XOn и XOff, значи проблема е в програмата ти. Така, че сядай да си я оправяш. Но както ти казах преди това вземи малко да попрочетеш.

Между другото понеже никъде не си споменал за XOn и XOff и предполагам че не си ги чул, и ще ти кажа само че това са кодове, който се използват за да укажат на устройството кога да подава данни и кога да спре да подава. А и не е лошо да ги използваш тези кодове преди да ти се е препълнил буфера, защото ще загубиш инфо в противен случай, но това е една друга тема, до която изглежда ти още не си достигнал.


Надявам се, че бях полезен!

Успех!

Бии, за да те уважават!

в някои случаи се ползват Xon/Xoff ама доста често се ползват и хардуерните протоколи.
А те позволяват DATA а и много по голямо бързодействие в сравнение с Xon/Xoff.
Имам предвид ембедед процесорите.
Нямаме разработка да ползва Xon/Xoff - или без протокол или хардваре протокол.
Има само една ситуация в която устройство превръща хардваре в Xon/Xoff.

Az ne razbiram ot programirane, oshte po malko ot operacionni sistemi, no imam niakolko predlojenia i vaprosi. Zashto ne probvash da prosledish status registera na UART-a. Siguren sam che triabva da ima podobni funkcii i/ili biblioteki. Imam predvid po-specialno overrun i framing error. Predpolagam che ne polzvash CTS i/ili RTS. Ako se poluchat razminavane v skorostite dosta chesto se sluchva da zahape stop bit na niakoi bit danni. Ne znam kakuv ti e protokola, no ako vremeto m/u otdelnite paketi e tvurde malko ima goliama veroiatnost da izturvesh dosta bytove Microsoft's OS malko biagat ot RTOS, a ako ne se luja FIFOto na UARTa e 16. Oshte poveche ako protokola niama markeri za nachalo i/ili krai na paket, i paketa ti e po-goliam ot 1 byte - niama kak da interpretirash ednoznachno informaciata.
Vaprosat mi e: kak se boravi s UARTa vuv C++ za NT based OS. Znam che OSa ne ti dava vazmojnost da pipash direktno po hardware-to. Kak stava obrushtenieto kum COMa ?

Хахаха, като чуя VB ми става ясно що за специалист си.

Искам да избягам от създаването на разни протоколи, контролни кодове и т.н. Щото и без това е бавно, та ще стане още по-бавно.

Значи, UART-а на микроконтролера няма буфер. Т.е. има, но е точно 1 байт. Ако не успееш да го изчетеш преди да е дошъл следващия - губиш. От страна на PC-то и Прозорците, COM-порта се отваря като файл и се използва почти като файл. Нямаш достъп до него на ниско ниво, освен ако не си напишеш драйвер (което не е моята цел).

Vapros na mikrokontroler :). Az dokolkoto razbrah stavashe duma za problem s PC-to ne s mikrokontrolera. Pri mikrokontrolera si polzvash prekusvaneto, i si butash na nisko nivo bez problem. Tam veroiatnostta da propusnesh data e po malka, spored men. No se seshtam za edna druga vazmojna prichina za problem - ako polzvash niakakvi konvertori po liniata.

С това, което си казал съм напълно съгласен.
Само, че човека е казал Null-modem. А null-modem е устройство, с което се комуникира по сериен порт чрез сигналите RxD, TxD, GND и се управлява софтуерно чрез XOn/XOff.

Това, че Вашата разработка е без протокол или с хардуерен протокол (RTS/CTS, DSR/DTR) не значи, че е null-modem. A точно null-modem-а ме подведе да напиша това за XOn/XOff.

Както и да е. Просто исках да кажа, че не е правилно вината веднага да се хвърли в ОС. Знам, че WinXP има доста бъгове, обаче пък WinXP съм го връзвал по сериен порт и съм сигурен, че работи. Е, верно имам някои съмнения за грешки при високи скорости, но все пак който иска да комуникира с висока скорост по разумно решение би било да избере USB например.

А между другото програмата ми също има възможност да работи и с хардуерни протоколи (RTS/CTS, DSR/DTR). Тествал съм я с хардуерен протокол на 256000 baud rate (е така заради спорта) като от едната страна беше много бърза машина а от другата бавна, и не мога да се оплача. Е верно на бавната машина буфера е много голям, защото при по-малки буфери се губи инфо. Но това е проблем на програмата, а не на операционната система и всичко си работеше. А програмата е писана на VB, което пък от своя страна означава, че на VC++ би трябвало да няма абсолютно никакъв проблем със синхроницация при високи скорости.

Бии, за да те уважават!

1. Аз не съм казал, че съм специалист
2. Също така не съм казал, че не мога да напиша програмата на VC++

Единственото нещо, което съм казал е, че ти не си чел достатъчно и не ставаш за тая работа с която си се захванал

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

Така, че по-добре знаещ и можещ и с работеща програма с над 200 потребители (па макар и писана на VB), отколкото "Велик" (по-точно бих казал "нещастник") и с неработеща програма.

Според мен има няколко вида програмисти
- такива, с много знания и възможности
- такива, които правят работещи програми (независимо от езика)
- такива, на който програмите им все не работят както трябва, защото или ОС му е крива, или езика не става, но никога проблема не е в тях, и това не им пречи да се присмиват на "нещастните VB програмисти", пък макар и с работещи програми
- такива, които имат много знания, но не са написали една свястна програма и не стават за програмисти
- такива, които си мислят, че са програмисти
- други

И да те попитам в конкретния случай ти към кои се причисляваш?

Бии, за да те уважават!

Браво. Горното ми хареса.

Хахаха null-modem не е устройство, а 3 жици. Ако за тебе 3 жици са устройство, тооо...
Леле, 32КБ/сек. са висока скорост за тебе?

Баси шута си честно, разсмиваш ме искрено. Правил ли си ТОЧНО ТОВА, което правя аз, та сега се правиш на отворен? Не вярвам да си сляп и би трябвало да си прочел по-горе, че хората, които са го правили са наблюдавали същото явление. Просто явно целта ти е да ни забавляш.