2-Tумблер-&PowerF1&Lukomor
Проблем с разными потоками под XP не испытывал.
Отрываю от сердца самописный пример под ц++дебилдер 6.0
Он, по моему, работал на всем, что только можно.
В одном потоке нон-стопом льет данные в коматоз, в другом потоке из этого же кома принимает. Софтина задумывалась как тестер канала связи. Динамически снижает скорость при появлении ошибок.
Для проверки замкнуть пины RX и TX.
Глючит при закрытии, если не приняла ни одного байта.
Кто будет запускать exe - проверте на вирусы, я антивирусами не пользуюсь.
Исходники предоставляю для ознакомления, просьба ими не раскидываться.


о п с .... старая версия только есть. завтра с работы нормальную принесу.

По грубой оценке около 30-40 ms.

2_VM

Спасибо за совет, обязательно попробую, но чувствую придется мне писать драйвер.
Пин вроде тот - проверял в W98 - передача идет.

2All
Никто случайно не знает, где в сети можно найти информацию по написанию драйверов на простеньком уровне? Потому как дело это для меня совсем новое.

Если владеешь C++ поищи Numega Driver Studio (софт коммерческий). Она с документацией идет. Для твоей задачи ненадо глубоко вникать в архитектуру виндов, а нумега ее внутри своих C++ классов скрывает. В общем я с нее начинал и доволен.

Но я бы на винапи еще подолбился бы. С драйвером конечно интереснее и надежнее, но разобраться не быстро получится.

Привет.
Может быть мой ответ устарел
Попробуй проверить свою программу так.

Соедени Com порты(Com1 , Com2) своей персоналки через нуль - модемный кабель.
Распайка
2-3
3-2
5-5
6 6
| |
4 4
7 7
| |
8 8
Запусти гипертерминал для Com2 в Win2000 и поставь настройки Com2
такие как в твоей программе для опроса контроллера.
Запусти свою программу для Com1 попробуй опросить контроллер.
Если программа что то кидает на Com1 то ты увидишь это в гипертерминале,
т.е. ты убедишься что у тебя программа что то посылает.


Так же я тебе могу предложить библиотеку программирования для COm
портов, если ты ее используешь то в программировании много знать не надо
она работает и под win2000 и под win98 (С ,VC, BC, VB)
ее можно скачать на www.webfile.ru
Файл номер 240397, pcommpro20.rar (размер 652 кбайт)




Пример:
int port = 2;

//настроить COM2 38400 8 бит данных 1 стоповый
ret = sio_ioctl ( 2, B38400, P_NONE | BIT_8 | STOP_1 );

if (ret != SIO_OK) {
/* Setting fail */
}


Нужно еще DTR поднять посмотри функцию в хелпе

ret = sio_open (port); //Открыть COM2
if ( ret != SIO_OK ) {
/* Open fail */
}
int len;
char buf[10];
len = sio_read( 2, buf, 10); //прочитать 10 байт с COM2
if (ch < 0) {
/* Fail */
}

Сегодня я ноконец померил - и вот что получилось:

При работе с одним потоком на прием и передачу - ~6 ms на ответ.
Если поток имеет приоритет NORMAL действительно, его прерывают
и иногда выходит ~30ms. Хотя и редко, это бывает.
Если поставить приоритет этому потоку Тайм_Критикал, то ему
никто особенно не мешает. Кроме ~6ms других значений времени
не зафиксировано.
Система была WIN98, PII-300, VC6+API ONLY.
Ничего особенно навороченного..
В качестве темплате использовалось готовое приложение
с двумя потоками - основной Нормал+2 и еще рабочий Нормал.
Под WIN-XP измерять буду завтра...

Так вышло, что измерил сейчас.
Получилось то же самое ~6ms на ответ.
Все то же самое.

Вполне вероятно, можно обойтись без драйверов
и лазания в порты.

2-Тумблер-
Спасибо, я действительно поигрался с приоритетами и потоками, вроде получилось, но проблема была в другом, "поймать" ответ устройства. Ответ приходит через ~11 мкс после запроса, при этом обмен идет через интерфесный девайс. От компьютера до девайса RS232 с управлением RTS, от девайса до устройства 485 интерфейс без управления потоком. Мне надо успеть вручную переключить RTS. Для работы с портом выставляю REALTIME_PRIORITY_CLASS и THREAD_PRIORITY_TIME_CRITICAL. С натягом, но все успеваю.

