| nethobo |
| Отправлено: 31.01.2004, 15:16 |
|
Не зарегистрирован
|
Необходимо организовать общение с устройством по rs-232. Опыта работы с внешними устройствами нет, по-этому прошу совета.
|
|
| Георгий |
| Отправлено: 02.02.2004, 01:41 |
|
Почетный железнодорожник
Группа: Модератор
Сообщений: 874
|
если устройство использует только 2 линии — приём и передача, то для работы надо установить режим программного управления потоком, если полноценно используются линии, то аппаратного. для других вариантов (когда линии используются не по прямому назначению) ничего сказать не могу.
в форуме тема работы с com портами (rs232) несколько раз обсуждалась.
резюмируя эти темы можно сказать следующее:
есть 2 способа: через компоненты и через Win32API
через Win32API работа с устройством идёт как с файлом — WriteFile & ReadFile. ОС выполняет буферизацию и чтение можно начинать позже, чем устройство начало запись данных в порт, и данные не будут потеряны.
поиск в архиве форума дал вот такие результаты:
| CODE |
_COMMTIMEOUTS ctmo;
DCB dcb;
COMMCONFIG cc;
cc.dwSize=sizeof (COMMCONFIG);
cc.wVersion=1;
cc.dwProviderSubType=PST_RS232;
cc.dwProviderOffset=0;
cc.dwProviderSize=0;
//ïî íåïîíÿòíûì ïðè÷èíàì ôóíêöèÿ BuildCommDCB íå çàïîëíÿåò ÂÑÅ ïîëÿ
//ñòðóêòóðû îïèñàíèÿ êîíòåêñòà óñòðîéñòâà òàê ÷òî çàïîëíÿåì èõ
//ñâîèìè ðóêàìè (êîïèÿ òîãî, ÷òî óñòàíàâëèâàåò CommConfigDialog)
dcb.DCBlength=28;
dcb.BaudRate=38400;
dcb.fBinary=1;
dcb.fParity=1;
dcb.fOutxCtsFlow=0;
dcb.fOutxDsrFlow=0;
dcb.fDtrControl=1;
dcb.fDsrSensitivity=0;
dcb.fTXContinueOnXoff=0;
dcb.fOutX=0;
dcb.fInX=0;
dcb.fErrorChar=0;
dcb.fNull=0;
dcb.fRtsControl=0;
dcb.fAbortOnError=0;
//dcb.wReserved;//ýòî ïîëå ïî íåïîíÿòíûì ïðè÷èíàì íå íàõîäèò êîìïèëÿòîð
*(&dcb.BaudRate+2)=0;//ïðèõîäèòñÿ îáíóëÿòü òàêèì îáðàçîì
dcb.XonLim=2048;
dcb.XoffLim=512;
dcb.ByteSize=8;
dcb.Parity=0;
dcb.StopBits=2;
dcb.XonChar=17;
dcb.XoffChar=19;
dcb.ErrorChar=0;
dcb.EofChar=0;
dcb.EvtChar=0;
if (hCom!=INVALID_HANDLE_VALUE) CloseHandle(this->hCom);
this->hCom=CreateFile(
ComName.c_str(),
GENERIC_READ|GENERIC_WRITE,
0,
0,
OPEN_EXISTING,
0,
0);
if (!BuildCommDCB(CfgString.c_str(),&dcb))
ShowLastError();
if (!SetCommState(this->hCom,&dcb))
ShowLastError();
ctmo.ReadIntervalTimeout=0;
ctmo.ReadTotalTimeoutMultiplier=0;
ctmo.ReadTotalTimeoutConstant=d->GetInputTimeOut();
ctmo.WriteTotalTimeoutMultiplier=0;
ctmo.WriteTotalTimeoutConstant=d->GetOutputTimeOut();
SetCommTimeouts(hCom,&ctmo);
запись чтение:
PurgeComm(this->hCom,PURGE_TXCLEAR|PURGE_RXCLEAR);
WriteFile(hCom,this->OutPutBuffer,4+size+2,&nBytes,NULL);
ReadFile(hCom,this->InPutBuffer,4+size+2,&nBytes,NULL);
закрытие:
CloseHandle(hCom)
|
Отредактировано Георгий — 02/02/2004, 02:50 |
|
| nethobo |
| Отправлено: 02.02.2004, 16:23 |
|
Не зарегистрирован
|
| QUOTE |
если устройство использует только 2 линии — приём и передача, то для работы надо установить режим программного управления потоком, если полноценно используются линии, то аппаратного. для других вариантов (когда линии используются не по прямому назначению) ничего сказать не могу.
|
Прорамма будет иметь три состояния: прием, передача и состояние готовности(устройство имеет анологичные состояния). Я так понимаю, что это програмное управление потоком.
Есть ли какие-нибудь стандартные модули? |
|
| Георгий |
| Отправлено: 03.02.2004, 01:50 |
|
Почетный железнодорожник
Группа: Модератор
Сообщений: 874
|
эх, блин, на работе лежит Гук с Зубковым, а то бы сейчас расписал бы что такое програмное и аппаратное управление потоком.
ладно — попробую по памяти:
програмное — из 7ми линий последовательного порта используются только 2 — Tx и Rx, остальные либо никуда не подключены, либо замкнуты на своих соседей. данные передаются без приглашения — приёмник может быть не готов принять данные (например FIFO заполнено), но передатчик всёравно их передаст (и они благополучно потеряются). но у этого режима есть и плюсы — требуется всего 2 жилы (+1 — экран/по совместительству земля) что позволяет делать длинные мотки "интерфейсного кабеля" — 15м не проблема.
аппаратное — используется больше линий — кажется 6. Tx, Rx, вход готовность приёма, выход готовность к передаче ( +2 с другой стороны готовность приёма, передачи). когда передатчик хочет что то передать, то он ждёт появления сигнала готовность приёма у приёмника и по его появлении передаёт, что гарантирует отсутствие потерь из-за неожиданной передачи.
описание не претендует на точность, но, как надеюсь показывает отличия програмного управления потоком от аппаратного.
мною некоторое время назад испольовались Win32API для работы с портом — никаких проблем не было. Сейчас в форуме видел упоминание о компоненте TComPort, которым, судя по всему, успешно пользуются для работы с com портом.
Ни каких сложностей при работе с железкой, присоединённой к последовательному порту, нет, поэтому смело идите в бой, но не забудьте вооружиться описанием протокола железки. |
|
|
