C / C++ / MFC

10-Dec-08 20:19

Hai !
I have a device connected to a COM port, i send a command to the device, the device responds, this response is stored in the buffer of COM port.
I read part of the response from buffer, and send the next command, now if i read response from buffer, i get the old remaining response plus the new response.
so i want to clear the buffer before i send a new command!
so how to clear the buffer of a COM port !
thanks !

VC++Maniac10-Dec-08 20:27

10-Dec-08 20:27

How do you read and write to the Buffer?

kapardhi10-Dec-08 21:15

10-Dec-08 21:15

Using the handle of Port along with ReadFile () and WriteFile ()

Roger Stoltz10-Dec-08 23:24

10-Dec-08 23:24

When communicating directly with the serial driver through the ::WriteFile() and ::ReadFile() API, you cannot "flush" the read buffer.
The file API contains the ::FlushFileBuffers() function, but it only flushes the transmit buffer if the handle refers to a communications device such as a COM port.

You have to read the entire response from your first request before issuing a new request to the device.
Why does this present a problem for you? Is it due to the lack of transmission protocol that you don't know how much data to expect from your device?
Some way you have to know when you've received the complete response from your device, either by protocol or by a timeout.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

VC++Maniac10-Dec-08 23:30

10-Dec-08 23:30

Are you specifying the FILE_FLAG_OVERLAPPED flag in CreateFile()..?

Roger Stoltz10-Dec-08 23:40

10-Dec-08 23:40

Ummm, I guess you replied to the wrong guy... Wink | ;)

However, specifying the flag for overlapped mode doesn't make a difference regarding "flushing" the receive buffer in the serial driver.
On the other hand, overlapped mode should be used in any case.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

kapardhi11-Dec-08 1:17

11-Dec-08 1:17

To be more specific :

The context where i want to clear buffer is somewhat as follows :
The device which is attached to the COM port is sujected to a specific Baudrate, parity, databit and stopbit, whose values i do not know beforehand. so i send the command for all combinations of baudrate, parity, databit stopbits.
During the process i receive junk/unnecessary response for a wrong combination, and i get correct/ expected response only for correct combination of baudrate, parity, databibit and stopbit.
so i want only to read the correct response and ignore others !
I know correct value starts with a specific value, so when ever there is a response starting with the specific value, I read it else I ignore it.
Now for the responses which I get for wrong combination donot start with a specific value so I ignore them hence they get accumulated in the buffer, now when the correct combination is reached and I try to read the response it starts with previous junk values as this response doesnot start with my specific value so it gets ignored in way I lose my correct response also, so I want to clear the buffer befor I send my command.

Thanks !

Roger Stoltz11-Dec-08 2:09

11-Dec-08 2:09

kapardhi wrote:
The device which is attached to the COM port is sujected to a specific Baudrate, parity, databit and stopbit, whose values i do not know beforehand. so i send the command for all combinations of baudrate, parity, databit stopbits.

You actually mean that you have no idea, and cannot predict, what settings the device uses on start up? I find that very hard to believe, because it means that the device is uninitialized and hence should not be able to communicate at all.

Usually a device that supports multiple communication settings starts off with a known configuration; e.g 300 baud, 1 stop bit, no parity. Then the host negotiates with the device about a new configuration through a known protocol.

If you don't know anything about this device, you would be better off using an oscilloscope to find out what configuration is used.
But even if you find out what configuration is being used, you still have to know the protocol, which I suspect can be found at the same place as where the communication settings are documented.
The alternative is to set a timeout using ::SetCommTimeouts() to let the timeout of the read operation expire when the hardware hasn't received a new byte within e.g. ten byte times. Then it's reasonable to assume that you've received all data the device wants to send and you can continue and try another configuration.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

kapardhi11-Dec-08 2:25

11-Dec-08 2:25

Sorry u are misunderstanding me !
Actually in my application i have an option to change the baudrate, parity, stopbit, databit of the device connected as well as to change the baudrate, parity, stopbit, databit of the COM port.

now lets assume one of the user have changed the device baud rate to 115200, with even parity, 6 databits 2 stopbits.

now i donot know the configuration of the connected device, so i have to change my COM port settings and send command for all combinations of baudrate, parity etc in order to communicate with the device.

when i get the correct/expected response i can conclude that this is the combination of the device!
i am also using CommTimeOuts !

Thanks !

Roger Stoltz11-Dec-08 3:01

11-Dec-08 3:01

kapardhi wrote:
Actually in my application i have an option to change the baudrate, parity, stopbit, databit of the device connected as well as to change the baudrate, parity, stopbit, databit of the COM port.

Why is this option offered to the user?
Is it because the application communicates with different kind of devices with different communication settings?

IF the application connects to different devices, doesn't one particular device start up with the same settings as the last time, i.e. is it not predictable?
If it is predictable, why not let the user choose from a list of device types that corresponds to the communication settings instead of giving him the possibility to change all settings and thus create this problem for you, the application, the device and himself?