Извините, если скажу общеизвестное.
Приоритет потока - вешь относительная.
Если посмотреть каким-либо процесс вьювером,
можно обнаружить, что абсолютный приоритет
потоков "обычного" приложения не может превысить ~15.
У Кернела - вдвое больше.
Так что резервы еще есть.
Можно попытаться увеличить приоритет процесса.
Тогда "THREAD_PRIORITY_TIME_CRITICAL" станет еще выше..

Так REALTIME_PRIORITY_CLASS это вроде и есть приоритет процесса
Скажу больше - для приоритета есть еще и динамический диапазон определяемый относительно базового.
Правда для такого REALTIME приоритета процесса, поток все равно получился 15. Не знаю почему. Глубоко не ковырялся.

И я тоже не рад этой особенности XP.
Еще раз подтверждаю (опять "влетел") - дело не в разных
потоках. Если в программе возможно обращение к порту
ОДНОВРЕМЕННОЕ из разых потоков, под XP аппликэйшн зависнет насмерть.
А для WIN98 нет проблем.
Это касается всех функций использующих idComDev
( где idComDev это : HANDLE idComDev = ::CreateFile.......)

В том числе и
::GetCommModemStatus
::GetCommMask
::EscapeCommFunction
::SetCommState(idComDev, &dcb)..
И видимо вообще для всех.

В случае применения синхронизации для использования этих
функций из разных потоков никаких проблем не обнаружено.

[/quote]

Так REALTIME_PRIORITY_CLASS это вроде и есть приоритет процесса
Скажу больше - для приоритета есть еще и динамический диапазон определяемый относительно базового.
Правда для такого REALTIME приоритета процесса, поток все равно получился 15. Не знаю почему. Глубоко не ковырялся.

[/quote]

Обратимся к книге Джеффри Рихтера "Windows Создание эфективных win-32 приложений".
" -Концепция класса приоритета вводит некоторых в заблуждение. Они делают отсюда вывод, будто процессы учавствуют в распределении процессорного времени. Так вот, процессы никогда не получают прцессорное время - оно выделяется лишь потокам. Класс приоритета процесса - сугубо абстрактная концепция, введенная Microsoft с единственной целью: скрыть от разработчика внутреннее устройство планировщика".

Приоритет потока всегда относителен к классу приоритета его процесса. Изменение приоритета процесса не влияет на относительный приоритет потока, но сказывается на их уровне приоритета в системе.

Клас приоритета потока
Относительный приоритет Idle Bellow Normal Above High Real-time
потока Normal Normal

Time-Critical 15 15 15 15 15 31
Highest 6 8 10 12 15 26
Above Normal 5 7 9 11 14 25
Normal 4 6 8 10 13 24
Bellow Normal 3 5 7 9 12 23
Lowest 2 4 6 8 11 22
Idle 1 1 1 1 1 16

Уровень 0 зарезервирован. Кроме того, уровни 17-21 и 27-30 в обычном приложении тоже не доступны.Вы можете пользоваться ими, только если пишите драйвер устройства, работающего в режиме ядра. И еще одно: уровень приоритета потока в процессе с классом real time не может опускаться ниже 16. а потока с любым другим классом поднималься выше 15.

И еше :
1. Планировщик не документирован полностью
2 Microsoft не разрешает в полной мере использовать особенности планировщика
3. Microsoft предупреждает, что алгоритмп ланировщика постоянно меняется, и не рекомендует писать программы в расчете на текущий алгоритм.

Вот так обстаят дела

2yuriyc:
Спасибо за информацию. Я пользовался в основном "Windows 98. Руководство разработчика. Бен Эззель, Джим Блейни". Правда _измеренный_ приоритет потока THREAD_PRIORITY_TIME_CRITICAL в REALTIME_PRIORITY_CLASS не поднимался выше 15. Но я проверил опытным путем. Запустил бесконечный цикл с этим приоритетом, в результате повесилась даже мышка .

