Самопальный интерпретатор

[Serg]

Все кроме настройки режима с DTR RTS работает.

Вообще-то это несколько разные вещи. DTR/DSR это одно, а контроль потока это RTS/CTS.

вот полезно почитать: http://www.softelectro.ru/rs232.html

[sidor094]

Я пробовал процессором обнулять и DTR и RTS.Компьютер не прекращал передачу.Может не так инициализировал СОМ на компьютере

[Serg]

надо включить режим аппаратного контроля потока.
http://www.softelectro.ru/rs232.html#M17
В линуксе и прочих юниксах я знаю как это сделать, в венде - не знаю...

[sidor094]

Спасибо попробую разобраться.

[AndyBig]

Элементарно
Вот кусок кода:

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

	HANDLE	hcom = CreateFile("COM1:", GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ, NULL, OPEN_EXISTING, 0, NULL);
	if (hcom == INVALID_HANDLE_VALUE)
	{
		hcom = NULL;
		DWORD err = GetLastError();
		_stprintf(cerr, _T("Ошибка открытия %s - %d\r\n"), cvalue, err);
		MessageBox(NULL, cerr, updcapt, MB_OK);
		return 1002;
	}

	COMSTAT cst;
	BOOL res = ClearCommError(hcom, &rdd, &cst);
	DCB dcb;
	COMMTIMEOUTS cto;
	dcb.DCBlength = sizeof(DCB);
	res = GetCommState(hcom, &dcb);
	dcb.DCBlength = sizeof(DCB);
	dcb.BaudRate = 115200;
	dcb.ByteSize = 8;
	dcb.Parity = NOPARITY;
	dcb.StopBits = ONESTOPBIT;
	dcb.fBinary = 1;
	dcb.fParity = 0;
	dcb.fOutxCtsFlow = 0;
	dcb.fOutxDsrFlow = 0;
	dcb.fDtrControl = DTR_CONTROL_DISABLE;
	dcb.fDsrSensitivity = 0;
	dcb.fTXContinueOnXoff = 1;
	dcb.fOutX = 0;
	dcb.fInX = 0;
	dcb.fErrorChar = 0;
	dcb.fNull = 0;
	dcb.fRtsControl = 0;
	dcb.fAbortOnError = 0;

	res = SetCommState(hcom, &dcb);
	if (!res)
	{
		CloseHandle(hcom);
		hcom = NULL;
		throw (1004, 1);
		MessageBox(NULL, _T("Error DCB set\r\n"), updcapt, MB_OK);
		return 1004;
	}

[sidor094]

А где тут включение контроля за DTR RTS CTS DSR?

[Serg]

Похоже, что этого нет.
Есть какой-то намёк на софтверный контроль

dcb.fTXContinueOnXoff = 1;

но есть сомнения, что это будет правильно работать вместе с этим

dcb.fBinary = 1;

[sidor094]

Попробую.

[AndyBig]

А где тут включение контроля за DTR RTS CTS DSR?

Вот это не оно?

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

   dcb.fOutxCtsFlow = 0;
   dcb.fOutxDsrFlow = 0;
   dcb.fDtrControl = DTR_CONTROL_DISABLE;
   dcb.fDsrSensitivity = 0;
   dcb.fRtsControl = 0;

Из справки:

fOutxCtsFlow
If this member is TRUE, the CTS (clear-to-send) signal is monitored for output flow control. If this member is TRUE and CTS is turned off, output is suspended until CTS is sent again.

fOutxDsrFlow
If this member is TRUE, the DSR (data-set-ready) signal is monitored for output flow control. If this member is TRUE and DSR is turned off, output is suspended until DSR is sent again.

fDtrControl
The DTR (data-terminal-ready) flow control. This member can be one of the following values.

Value Meaning
DTR_CONTROL_DISABLE
0x00
Disables the DTR line when the device is opened and leaves it disabled.

DTR_CONTROL_ENABLE
0x01
Enables the DTR line when the device is opened and leaves it on.

DTR_CONTROL_HANDSHAKE
0x02
Enables DTR handshaking. If handshaking is enabled, it is an error for the application to adjust the line by using the EscapeCommFunction function.


fDsrSensitivity
If this member is TRUE, the communications driver is sensitive to the state of the DSR signal. The driver ignores any bytes received, unless the DSR modem input line is high.

fTXContinueOnXoff
If this member is TRUE, transmission continues after the input buffer has come within XoffLim bytes of being full and the driver has transmitted the XoffChar character to stop receiving bytes. If this member is FALSE, transmission does not continue until the input buffer is within XonLim bytes of being empty and the driver has transmitted the XonChar character to resume reception.

fOutX
Indicates whether XON/XOFF flow control is used during transmission. If this member is TRUE, transmission stops when the XoffChar character is received and starts again when the XonChar character is received.

fInX
Indicates whether XON/XOFF flow control is used during reception. If this member is TRUE, the XoffChar character is sent when the input buffer comes within XoffLim bytes of being full, and the XonChar character is sent when the input buffer comes within XonLim bytes of being empty.

