Error setting parameters from dcb com port toolkit

Set DCB Fails When Attempting to Configure COM Port

I’m trying to write a C++ MFC application that uses the serial port (e.g. COM8). Every time I try to set the DCB it fails. If someone can point out what I’m doing wrong, I’d really appreciate it.

Additional Info: The generated error code is 87: «The parameter is incorrect.» Probably Microsoft’s most useful error-code. j/k

5 Answers 5

My money is on this:

The MSDN docs says this about StopBits:

The number of stop bits to be used. This member can be one of the following values.

So, you’re asking for 1.5 stop bits, which is such a horribly archaic thing I can’t even remember where it comes from. Teleprinters, possibly.

I’d guess the chances of your driver/hardware supporting this mode are slim, hence the error.

So, change it to dcb.StopBits = ONESTOPBIT;

Here are some possibilities in no particular order.

• GetCommState is filling the structure with garbage since the port hasn’t been initialized yet. You might just skip this step.
• There are two parameters that control the Parity settings, and it’s not clear if there’s any invalid combinations.
• The value for StopBits is not the number of bits, it’s a magic number constant. The value 1 equates to ONE5STOPBITS which might be invalid when combined with the other parameters.

I was able to resolve the problem using BuildCommDCB :

Источник

Error setting parameters from dcb

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

We are using Visual C++ to write a small application to communicate with a comm port for reading as well as writing to the port.

CreateFile call succeeds. Below is code snippet for CreateFile.

Later, we use a function SetRS232Params to get and set the parameters of the DCB structure. Below is the code snippet for this function.

In this code, SetCommstate is failing, we we checked the lasterror, its returning 6 with INVALID HANDLE.

We see that handle is invalid is getting printed.

Similarly, Invalid handle is printed for SetCommTimeouts too.

We are using Win 7 64 bit machine, and com port 1 for serial communication.

Do you think there is any problem in the hardware or some issue with the COMM or USB drivers due to which the handle becomes invalid and it is not usable for writing or reading to the port.

Or is there any problem in our function SetRS232Params where we are setting the parameters of the DCB structure.

Any help on this ll be greatly appreciated. please let us know.

Источник

RS232. Взгляд изнутри

Последовательный порт (далее ПП) удобный инструмент для общения между разными периферийными устройствами (как собранные самостоятельно на основе какого-нибудь МК, так и заводские: принтеры, осциллографы и т.д.) с одной стороны, и ПК с другой. На сегодняшний день наиболее популярные из всех ПП являются RS232 стандарт (переводится как «Recommended Standard») за его простоту и USB стандарт («Universal Serial BUS») за его резвость.
USB бесспорно вещь полезная, но жудко навороченная. Поскольку многим самодельным устройствам бешенный обмен данными с ПК неособо нужон, тогда на помощи приходит простой, надежный и многоопытный RS232 Интерфейс.

По RS232 стандарту устройства участвующие в обмене данными бывают двух типов:
Data Terminal Equipment (DTE) (устройство отдающее команды — ведущий) и
Data Circuit-Terminating Equipment (DCE) (периферия, обслуживающая хозяина — ведомый). Нередко, некоторые периферийные устройства ведут себя как DTE (например осциллографы, или наши с вами девайсы).

Модемное соединение — подрозумеваеи наличие некой иерархии, тоесть в случае когда в обмене данными участвуют больше чем два устройства им необходим некий арбитр (модем), разрешающий в определенный момент времени отсылать данные только одному устройству (в то время как читать могут хоть все остальные). Модемом может быть что угодно: отдельный девайс, или один из участников обмена данными, главное недопустить потери данных.

В случае когда устройств только два, или есть явный ведущий которого слушаются все остальные, никакого посредника им не нужно, а это означает что к их общению больше никто не подключится, и никакого арбитра в лице модема им не надо ( в отличие от предыдущего типа соединения, когда к одному принтеру можно подключить штук 10 ПК ). Опять-же главное недопустить одновременной отправки данных — в определенный момент времени, общатся может только одна пара устройств. Такое соединение называется нуль-модемное соединение:

