如何使用 Win32 API 与 com 端口 (RS232) 通信

发布于 2024-10-23 18:31:06 字数 757 浏览 1 评论 0原文

我正在尝试使用 win32 API 与 com 端口对话 我找到了这个 http://www.robbayer.com/files/serial-win.pdf

hSerial = CreateFile("COM1",
GENERIC_READ | GENERIC_WRITE,
0,
0,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
0);

我使用 VS2008,它抱怨 错误 C2664: 'CreateFileW' : 无法将参数 1 从 'const char [5]' 转换为 'LPCWSTR'

好的,我想它不喜欢“COM1”为 char* 类型,

我尝试将其转换为 LPCWSTR("COM1" ),然后编译就没有问题了。

但是,它返回“ERROR opening serial port -1”,因此它没有成功找到com端口。我想直接铸造不是正确的方法?

请告诉我应该做什么才能使这项工作成功。

msdn 没有那么有帮助 http://msdn.microsoft.com/en-us/library/ms810467.aspx

我不知道“gszPort”是什么意思

I am trying to use win32 API to talk to a com port
I found this
http://www.robbayer.com/files/serial-win.pdf

hSerial = CreateFile("COM1",
GENERIC_READ | GENERIC_WRITE,
0,
0,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
0);

I use VS2008 and it complains
error C2664: 'CreateFileW' : cannot convert parameter 1 from 'const char [5]' to 'LPCWSTR'

OK, I guess it doesn't like "COM1" to be char* type,

I tried casting it LPCWSTR("COM1"), then it compiles with no problem.

However, it returns "ERROR opening serial port -1", so it doesn't find the com port successfully. I guess direct casting is not the right way?

Please tell me what I should do to make this work.

the msdn is not that helpful
http://msdn.microsoft.com/en-us/library/ms810467.aspx

I don't know what the "gszPort" means there

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

吻安 2024-10-30 18:31:06

尝试使用 _T("COM1") 而不是 LPCWSTR("COM1")。它称为通用文本映射。我实际上不知道这是否是问题所在,但使用 _T 是解决问题的正确方法。

此外,当 Windows API 调用返回错误条件(例如 -1)时,您可以使用 最后一个错误代码(使用 GetLastErrorFormatMessage 获取更详细的错误描述。

Try _T("COM1") instead of LPCWSTR("COM1"). It's called Generic-Text Mapping. I don't actually know whether that is the problem, but using _T is the right way to it.

Also, when Windows API calls return an error condition (like -1) you can use the Last-Error Code (using GetLastError and FormatMessage) to get a more detailed description of the error.

不离久伴 2024-10-30 18:31:06

对于 Unicode 构建,CreateFile 映射到 CreateFileW,它需要“宽”字符串。您可以通过在字符串常量前添加 L 来解决眼前的问题,如下所示:

CreateFile(L"COM1", ...);

有些人会建议显式使用宽版本:

CreateFileW(L"COM1", ...);

或者您可以显式使用“ANSI”版本,即使在 Unicode 版本中:

CreateFileA("COM1", ...);

如果您希望能够要构建 Unicode 和 ANSI 版本,您可以使用可以选择包含 L 前缀的宏。该宏有两个版本:TEXT(x)_T(x)。如果我没记错的话,前者来自 Windows API,通过 实现,后者来自 Microsoft 的 C 运行时库实现。由于这是一个 Windows API,我将使用 TEXT 版本。

CreateFile(TEXT("COM"), ...);

如今,保留 ANSI 的向后兼容性可能不值得。过去十年中发布的所有 Windows 版本都在内部使用 Unicode,因此如果您尝试使用 ANSI 版本,字符串将在运行时变宽。所以我不会担心宏,只需在字符串文字前加上 L 前缀,除非在非常特殊的情况下。

For a Unicode build, CreateFile maps to CreateFileW which expects "wide" character strings. You can solve the immediate problem by prefixing your string constant with L, like this:

CreateFile(L"COM1", ...);

Some people would suggest explicitly using the wide version:

CreateFileW(L"COM1", ...);

Or you can explicitly use the "ANSI" version, even in a Unicode build:

CreateFileA("COM1", ...);

If you want to be able to build Unicode and ANSI builds, you can use a macro that optionally includes the L prefix. There are two versions of this macro: TEXT(x) and _T(x). If I recall correctly, the former comes from the Windows API via <tchar.h> and the latter comes from Microsoft's implementation of the C runtime library. Since this is a Windows API, I'd use the TEXT version.

CreateFile(TEXT("COM"), ...);

Nowadays, it's probably not worth keeping the backward compatibility for ANSI. All versions of Windows released in the past decade use Unicode internally, so if you try to use the ANSI versions, the strings are going to be widened at run time. So I wouldn't worry about the macros and just prefix string literals with L except in very special circumstances.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文