Работа с COM портом - C++

[СЦБист]

тогда WaitForSingleObject не работает.

мне это не грозит. у меня все работает.

а поточный вариант жрет проц на 50 процентов . вероятно из-за цикла.

[Мурик]

Sleep(1) в цикле и загрузка процессора минимальная.

[СЦБист]

Sleep(1) в цикле и загрузка процессора минимальная.

с какой целью ?

чем смущает не поточная версия ?

[Мурик]

с какой целью ?

жрет проц на 50 процентов . вероятно из-за цикла.

чем смущает не поточная версия

Ничем. Я только предложил простой способ избавится от загрузки процессора.

[СЦБист]

практика покажет. пока еще с МК не увязывал.

[Siarzhuk]

Sleep(1)

с какой целью ?

Время исполнения кода в цикле исчезающе меньше 1 миллисекунды - и если добавить в цикл этот вызов - большую часть времени поток будет проводить в sleep-е, выскакивая оттуда раз в миллисекунду, чтобы проверить "чой-то там на улице?". Да и процессор во время Sleep-а будет заниматься более полезными деяниями нежели тупо цикл маслать с частотой пару сотен миллионов оборотов в секунду.

50% загрузки? Это на двухядернике? На одноголовом он пожрал бы всё, кмк.

Солидарен в том, что городить +2 потока для обеспечения примитивного ввод-вывода - это дюже по богатому. Ибо потоки - это не только головная боль при обеспечении их синхронизации на этапе проектирования но и геморрой при поиске ошибок этой синхронизации опосля. Но окончательную версию поточно пациента увидеть тем не менее хотелось-бы.

[Myp3ik]

Так WaitForSingleObject как раз и усыпляет цикл и процесс потребляет 0% процессора. У меня даже при передаче загрузка процессора не превышала 1%

[Siarzhuk]

Так WaitForSingleObject как раз и усыпляет цикл

Совершенно верно, но если евент ручной и уже засигнален - циклу ведь и положено пролетать Wait-ы как пшёнке через дизентерийного пациента.

[Vano79]

Поточный вариант сильно жрет процессор.

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

if (btr >= 100)

Не очень красиво, читать нужно все, даже if (btr == 0), складывать в отдельный буфер, основным потоком приложения обрабатывать этот буфер. Для определения начала-конца пакета гуглите.

[СЦБист]

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

прежде чем писать для начала подумайте что пишите. никаких задержек в не поточном варианте нету.

сидите разбирайтесь.

[ Не очень красиво,.

делай как хочешь. ))))))


___________________

добавил еще один метод ClearCom() в класс

[СЦБист]

Все думаю как лучше посылать данные с МК. Произвольно или по запросу ПК ?

У меня с МК приходит 10 байтов информации. Когда в буфере приема >= 10 то эти

байты читаю и обрабатываю.

Но тут не понятно будут ли эти 10 байт те которые я жду.

В буфере же может быть к примеру не 10, а 13 байт.

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

На ум приходит следующее:

После каждого приема 10 байт буфер приема принудительно очищать

PurgeComm(COMport, PURGE_RXCLEAR); //Очистка буфера приема

Или вводить два проверочных байта в начале и в конце информационных байтов.

Для надежности конечный проверочный байт должен быть инверсией начального проверочного

байта.

Достоверность посылки следовательно проверяем по этим контрольным байтам.

+ тоже очищаем буфер.

[Siarzhuk]

Произвольно или по запросу ПК ?

Если данные бинарные и в них может появиться любой байт из диапазона 0х00 - 0хFF - используем poll режим хоста с чексуммой для самоуспокоения. Если формат ASCII либо какие-то значения байтов заведомо не появятся в полезном теле посылки - выбираем из них кого-либо на роль терминатора и можем организовать асинхронный поток. Можно конечно вставлять мэджиков в начала пакетов и прикрывать задницы последних чексуммами после чего пытаться синхронизироваться на лету зачатками AI - но это скорее для сокрытия деталей реализации протокола от [начинающих] снифферистов может быть полезно.

PS:Мы пользуемся обычным ASCII с CR в качестве терминатора. Устройство наглядно отлаживается в любой терминалке.

[СЦБист]

[
Если данные бинарные и в них может появиться любой байт из диапазона 0х00 - 0хFF - используем poll режим хостае.

ниче не понял )))) решил передавать данные по запросу.

пришлось слепить класс которые будет посылать запросы через равные промежутки времени.

это время взял с запасом. 500 мс. цикл опроса.

информационная часть содержит 80 обьектов контроля. следовательно 10 кадров.

скорость передачи 1200 бод. 10 кадров будут идти где-то 100 мс с учетом времени сбора посылки в МК.

Собственно класс.

Код: Выделить всё

class Request
{
	LARGE_INTEGER time;
	bool request;
public:
	Request()
	{
		SYSTEMTIME st;
		FILETIME ft;
		GetSystemTime(&st);
		SystemTimeToFileTime(&st,&ft);

		time.LowPart = ft.dwLowDateTime;
		time.HighPart = ft.dwHighDateTime;

		request = true;
		Queue_message.push(212);
	}
	bool Check_request() const {return request;}
	void Reset_request() {request = false;}
	void Time_out_request()
	{
		LARGE_INTEGER time;
		SYSTEMTIME st;
		FILETIME ft;
		GetSystemTime(&st);
		SystemTimeToFileTime(&st,&ft);

		time.LowPart = ft.dwLowDateTime;
		time.HighPart = ft.dwHighDateTime;

		if ((time.QuadPart - this->time.QuadPart) >= 5000000)
		{
			if (request)
			{
				MessageBox(NULL,_T("От микроконтроллера не получено ответа"),
				_T("Ошибка связи"), MB_OK | MB_ICONERROR);
				
				GetSystemTime(&st);
				SystemTimeToFileTime(&st,&ft);
				
				time.LowPart = ft.dwLowDateTime;
				time.HighPart = ft.dwHighDateTime;
			}
			else request = true;
			
			this->time = time;
			Queue_message.push(212);
		}
	}
};

[Мурик]

скорость передачи 1200 бод

Что так медленно? Не помешало бы увеличить скорость до 9600 или выше.

[СЦБист]

[q] Не помешало бы увеличить скорость до 9600 или выше.

Мне вполне хватает. Пробовал передавать информацию по медным проволокам с транса.

М-ду ПК и МК 3 проволоки. Расстояние м-ду ПК и МК 8 м. Вроде все норм.


на скорости 9600 большая погрешность 7%. я кварц не применяю.

Спойлер

110 567 110.035 0.0320102
300 207 300.481 0.160256
600 103 600.962 0.160256
1200 51 1201.92 0.160256
2400 25 2403.85 0.160256
4800 12 4807.69 0.160256
9600 6 8928.57 -6.99405

http://ideone.com/9yk0iS