Типы передач данных

Минимальное количество проводков необходимое для обмена данными равно двум (этокий жадный изврат), если передача является односторонней ([Tx, GND]). В случае когда необходимо полноценное — двухстороннее общение число проводков возростает аж до трех ([Rx, Tx, GND]). Большинство периферийных устройств поддерживают одновременную передачу и прием данных — full-duplex, но если один из собеседников на такое не способен, обмен переходит в разряд неполноценных — half-duplex (пока один не закончил передачу/прием другой пляшит под его дудку).

Распиновка COM разъёма

В столбце Signal Name, DATA Terminal можно заменить на ПК (то есть Data Terminal Ready соответствует ПК готов к работе), а DATA Set на Периферия.

Как следует из предыдущей таблицы, все пины делятся на управляющие (control pins) и транспортные (Data pins). Каждый пин в определенный момент времени может находьтся только в одном из двух состояний: активном (on) или неактивном (off). Чтобы не запутатся, и както защитить данные от помех, разработчики решили что во время передачи данных они были сначало усилены (+5В –> +12В, 0В –> -12В ) а потом инвертированы, в то время как c управляющими сигналами они долго не парились и просто их усилели (тоесть положительное стало еще положительней а отрицательное — отрицательнее, относительно общего провода).

Назначение управляющих пинов ([RTS, CTS], [DTR, DSR] и [CD, RI]) сводится к следующему:

• Отслеживать состояние собеседника
• Отслеживать поток данных

Пара [RTS, CTS] — используется для обозначения готовности данной пары устройств к передачи/приему соответственно.

1. DTE устройство устанавливает RTS = on, сигнализируя о том что оно готово к приему данных. Если устройство получило достаточное количество данных то устанавливаем RTS =off.
2. DCE устройство устанавливает CTS =on, сигнализируя о том что оно готово к приему данных. Если устройство получило достаточное количество данных то устанавливаем CTS =off.

Кто каким пином будет управлять (тоесть кому быть DTE а кому DCE) решать вам. Соответственно программы управления этими устройствами должны выставить RTS(выход)/CTS (вход), или наоборот, иначе могут быть глюки.

Пара [DTR, DSR] — большинство устройств используют эти пины для сигнализирования что они подключены и готовы к работе.

1. DTE устройство устанавливает DTR=on, сообщая DCE устройству что оно готово к работе. Соответственно когда DTE устанавливает DTR=off, то оно больше не желает (или не может) общатся (положила трубку 🙂 )
2. DCE устройство устанавливает DSR=on, сообщая что оно подключено, а когда DSR=off – оно отключено.

Такой метод контроля потока данных называется – hardware handshaking (чтото вроде аппаратное управление). Пары [DTR, DSR] и [RTS, CTS] могут быть с легкостью взаимо-заменены без всякого ущерба.

Пара [CD, RI] – используется для обозначения (в тот самом случае когда один принтер на отару кампов) что в данный момент линии передачи данных кем-то заняты.
Как правило этой парой управляет модем, но не обязательно.

• St – Стартовый Бит (начало передачи данных) – логический ноль
• 0..8 – позиция бита (данных) в пакете (позиция «0» – LSB)
• P – бит парности (проверка успешной передачи данных)
• Sp1,Sp2 – стоп биты (завершают передачу пакета) – логическая единица
• [] – в скобках обозначены биты которые могут отсутствовать
(биты данных с 5 по 8 так или иначе будут переданы, но не рассмотрены — мусор)
• IDLE – ожидание (логическая единица)

Как я уже говорил, во время передачи — данные инвертируются, так что если будете проверять осциллографом как отсылается пакет — не пугайтесь.

Часто формат пакета обозначается следующим образом: 8-N-1 (8 бит данных, без бита проверки, один стоп бит) или 5-E-2 (5 бит данных (3 бита мусора), с проверкой на четность, два стоп бита).

Поскольку MAX232 поддерживает аппаратное управление COM портом, и если с разводкой данной схемы проблем нет, почемуб и не использовать эту возможность, вдруг когда пригодится (не пропадать же добру). В противном случае, можно обойтись без аппаратного управления, как зачастую и происходит.

