Нужно получить доступ к порту RS-485 ( имеется на ПК в количесве 2 штук). Язык С++ (Си). Среда Builder C++. Передача пакетов малого объема 12-20 байт. Операционная система WndXP (желательно wnd7)
Имею доступ к портам ввода/вывода (думаю это плохой способ), поэтому пока о другом...
Гугл дал варианты через "файл" (CreateFile winapi). Но читая , понял , что есть проблемы, плохо освещенные RS-485 и т.п. в частности переключения потоков (полудуплекс, передал пакет нужно успеть принять ответ )
Если у кого есть материалы по этой теме/ готовые реализации/ тонкости, то приму с удовольствием. Мб особенности есть написания оконных приложений (отдельный поток )и т.п.
PS. Пока, что собираю материал и конкретных вопросов/ проблем не имею т.к. только с завтра начну.
Полная версия этой страницы: RS-485 С++
так посмотрите open source терминалы, вроде HTerm (не помню точно)
Коллега, мы же договаривались о цитировании...
Коллега, мы же договаривались о цитировании...
Цитата(go2winner @ Jun 29 2016, 19:55) 
Гугл дал варианты через "файл" (CreateFile winapi). Но читая , понял , что есть проблемы, плохо освещенные RS-485 и т.п. в частности переключения потоков (полудуплекс, передал пакет нужно успеть принять ответ )
Файловые функции WinAPI + "Serial Communications Functions" (MSDN) из того же WinAPI дают все возможности работы с UART.
Управление направлением передачи для RS-485 - зависит от вашего контроллера RS-485 какие методы он предоставляет. Обычно конверторы RS-232 - RS-485 умеют прозрачно управлять направлением передачи, без дополнительных сигналов управления (есть данные на RS-232.TX - включают передачу, данные закончились - приём).
Если работаете под WinXP в прямом доступе к портам нет необходимости.
Тем более, что виндузный драйвер все это делает прекрасно - вопрос только в освоении его управлением
и своей прикладной "навеске".
Вырезка из утилиты которую я пользую (дежурный прием пакетов, отсечка пакетов - по таймаутам драйвера и/или по кол-ву принятых байт)
Там поминаются функции Win32API.
Дуплекс реализуется как выделение, например, приема в отдельный поток выполнения и сихнронизацией по семафору с управляющим потоком.
Консольная main()
Тем более, что виндузный драйвер все это делает прекрасно - вопрос только в освоении его управлением
и своей прикладной "навеске".
Вырезка из утилиты которую я пользую (дежурный прием пакетов, отсечка пакетов - по таймаутам драйвера и/или по кол-ву принятых байт)
Там поминаются функции Win32API.
Дуплекс реализуется как выделение, например, приема в отдельный поток выполнения и сихнронизацией по семафору с управляющим потоком.
Консольная main()
Код
HANDLE hport;
DCB dcb1;
main()
{
. . . .
hport = CreateFile( s_port, GENERIC_READ | GENERIC_WRITE,0,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,0);
if(hport == INVALID_HANDLE_VALUE) printf( "\nCOM_R hport WAS NOT OPEN !\n" );
. . . .
// --- DCB init ----
dcb1.BaudRate= CBR_9600;
dcb1.ByteSize=8;
. . . .
. . . .
succ=SetCommState(hport,&dcb1);
// ------------------------------
COMMTIMEOUTS CommTimeOutsW;
GetCommTimeouts(hport, &CommTimeOutsW);
. . . .
CommTimeOutsW.ReadIntervalTimeout = t_RITT;
CommTimeOutsW.ReadTotalTimeoutMultiplier = t_RTTM;
CommTimeOutsW.ReadTotalTimeoutConstant = t_RTTC;
// ----
SetCommTimeouts(hport, &CommTimeOutsW);
succ=SetCommState(hport,&dcb1);
. . . .
PurgeComm(hport, PURGE_TXCLEAR | PURGE_RXCLEAR );
EscapeCommFunction(hport, SETRTS);
EscapeCommFunction(hport, SETDTR);
. . . . .
while( !kbhit() )
{ real_read = 0x00;
ReadFile(hport,&RxR_bf[0],50,&real_read,NULL);
if(real_read > 0)
{
} // if read > 0
else
{
printf("*");
}
real_write = 0x00;
} // while
PurgeComm(hport, PURGE_TXCLEAR | PURGE_RXCLEAR );
CloseHandle(hport);
return 0;
}
DCB dcb1;
main()
{
. . . .
hport = CreateFile( s_port, GENERIC_READ | GENERIC_WRITE,0,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,0);
if(hport == INVALID_HANDLE_VALUE) printf( "\nCOM_R hport WAS NOT OPEN !\n" );
. . . .
// --- DCB init ----
dcb1.BaudRate= CBR_9600;
dcb1.ByteSize=8;
. . . .
. . . .
succ=SetCommState(hport,&dcb1);
// ------------------------------
COMMTIMEOUTS CommTimeOutsW;
GetCommTimeouts(hport, &CommTimeOutsW);
. . . .
CommTimeOutsW.ReadIntervalTimeout = t_RITT;
CommTimeOutsW.ReadTotalTimeoutMultiplier = t_RTTM;
CommTimeOutsW.ReadTotalTimeoutConstant = t_RTTC;
// ----
SetCommTimeouts(hport, &CommTimeOutsW);
succ=SetCommState(hport,&dcb1);
. . . .
PurgeComm(hport, PURGE_TXCLEAR | PURGE_RXCLEAR );
EscapeCommFunction(hport, SETRTS);
EscapeCommFunction(hport, SETDTR);
. . . . .
while( !kbhit() )
{ real_read = 0x00;
ReadFile(hport,&RxR_bf[0],50,&real_read,NULL);
if(real_read > 0)
{
} // if read > 0
else
{
printf("*");
}
real_write = 0x00;
} // while
PurgeComm(hport, PURGE_TXCLEAR | PURGE_RXCLEAR );
CloseHandle(hport);
return 0;
}
Когда я начинал пользовать C++Builder (кажись, в прошлом веке еще), коллеги порекомендовали не пользоваться втроенными средствами общения с сериальными портами, а пользоваться внешним пакетом- "Async Professional from TurboPower Software Company". Оно имеет очень много разных подпорок, делающих работу с портами простой- от простых отправлений-приемов до готовых терминалок, которые легко встроить в свою программу.
Не разочаровался и использую до сих пор (у меня старинная версия 3.05). Винды меняются, а оно все работает и работает.
Много воды утекло, этот Async Professional уже вроде давно фриварным стал.
вот тут оно вроде бы теперь обитает, и, кажется, я на местном загашнике старую версию выкладывал, еще коммерческую.
А, был вроде глюк с его винсокетом (это ApdWinsockPort надстройка компонента), когда витруальные сериал порты через интернет по его UDP прокидывал и с другой стороны стандартный модем с UDP портом висел- пришлось пакет Indy ставить для корректной работы с TCP/UDP.
Но это другие компоненты пакета. Простой ApdComPort и все что через него - работает отлично.
И да, в основном для RS-485 использую- железо и и с RTS сигналом, и с автоопределением направления передачи.
Не разочаровался и использую до сих пор (у меня старинная версия 3.05). Винды меняются, а оно все работает и работает.
Много воды утекло, этот Async Professional уже вроде давно фриварным стал.
вот тут оно вроде бы теперь обитает, и, кажется, я на местном загашнике старую версию выкладывал, еще коммерческую.
А, был вроде глюк с его винсокетом (это ApdWinsockPort надстройка компонента), когда витруальные сериал порты через интернет по его UDP прокидывал и с другой стороны стандартный модем с UDP портом висел- пришлось пакет Indy ставить для корректной работы с TCP/UDP.
Но это другие компоненты пакета. Простой ApdComPort и все что через него - работает отлично.
И да, в основном для RS-485 использую- железо и и с RTS сигналом, и с автоопределением направления передачи.
Цитата(Ruslan1 @ Jul 1 2016, 11:10)
Когда я начинал пользовать C++Builder (кажись, в прошлом веке еще).
Аналогично дело было, но сейчас нет никакого смысла НАЧИНАТЬ работать с проприетарным софтом.Qt + boost::asio::serial_port - наше всё!
Я это на полном серьёзе...
Когда среда разработки (C++Builder 6) падает сама - это не среда разработки .
Цитата(demiurg_spb @ Jul 1 2016, 23:52)
Аналогично дело было, но сейчас нет никакого смысла НАЧИНАТЬ работать с проприетарным софтом.
Qt + boost::asio::serial_port - наше всё!
Я это на полном серьёзе...
Когда среда разработки (C++Builder 6) падает сама - это не среда разработки .
Qt + boost::asio::serial_port - наше всё!
Я это на полном серьёзе...
Когда среда разработки (C++Builder 6) падает сама - это не среда разработки .
Да, согласен. Единственное "Но": лично у меня ощущение, что старый софт был лучше (насчет что "небо было голубее и трава зеленее"- не скажу, а вот софт был лучше). Но надеюсь что это временное явление, ну не могут же вечно корявое писать после хорошего.
Про 6-й билдер- я до сих пор на пятом билдере пишу (правильнее- пописываю, это дополнение к основной разработке- тесты и всякие мелкие поддержки). Не падал пятый билдер никогда, ни на 95-й винде давно, ни на семерке сейчас
Цитата(go2winner @ Jun 29 2016, 16:55)
Имею доступ к портам ввода/вывода (думаю это плохой способ), поэтому пока о другом...
Это самый лучший способ, но для wnd он драйверный.
Цитата(go2winner @ Jun 29 2016, 16:55)
PS. Пока, что собираю материал и конкретных вопросов/ проблем не имею т.к. только с завтра начну.
Кажется у klenа была потоко-событийная реализация компонента для ком. порта и, в отличие, от Async - на С++.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.