My point is that the settings in the device should be the same every time it starts. If the user knows what kind of device it is, the application should know what configuration to use in order to communicate with that kind of device. It's your responsability as developer to make this mapping and if you don't think it is, then the user could use HyperTerminal, PuTTY or similar.

kapardhi wrote:
i am also using CommTimeOuts !

But probably the wrong way, or with the read timeout too short, since you clearly have not received the complete answer. Otherwise you would not have posted this thread in the first place.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

Iain Clarke, Warrior Programmer

Iain Clarke, Warrior Programmer11-Dec-08 0:13

11-Dec-08 0:13

I can see this being very fragile [*]

What if you see the first part of the response, act on that, clear the buffer, but the rest of the response is still coming in?
You could clear the buffer too early. What do you do with the junk data?
If you wait for it to be quiet, you will add long delays.
If you wait till the right amount of data has come in, you don't need to flush.

I really struggle to see you needing to do this, unless your protocol is broken. If it's designed by someone else, then it's probably fine and you need to change your code. If it's designed by you, then you may need to go back and change the protocol *then* your code.

I've had similar issues with Pipes and sockets with varying data-lump-sizes, and solved it by having a header value specifying how many further bytes are in this lump of data. Simple but works well. Whether you pay attention to the whole data-lump or not, it's wise to read it all in. Feel free to throw it away.

Good luck,

Iain.

[*] A euphemism meaning it will fail within 2 minutes of someone else using it.

kapardhi11-Dec-08 1:18

11-Dec-08 1:18

To be more specific :
The context where i want to clear buffer is somewhat as follows :
The device which is attached to the COM port is sujected to a specific Baudrate, parity, databit and stopbit, whose values i do not know beforehand. so i send the command for all combinations of baudrate, parity, databit stopbits.
During the process i receive junk/unnecessary response for a wrong combination, and i get correct/ expected response only for correct combination of baudrate, parity, databibit and stopbit.
so i want only to read the correct response and ignore others !
I know correct value starts with a specific value, so when ever there is a response starting with the specific value, I read it else I ignore it.
Now for the responses which I get for wrong combination donot start with a specific value so I ignore them hence they get accumulated in the buffer, now when the correct combination is reached and I try to read the response it starts with previous junk values as this response doesnot start with my specific value so it gets ignored in way I lose my correct response also, so I want to clear the buffer befor I send my command.
Thanks !

JudyL_MD11-Dec-08 8:07

JudyL_MD

11-Dec-08 8:07

Are you perchance in search of PurgeComm[^]?

Judy

Be wary of strong drink. It can make you shoot at tax collectors - and miss.
Lazarus Long, "Time Enough For Love" by Robert A. Heinlein

kapardhi11-Dec-08 19:41

11-Dec-08 19:41

PurgeComm clears the buffer of the device's driver, i want to clear the buffer of the Serial COM port of my computer !!

How to create .DBX file (MS-OUTLOOK EXPRESS files) using vc++ 6.0

JudyL_MD12-Dec-08 3:14

JudyL_MD

12-Dec-08 3:14

kapardhi wrote:
PurgeComm clears the buffer of the device's driver, i want to clear the buffer of the Serial COM port of my computer !!

Which part of (the first sentence in the link)

Discards all characters from the output or input buffer of a specified communications resource

is unclear? A COM port is a communications resource. The buffers for a comm resource are maintained by the device driver for that resource.

Judy

Be wary of strong drink. It can make you shoot at tax collectors - and miss.
Lazarus Long, "Time Enough For Love" by Robert A. Heinlein

ravi malik10-Dec-08 19:44

ravi malik

10-Dec-08 19:44

hi all

i want to create a .DBX file having some mails.
can anybody tell me how to create a .DBX file(MS-OUTLOOK EXPRESS)
using vc++ 6.0

Thanks in advance.

Create DIB from a HBITMAP

VC++Maniac10-Dec-08 19:35

10-Dec-08 19:35

I have a handle to bitmap. I need to store this bitmap to a xml file. The xml file will be read on a mac system.

So how do I create a DIB from a HBITMAP?

Thanks..

Hamid_RT10-Dec-08 20:17

Hamid_RT

10-Dec-08 20:17

Creating a DIB section from a BMP file[^].

Of one Essence is the human race
thus has Creation put the base
One Limb impacted is sufficient
For all Others to feel the Mace
(Saadi )

VC++Maniac10-Dec-08 20:25

10-Dec-08 20:25

That is not what I require. Not from a file. I already have a HBITMAP from the file. I need a logic that converts a HBITMAP to a DIB, which will be readable on a mac system.

enhzflep10-Dec-08 23:34

enhzflep

10-Dec-08 23:34

1. Get dimensions of existing HBITMAP
2. Use CreateDIBSection to create an image of the correct size
3. Create a couple of memory DCs
4. Select the images into their own DCs
5. BitBlt from the DC holding the HBITMAP to the one containing the DIBSection
6. Save the DIBSection to disk (you can use the supplied function)
7. Deselect the images from their DCs
8. DeleteObject both images (HBITMAP & DIBSection)