Софт
UPD: заменил вывод cout на printf, и убрал флаги RxClear и TxClear

ПП по сути является фаилом из которого ведется чтение/запись, поэтому основные операции которые применяются над ПП можно группировать следующим способом:

Также много интересного можно узнать на следующих сайтах: Programming Serial Connections , Serial programming in win32 OS

Запихните предыдущий код в хидэр фаил, например с именем COM_INIT.h и можно использовать ПП.

Надеюсь эти скромные знания кому-то помогут. Если есть вопросы попытаюсь ответить.

Источник

Device control block (dcb) parameters, Bypassing the normal windows 32 apis, Real time issues – Comtrol Multiport Modems Windows 98 User Manual

Page 50

Device Control Block (DCB) Parameters

Device Control Block (DCB) Parameters

XonLim, XoffLim — The RocketPort and RocketModem series does not handle
flow control like traditional PC COM ports. Keep in mind the adapters have
large hardware input/output buffers, and any control strategy based on buffer
levels brings the following question: should the trip point be in reference to the
hardware buffer, or the driver software buffer, or both? And if the hardware
performs the flow control, you cannot consider the software buffer in the
equation. You also need to balance this with efficiency.

RTS/CTS flow control is handled by the adapter on a hardware level. The RTS
trip points are hardwired to about 7/8 full and empty in relation to the
hardware input buffer of 1,024 bytes.

DTR/DSR flow control is handled at the software driver level. The DTR trip
point is hardwired at the level at which the software input buffer becomes full
(the hardware input buffer of 1,024 bytes still remains). The low level is
XonLim, and is in relation to the drivers software buffer.

fOutX — If set, this cause data transmission to halt upon reception of a XOFF
character and resume when a XON character is received. The XON/XOFF
characters are specified by XoffChar and XonChar parameters and may be
changed by the application. The trip points are hardwired to 7/8 full and
empty in relation to the hardware input buffer of 1,024 bytes.

fInX — If set, when the receive buffer is near full, an XOFF character will be
sent out to stop the incoming flow of data. When the receive buffer empties,
the XON character is sent to resume incoming data. The fInX trip point is
hardwired at the level at which the software buffer becomes full (same as DTR
above).

fBinary — Leave this bit set on! ASCII mode (this value at zero) enables the EOF
character to be detected. After the EOF character has been detected, no more
data is allowed to be read, and an overflow error is displayed if more data is
received. While Non-Binary mode is supported, it should not be used.

Bypassing the Normal Windows 32

An application program cannot talk to the port driver directly, and must go
through the normal API calls. In the Windows 98/SE and ME environments it is
possible to write a VCOMM client to bypass the Win32 API layer, but this is not
recommended and is not portable to the Windows NT environment.

Real Time Issues

By default, the driver runs in a polled interrupt fashion; the system is interrupted
every poll period. The poll period default is 10 milliseconds (100 Hz). (In this
instance the Use IRQ option is not selected in the Advanced Board Options
dialog. See

on Page 16 for more information on the Use

What this means is that all Event processing is restricted to the poll period
interval. This will only be a problem for some applications that require very
precise synchronization with other hardware. In some cases, this may be worked
around by polling the queue counts through GetCommError().

Источник

Error setting parameters from dcb

Post by peteH » Nov 30, 2007 14:03

I have an auto project where I need to communicate with the serial (diagnostic) port on a car. Unfortunately, it runs at a fixed non-standard 93750 baud via the UART on its 8051 processor.

I currently am using a USB to Serial adaptor from my PC and have successfully got a loop back test running across the serial adaptor from my PC and it can happily talk to itself, so it looks like the FreeBASIC program that I’ve written to communicate with the car is working ok at a basic level.

But, I have two problems.

Problem 1.) I haven’t been able to get the serial port to operate at the car computer’s non-standard baud rate yet. When I specify 93750 baud in the OPEN COM statement it appears to «default» to 115600 (when I look at the bit rate on a CRO). Is there a way to get the 93750 baud rate command to work via standard FreeBASIC? That is, assuming the serial convertor is capable of the non-standard speed, can FreeBASIC software be made to set it? I’d prefer not to have to write a special handler! If the software issue can be fixed, I note there are PCI Bus Serial I/O cards available on the Web that appear to be programmable to non-standard baud rates, provided the application program can handle it.