2all:
Кто нибудь знает, каким образом можно точно переключить RTS после передачи слова? Автоматический вариант не подходит Происходит или большая задержка между концом слова и переключением или RTS переключается раньше.

[/quote]

2all:
Кто нибудь знает, каким образом можно точно переключить RTS после передачи слова? Автоматический вариант не подходит Происходит или большая задержка между концом слова и переключением или RTS переключается раньше.

[/quote]

Как вариант: можно отследить событие/прерывание возникающее по окончанию передачи байта. И ручками выставить RTS.

Мне кажется из под Win управлять RTS дело безнадежное.
Вы видимо подключаетесь к RS485 и вам понадобится
преобразователь интерфейса.
Обычно он автоматом управляет активностью
передатчика ориентируясь на заданную для него скорость.
Работает как одновибратор на время передоваемого
слова, стартует от стартового бита.
RTS от PC при этом не используется.

Отлов прерываний WIN32? Это если только на уровне драйвера. Других способов не знаю.
Событие - возврат из функции записи в порт. При этом если сразу выставить RTS, а потом посмотреть на осциллограф то получится что RTS выставляется в СЕРЕДИНЕ передаваемого слова, то есть надо вводить программную задержку, при этом она (задержка) должна определяться для каждой машины отдельно.
RTS выставляю EscapeCommFunction(...).

2vm1:
Вы правы, но к сожалению преобразователь интерфейса уже есть и изменить его нельзя, поэтому управлять RTS могу только с машины. Причем добавлять какое-либо оборудование тоже нельзя - все задокументировано и согласовано

а есть возможность передавайть последний байт транзакции
тогда когда вы достоверно контролируете
возможную задержку по снятию RTS?

Вот примерчик для Borland C++ Builder из моей тестовой программки. hCOM, dcb, и sTO обьявлены глобально ( HANDLE hCOM, DCB dcb, COMMTIMEOUTS sTO), в классе MainForm, cbBaudRate - комбо-бокс на главной форме с выбором скорости обмена.

int __fastcall TMainForm::InitComm(int portno)
/////////////////////////////////////////////////////////////////////////////
//
// Инициализация COM-порта с номером portno. Если инициализация прошла
// успешно, то функция возвращает 0, в противном случае один из следующих
// кодов:
// -1 не удалось получить доступ к COM-порту
// -2 не удалось получить доступ к блоку dcb
// -3 не удалость перенастроить порт
// -4 ошибка при настройке тайм-аутов
//
/////////////////////////////////////////////////////////////////////////////
{
char portname[8];
int result;
DWORD val;

sprintf(portname,"COM%d",portno); //

hCOM = CreateFile(
portname, //
GENERIC_READ|GENERIC_WRITE, // Пробуем получить доступ
0, // к COM-порту
NULL, //
OPEN_EXISTING, //
FILE_ATTRIBUTE_NORMAL, //
NULL //
);

if( hCOM != INVALID_HANDLE_VALUE )
{//*1*-----------------------------------------------------------------
// Настройка параметров порта
//--------------------------------------------------------------------
if( GetCommState(hCOM,&dcb) )
{//*2*
switch( cbBaudRate->ItemIndex )
{
case 0: {
dcb.BaudRate=CBR_4800;
break;
}
case 1: {
dcb.BaudRate=CBR_9600;
break;
}
case 2: {
dcb.BaudRate=CBR_19200;
break;
}
case 3: {
dcb.BaudRate=CBR_38400;
break;
}
case 4: {
dcb.BaudRate=CBR_57600;
break;
}
case 5: {
dcb.BaudRate=CBR_115200;
break;
}
default: dcb.BaudRate=CBR_9600;
}// end of switch (cbxBaudRate)

dcb.ByteSize = 8; // в байте 8 битов
dcb.fBinary = True; // альтернативы как бы нет

dcb.fNull = False; //

dcb.fOutxCtsFlow = False; // disable TS output flow control
dcb.fOutxDsrFlow = False; // disable DSR output flow control
dcb.fErrorChar = False; // disable error replacement

dcb.fAbortOnError = True; // abort reads/writes on error

dcb.fDtrControl = DTR_CONTROL_DISABLE; // DTR flow control disable
dcb.fRtsControl = RTS_CONTROL_DISABLE; // RTS flow control
dcb.fDsrSensitivity = False; // DSR sensitivity disable

dcb.fOutX = False; // disable XON/XOFF out flow control
dcb.fInX = False; // disable XON/XOFF in flow control

dcb.XonLim = 256; // transmit XON threshold
dcb.XoffLim = 2048; // transmit XOFF threshold

dcb.XonChar = 0x7F; // Tx and Rx XON character
dcb.XoffChar = 0x7F; // Tx and Rx XOFF character

dcb.EvtChar = 0x02; // received event character
dcb.ErrorChar = 0x00; // error replacement character
dcb.EofChar = 0x03; // end of input character

dcb.fTXContinueOnXoff = False; // XOFF continues Tx (????)

if( !SetCommState(hCOM, &dcb) )
{
CloseHandle(hCOM);
hCOM = INVALID_HANDLE_VALUE;
return( -3);
}
}
else
{
CloseHandle(hCOM);
hCOM = INVALID_HANDLE_VALUE;
return( -2);
}//*2*

}//*1*
else return( -1);


//---------------------------------------------------------------------
// Настройка тайм-аутов
//---------------------------------------------------------------------

if( GetCommTimeouts(hCOM, &sTO) )
{
sTO.ReadTotalTimeoutConstant = 250;
sTO.ReadTotalTimeoutMultiplier = 3;
sTO.ReadIntervalTimeout = 2;
sTO.WriteTotalTimeoutConstant = 100;
sTO.WriteTotalTimeoutMultiplier = 5;

if( !SetCommTimeouts( hCOM, &sTO ) ) {
CloseHandle( hCOM );
hCOM = INVALID_HANDLE_VALUE;
return( -4);
}
}
else
{
CloseHandle(hCOM);
hCOM = INVALID_HANDLE_VALUE;
return( -4);
}

PurgeComm(hCOM,PURGE_TXABORT|PURGE_RXABORT|PURGE_TXCLEAR|PURGE_RXCLEAR);
ClearCommError(hCOM,&val,NULL);

return( 0 );
}//<<< End of InitComm() >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>