BOOL SaveBitmapFile(HDC p_hDC, LPCTSTR p_pchFileName)
{
    HBITMAP hBmp = (HBITMAP)GetCurrentObject( p_hDC, OBJ_BITMAP );

    BITMAPINFO stBmpInfo;
    stBmpInfo.bmiHeader.biSize = sizeof( stBmpInfo.bmiHeader );
    stBmpInfo.bmiHeader.biBitCount = 0;
    GetDIBits( p_hDC, hBmp, 0, 0, NULL, &stBmpInfo, DIB_RGB_COLORS );

    ULONG iBmpInfoSize;

    switch( stBmpInfo.bmiHeader.biBitCount )
    {
        case 24:
            iBmpInfoSize = sizeof(BITMAPINFOHEADER);
        break;

        case 16:
        case 32:
            iBmpInfoSize = sizeof(BITMAPINFOHEADER)+sizeof(DWORD)*3;
        break;

        default:
            iBmpInfoSize = sizeof(BITMAPINFOHEADER) +
                           sizeof(RGBQUAD) * ( 1 << stBmpInfo.bmiHeader.biBitCount );
        break;
    }

    PBITMAPINFO pstBmpInfo;
    if( iBmpInfoSize != sizeof(BITMAPINFOHEADER) )
    {
        pstBmpInfo = (PBITMAPINFO)GlobalAlloc( GMEM_FIXED | GMEM_ZEROINIT, iBmpInfoSize );
        PBYTE pbtBmpInfoDest = (PBYTE)pstBmpInfo;
        PBYTE pbtBmpInfoSrc = (PBYTE)&stBmpInfo;
        ULONG iSizeTmp = sizeof( BITMAPINFOHEADER );

        while( iSizeTmp-- )
        {
            *( ( pbtBmpInfoDest )++ ) = *( ( pbtBmpInfoSrc )++ );
        }
    }

    HANDLE hFile = CreateFile( p_pchFileName, GENERIC_WRITE, 0,
                               NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_ARCHIVE,
                               NULL );

    BITMAPFILEHEADER stBmpFileHder;
    stBmpFileHder.bfType = 0x4D42; // 'BM'
    stBmpFileHder.bfSize = sizeof(BITMAPFILEHEADER)
                         + sizeof(BITMAPINFOHEADER)
                         + iBmpInfoSize
                         + pstBmpInfo->bmiHeader.biSizeImage;

    stBmpFileHder.bfReserved1 = 0;
    stBmpFileHder.bfReserved2 = 0;
    stBmpFileHder.bfOffBits = sizeof(BITMAPFILEHEADER) + iBmpInfoSize;

    DWORD dRet;

    //// WRITING ////
    WriteFile( hFile, (LPCVOID)&stBmpFileHder , sizeof(BITMAPFILEHEADER), &dRet, NULL );

    PBYTE pBits = (PBYTE)GlobalAlloc( GMEM_FIXED | GMEM_ZEROINIT, stBmpInfo.bmiHeader.biSizeImage );

    HBITMAP hBmpOld;
    HBITMAP hTmpBmp = CreateCompatibleBitmap( p_hDC,
                                              pstBmpInfo->bmiHeader.biWidth,
                                              pstBmpInfo->bmiHeader.biHeight );

    hBmpOld = (HBITMAP)SelectObject( p_hDC, hTmpBmp );

    GetDIBits( p_hDC, hBmp, 0, pstBmpInfo->bmiHeader.biHeight,
               (LPSTR)pBits, pstBmpInfo, DIB_RGB_COLORS );

    //// WRITING ////
    WriteFile( hFile, (LPCVOID)pstBmpInfo, iBmpInfoSize, &dRet, NULL );

    WriteFile( hFile, (LPCVOID)pBits, pstBmpInfo->bmiHeader.biSizeImage, &dRet, NULL );

    SelectObject( p_hDC, hBmpOld );
    DeleteObject( hTmpBmp );
    CloseHandle( hFile );
    GlobalFree( pstBmpInfo );
    GlobalFree( pBits );
    return TRUE;
}

VC++Maniac10-Dec-08 23:43

10-Dec-08 23:43

Thanks for your reply.
Do you think writing the DIB to a xml file and reading back and displaying it will actually display it?

akirilov11-Dec-08 0:08

akirilov

11-Dec-08 0:08

Do you think writing the DIB to a xml file and reading back and displaying it will actually display it?

Well that is the tricky part - it is important to choose what kind of DIB you want, so you can read it latter on Mac:
- choose how many colors
- by default DIB is bottom-up. If Mac can't read it put negative height in DIB
- if Mac can read .bmp, consider writing the file in .bmp rather .xml (this will greatly reduce file size and writing routines to read .xml)

Good luck.