Problem 2.) I have found in testing the serial port from FreeBASIC while examining the 1st problem, that even if I set up a continuous loop writing to the port (with errors suppressed to stop overflow errors), it is only outputting one 11 bit charactor per 1 mSec as the stop bit period extends to fill out to 1 mSec before the next START bit begins. When I vary the port speed (in the OPEN command) over a large range of (standard) speeds, the actual character bits are output at the proper rate but the gap between the end of the STOP bit and the next START bit just expands up to the 1 mSec total (again looked at via a CRO). The continuous loop code fragment follows and is so simple it’s pretty hard to see how it could contribute. It doesn’t even involve a GET command while in the test loop.

Источник

DCB dcb = {0};

dcb.DCBlength = sizeof(DCB);
port.Insert( 0, L"\\.\" );

m_hComm = CreateFile(
    port,                           // Virtual COM port
    GENERIC_READ | GENERIC_WRITE,   // Access: Read and write
    0,                              // Share: No sharing
    NULL,                           // Security: None
    OPEN_EXISTING,                  // The COM port already exists.
    FILE_FLAG_OVERLAPPED,           // Asynchronous I/O.
    NULL                            // No template file for COM port.
    );

if ( m_hComm == INVALID_HANDLE_VALUE )
{
    TRACE(_T("Unable to open COM port."));
    ThrowException();
}

if ( !::GetCommState( m_hComm, &dcb ) )
{
    TRACE(_T("CSerialPort : Failed to get the comm state - Error: %d"), GetLastError());
    ThrowException();
}

dcb.BaudRate = 38400;               // Setup the baud rate.
dcb.Parity = NOPARITY;              // Setup the parity.
dcb.ByteSize = 8;                   // Setup the data bits.
dcb.StopBits = 1;                   // Setup the stop bits.

if ( !::SetCommState( m_hComm, &dcb ) ) // <- Fails here.
{
    TRACE(_T("CSerialPort : Failed to set the comm state - Error: %d"), GetLastError());
    ThrowException();
}

5 ответов

Лучший ответ

DCB dcb = {0};

if ( !::BuildCommDCB( _T("baud=38400 parity=N data=8 stop=1"), &dcb ) )
{
    TRACE(_T("CSerialPort : Failed to build the DCB structure - Error: %d"), GetLastError());
    ThrowException();
}

dcb.StopBits = 1; 

/* Try to open the port */
hCom = CreateFile(szPort, GENERIC_READ | GENERIC_WRITE, 0, 0, OPEN_EXISTING, 0, 0);

if (hCom != INVALID_HANDLE_VALUE) {
    printf("Handle successn");
}

    dcb = { 0 };
    dcb.DCBlength = sizeof(dcb);

    fSuccess = GetCommState(hCom, &dcb);

    if (!fSuccess) {
        // Handle the error.
        printf("GetCommState failed with error %d.n", GetLastError());
        CloseHandle(hCom);
        return APP_ERROR;
    }

    // Fill in DCB: 57,600 bps, 8 data bits, no parity, and 1 stop bit.
    dcb = { 0 };
    dcb.DCBlength = sizeof(dcb);

    dcb.BaudRate = CBR_115200;     // Set the baud rate
    dcb.ByteSize = 8;              // Data size, xmit, and rcv
    dcb.Parity = NOPARITY;         // No parity bit
    dcb.StopBits = ONESTOPBIT;     // One stop bit

    fSuccess = SetCommState(hCom, &dcb);

    if (!fSuccess) {
        // Handle the error.
        printf("SetCommState failed with error %d.n", GetLastError());
        CloseHandle(hCom);
        return APP_ERROR;
    }
}

printf("Serial port successfully reconfigured.n");