но есть сомнения, что это будет правильно работать вместе с этим

Из той же справки:

fBinary
If this member is TRUE, binary mode is enabled. Windows does not support nonbinary mode transfers, so this member must be TRUE.

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

[Serg]

Из справки:

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

Из той же справки:

Ок, тут вроде всё нормально, если почитать описание параметра. Но напрашивается вопрос что курили программисты Microsoft, когда придумывали название этому параметру?..

[AndyBig]

Судя по этому описанию нет возможности заставить чип/драйвер порта самостоятельно заниматься контролем потока

А зачем? В основном цикле опрашивается входной буфер, новые данные оттуда копируются в свой буфер нужного размера, заодно по необходимости контролируется поток Буфер чипа или драйвера - это только промежуточный "перевалочный пункт"
А вообще я, например, никогда не пользовался аппаратным контролем, мне всегда было удобнее пользоваться протоколом с подтверждением каждого пакета - с проверкой CRC, длины и корректности данных и т.д. Если траффик настолько плотный, что интерфейс из-за него начинает подтормаживать, то обработка входящего траффика просто выносится в отдельный программный поток
Честно говоря, вообще не понимаю затруднений Сидора. "не хотел слишком усложнять протокол отвечая номером в буфере" - тут эта экономия, по-моему, не в тему, тут огромное значение имеет надежность, значит лучше перебздеть и подтверждать от приемника и номер пакета, и целостность данных в нем
UPD: "Не хотел использовать длинный буфер т.к компьютер должен показывать текущую команду" - тоже, по-моему мнению, не совсем правильный подход. Буфер должен обеспечивать работу станка на максимальное время затыка хоста, а не стремиться к максимально короткому промежутку между тем, что отправляется с компа и что выполняется в данный момент станком
Синхронизацию работы станка с отображением на компьютере можно добиться другими, более правильными способами

[Крафтер]

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

Я для этого шлю номер текущего исполняемого пакета, когда до него доходит очередь, и периодически шлю текущие координаты.

[Serg]

А зачем?

При правильной настройке этого режима и выделения буфера достаточного размера оно может нормально передавать данные через порт даже если ЦПУ перестанет реагировать на прерывания...
Никогда не замечали как во время попыток обращения к сбойным секторам HDD система вообще перестаёт на что-либо реагировать? Это особенности архитектуры платформы x86...

[Крафтер]

Переделал полностью расчёт ускорения, теперь при сопряжении линий не происходит торможения, если там нет излома и нет переключения режима G0 / G1. Осталось баги исправить.

[Крафтер]

Никогда не замечали как во время попыток обращения к сбойным секторам HDD система вообще перестаёт на что-либо реагировать? Это особенности архитектуры платформы x86...

Это общее падение уровня ПО, мелкософт уже не тот. Драйвер криво написан, вот и тупит.

[AndyBig]

Я для этого шлю номер текущего исполняемого пакета, когда до него доходит очередь, и периодически шлю текущие координаты.

Примерно такой способ мне и представлялся

При правильной настройке этого режима и выделения буфера достаточного размера оно может нормально передавать данные через порт даже если ЦПУ перестанет реагировать на прерывания...

Если ЦПУ перестанет реагировать на прерыывания, то никакой буфер уже не спасет

во время попыток обращения к сбойным секторам HDD система вообще перестаёт на что-либо реагировать? Это особенности архитектуры платформы x86...

Это особенности реализации драйверов

UPD: Кроме того COM-порты с их аппаратным контролем потока начинают постепенно уходить в прошлое. Если разрабатывать что-то свое, с нуля, то лучше уже основываться на USB, а еще лучше в данном случае на Ethernet

[selenur]

UPD: Кроме того COM-порты с их аппаратным контролем потока начинают постепенно уходить в прошлое. Если разрабатывать что-то свое, с нуля, то лучше уже основываться на USB, а еще лучше в данном случае на Ethernet

Недавно сделал устройство, которое работает по сети, и как дошло до программирования дополнительной утилиты по виндовс (для загрузки отчетов в 1С предприятие), так сразу начали всплывать косяки сетевого стека данной ОС, если в системе не одна а несколько сетевых интерфейсов
А в остальном сетевой интерфейс очень перспективная штука на мой взгляд И самое главное не страдает болячками USB интерфейсов, в плане качества, и длины соединительных проводов

[AndyBig]

косяки сетевого стека данной ОС, если в системе не одна а несколько сетевых интерфейсов

Что за косяки? А то может это косяки организации сети, а не ОС

[selenur]

косяки сетевого стека данной ОС, если в системе не одна а несколько сетевых интерфейсов

Что за косяки? А то может это косяки организации сети, а не ОС

Если интересно, узнаю у сотрудника этой частью занимался он, и на вскидку уже не помню...

[AndyBig]

Да ладно, тогда не нужно, не такой уж это животрепещущий вопрос