Has serial ever worked with InpOut32

[MrRoger]

Hi, I'm trying to directly access UART registers.

Why? Well I'm an expert in comms protocols, I implemented serial protocols in embedded systems for many years. That's why someone has asked me to implement a difficult legacy protocol, and it cannot be done using ordinary serial port drivers because of the Sync Trauma requirements.

It would be very straightforward if I could access the UART registers directly, indeed I have done this on a micro controller with an 8250 like UART. But ideally I want to do this directly with a PC serial port, but I'm no expert on windows

Now googling a bit I soon found both InpOut32 and WinIo. Everydody says these will allow direct port access, but I can't make either work. All I get is 0xFF from the serial I/O space, can't even use the scratchpad register (base + 7).

Again, googling around, I see a lot of people with the same problem. And everybody says it 'should' work, but nobody seems to have concrete success stories.

I note also that while many people are using these drivers, the primary use is for paralell port access.

So, I'm wondering, is it really possible to access the serial port with these devices?

Does anybody have concrete success?

(Note, I am talking about real serial ports, i.e. COM1 with base address given as 0x3f8 in device manager, and I have tried with the port activated and non activated, and the port does work. )

[phil]

Yes it does, infact this is what I used InpOut32 for and the reason I ported it to x64.
I was hitting the registers to set a nonstandard BAUD rate!

It should work fine, so long as the serial port's registers are in fact addressable by inpout32. USB serial ports are not likely to work, but onboard ones should be fine. I guess PCI serial boards would suffer the same potential issues as PCI parallel ports - in that they probably wont work, but some might!

Thanks,
Phil

[MrRoger]

Aha, found the problem. You need to open the serial! As I do all the setup of the UART I thought I could just use it as you used to in DOS.

But no, it seems that the UART is not even mapped into the IO address space until it has been opened... presumably these days it is all virtual like the memory map!

[dotpk]

Hi guys,

I think I'm having a similar problem to MrRoger above, but I don't understand his previous post about 'opening the serial port'.

I'm using inpout32.dll on a Windows 7 x64 system, in Visual Studio 2013. It seems that I can write to a register with Out32(), but the value is not returned to me if I use Inb32() on the same address. My pc speaker plays its tune when I run the demo program, so it does appear that the driver is working.

I'm trying to toggle the FCS bit (0x01) of the Modem Control Register of my PC's USART. As mentioned, writing to port 0x3fc appears to work, but reading back from the address consistently returns 0xff. I've attached my code below, as well as the console output that it returns when I run it. If anyone can give a hint or pointer as to what I'm doing wrong it'd be greatly appreciated.

Cheers!

Code: Select all

#include "stdafx.h"
#include "windows.h"
#include "stdio.h"

typedef void	(__stdcall *lpOut32)(short, short);
typedef short	(__stdcall *lpInp32)(short);
typedef BOOL	(__stdcall *lpIsInpOutDriverOpen)(void);
typedef BOOL	(__stdcall *lpIsXP64Bit)(void);

//Some global function pointers (messy but fine for an example)
lpOut32 gfpOutb;
lpInp32 gfpInb;
lpIsInpOutDriverOpen gfpIsInpOutDriverOpen;
lpIsXP64Bit gfpIsXP64Bit;

int
main(int argc, char* argv[]) {
	
	short port, val, i

	//Dynamically load the DLL at runtime (not linked at compile time)
	HINSTANCE hInpOutDll ;
	hInpOutDll = LoadLibrary("InpOut32.DLL") ;	//The 32bit DLL. If we are building x64 C++ 
												//applicaiton then use InpOutx64.dll
	if (hInpOutDll == NULL) {
		printf("Unable to open InpOut Driver!\n");
		return -1;
	}

	gfpOutb = (lpOut32)GetProcAddress(hInpOutDll, "Out32");
	gfpInb = (lpInp32)GetProcAddress(hInpOutDll, "Inp32");
	gfpIsXP64Bit = (lpIsXP64Bit)GetProcAddress(hInpOutDll, "IsXP64Bit");
	gfpIsInpOutDriverOpen = (lpIsInpOutDriverOpen)GetProcAddress(hInpOutDll, "IsInpOutDriverOpen");

	if (gfpOutb == NULL || gfpInb == NULL || gfpIsXP64Bit == NULL || gfpIsInpOutDriverOpen == NULL) {
		printf("Error: function pointer was NULL\n");
		return -1;
	}

	if (gfpIsXP64Bit) {
		printf("looks like an x64 system!\n");
	}


	if (gfpIsInpOutDriverOpen()) {
		
		port = (short)0x3fc;
		val =   (short)0x000;
		
		for (i = 5; i > 0; --i) {
			gfpOutb(port, val);
			Sleep(500);

			printf("data written to 0x%3x: %d\n", port, val);
			printf("data at 0x%3x is: %2x\n", port, gfpIn(port));

			val ^= (1 << 0x01); /* toggle val */
		}
	}

	//All done
	FreeLibrary(hInpOutDll);
	return 0;
}

The result:

C:\Users\User\Desktop\Debug>InpoutTest.exe
looks like an x64 system!
data written to 0x3fc: 0
data at 0x3fc is: 0xff
data written to 0x3fc: 2
data at 0x3fc is: 0xff
data written to 0x3fc: 0
data at 0x3fc is: 0xff
data written to 0x3fc: 2
data at 0x3fc is: 0xff
data written to 0x3fc: 0
data at 0x3fc is: 0xff

[phil]

Sorry, I dont know the answer. Maybe MrRoger can help as he seemed to figure out his problem. I dont know if your problem is the same. Have you tried "opening" the serial port first like he suggested fixed his problem?

[dotpk]

Sorry, I dont know the answer. Maybe MrRoger can help as he seemed to figure out his problem. I dont know if your problem is the same. Have you tried "opening" the serial port first like he suggested fixed his problem?

Yeah I've PM'ed MrRoger, but no reply as yet. RE 'opening' the port - that's what I'm trying to understand. I have no idea how that's supposed to work :S. Perhaps he means opening it via the COM interface? I guess I'll have to experiment a bit...

Thanks anyway Phil - and thanks again for making the driver available

[dotpk]

So I figured it out and thought I would post for anyone else who gets stuck on this.

Apparently it's OK to open the COM port in any random program. The only theory I have for this is that the PC's USART is disabled by the motherboard drivers in order to save power. This would therefore imply that the inpout dll is not 'triggering' the drivers to wake up the USART. I could be wrong about that, though.

I downloaded PuTTY and used it to open COM1, and I started getting coherent values out of my C++ program. I suspect that it is probably OK to open the COM port via the same program that's using inpout, but I haven't tested this.

I hope that helps anyone else who gets stuck on this!

[phil]

Thanks for the feedback - this seems to confirm MrRoger's post above.