Ну а дальше через функции ReadFile и WriteFile.
1. Передача:

len = 5;
fSucs = WriteFile( hCOM, &txbuf[0], len, &len, NULL );

if( !fSucs )
{
Errors = CE_BREAK|CE_FRAME|CE_IOE|CE_MODE|CE_OVERRUN|CE_RXOVER|CE_RXPARITY|CE_TXFULL;
ClearCommError(hCOM, &Errors, NULL);
}

2. Прием:

len = 5;
fSucs = ReadFile( hCOM, &rxbuf[0], len, &len, NULL );

if( fSucs && (len==5) ) { принято } else { сбросить ошибки как при передаче}

Количество принятых байт проверять желательно, так как иногда функция возвращает вроде все ОК, хотя считано 0 байтов. Что это за глюк не разбирался.

По переключению RTS. Автоматический вариант проходит - сам когда-то писал утилитку для заливки в кассу базы товаров по 485 интерфейсу. Долго мучался, но в конце-концов разобрался - хитрость там какая-то с настройками com-порта, давно это было, попрбую найти в архивах примерчик.

Помогите плиз.
Взялся за курсовик.Для начала надо написать прогу для работы с мобилой через com порт.
Я в этом совсем не ничего не понимаю.Объясните новичку
Скиньте кто что может.Буду очень благодарен

Меня вот удивляет, зачем учиться, если ничего не понимаешь? Просто уже наприятно видеть на форуме сообщения типа "в электронике не шарю, но хочу сделать устройство на микроконтроллере". Сори за оффтоп.
По теме: в интернете, да и на этом форуме полно материала. Поиск спасет Вас.

Запоздало, но тем не менее..

Я делал так в Visual Studio 2005:
Инициализация:
SerialPort system_port;
system_port = new SerialPort();
system_port.PortName = "COM1";
system_port.BaudRate = 115200;
system_port.DtrEnable = true;
system_port.ReadBufferSize = 100000;
system_port.DataReceived += new SerialDataReceivedEventHandler(system_port_DataReceived);
system_port.Open();
system_port.DiscardOutBuffer();
system_port.DiscardInBuffer();
А далее по событию, которое вызывается, когда приходит байт в буфер COM-порта (объемом 100000 байт) пишете свою процедуру обработки принятых данных:
void system_port_DataReceived(object sender, SerialDataReceivedEventArgs e)
{
byte newbyte;
while (system_port.BytesToRead >=3) // К примеру, если пришло более трех байт
{
newbyte=(byte)system_port.ReadByte();
...... // Тут пишем свою часть обработки принятых данных
}
}
Передавать данные также просто: записываем в выходной буфер - и всё.
Вот пример передачи 7-байтного пакета с хэшем
data = new byte[7];
data[0] = 183;
data[1] = 5;
data[2] = 0xA0;
data[3] = 0x01;
data[4] = 0x01;
data[5] = 0x00;
data[6] = (byte)(data[1] ^ data[2] ^ data[3] ^ data[4]);
system_port.Write(data, 0, data.Length);
Всё общение использует только класс SerialPort. Преимущества такого решения в следующем:
1. Поддержка с Win98 (только dotNet 2.0 поставить надо) по WinXP и даже Vista.
2. Программа не занимает ресурсов ПК для постоянного опроса COM-порта. Пришел байт - сработало событие. Не пришел - можете выполнять любые другие действия.
3. Как следствие из пункта 2 программа может быть легко использована в многозадачном приложении.
4. Никаких драйверов писать не надо. Код максимально простой. Читаем MSDN как использовать SerialPort и всё.
5. Есть возможность устанавливать таймер на ожидание прихода данных, просто в данном примере он не использован.
Недостаток - Windows не операционная система реального времени, а поэтому НЕТ четкого временного интервала, в течение которого будет передан байт в линию из выходного буфера COM-порта. Но на практике, я общался со скоростью 115200 и реальной информационной ёмкостью 72000 как в сторону ПК, так и в сторону железа - проблем не было, хотя параллельно работал Emule.

Подскажите как cport310 прицепить к Borland

Судя по Вашей переписке - лето было боевое.
Есть очень простое решение COM - Delphi + компонент Async32.
http://www.tmssoftware.com/
http://www.tmssoftware.com/ta32.htm
Downloads Asynchronous serial communications made easy for your Delphi & C++Builder applications

Вообще не нужно знать. Задать нужную скорость (константа) - максимум усилий. Работает везде, есть рабочий пример, если ваш контроллер выдаёт символы - их сразу увидите. На Delphi (если не пробывали) писать намного удобней чем на С (мне так кажется).
Я правда из-за Async32 остался на Delphi 3 (кто-то ухмыльнётся), когда-то для более старших не получилось и руки не дошли, на сайте то есть, сейчас время жалко. Главное хочется уйти на USB, вот для этого нужен компонент.
К стати компонент Delphi 3 есть сам исходный текст - я раз заглянул и мне хватило навсегда. Понял мне в калашный ряд не стоит... Такие вещи будут жить и потом. Иногда приходиться иметь дело с самоделками, хороши до времени. Пример с Win XP.
С уважением
badik

Спасибо классный класс. Давно искал что-то подобное.

Да неплохой. Использовал под C++Builder что-бы не нарушать лицензионного соглашения.

в архиве cport310 есть файл readme.txt всё (правда по английски) написано

а если кратко, то так (на примере Delphi 7):
- открываем в Delphi файл cport-3.10\sources\CPortLib7.dpk
- в открывшемся окне "Package - CPortLib7.dpk" жмём кнопку "Compile"
- закрываем окно "Package - CPortLib7.dpk", но запрос "Сохранить" жмём "Нет"
- открываем в Delphi файл cport-3.10\sources\DsgnCPort7.dpk
- в открывшемся окне "Package - DsgnCPort7.dpk" жмём кнопку "Compile", потом "Install"
- закрываем окно "Package - DsgnCPort7.dpk", но запрос "Сохранить" жмём "Нет"
- проверяем на вкладке компонентов наличие вкладки "CPortLib"
- все файлы cport которые будет требовать компилятор копируем из cport-3.10\sources\ в C:\Program Files\Borland\Delphi7\Projects\Bpl\, как правило это *.dcu, *.dfm, *.pas, CPort.inc, CPortImg.res

вроде всё