I am looking to read the value that is located in address 302H. The purpose is to read an input from hardware (a part of a 104pc stack). When I run the following code a get this error: Unhandled exception at 0x004134b9 in setOutput.exe: 0xC0000005: Access violation reading location 0x00000302.
#include <stdlib.h>
#define PORTBASE 0x302
int _tmain(int argc, char *argv[])
{
int value;
int volatile * port = (int *) PORTBASE;
printf("port = %d\n", port);
value = *port;
printf("port value = %d\n", value);
}
EDIT:
I am running this under widows xp. Only Documentation I can find on the board is below
EDIT:
From your answers below, I can see that I need to write a driver for the board. Can someone point me to a resource on how to do so?
In order to access physical memory directly under Windows, you need to develop a driver. I suggest you read up on Virtual Address Space to see why. The short story: The memory addresses you see from a usermode process has no relation to physical memory addresses, and the addresses where hardware lives are protected by the OS to prevent usermode applications from messing up things.
I'm assuming your program is running as a normal user. To prevent you from damaging the OS and crashing the system, modern OSes&CPUs prevent you from accessing memory that doesn't belong to your program.
In order to access such device memory you'll need to run in kernel CPU mode rather than user mode. The usual way to user such devices is to write a low level device driver that runs in kernel mode and use it as the interface to your user mode program.
You are not allowed to access the hardware directly from a user mode program. You need a device driver for that.
Doesn't the hardware come with some software you should install? Check the software documentation on how to call it.
There are several ready-made drivers to let user-mode applications read and write IO ports; one of the most famous ones is inpout32.dll, other are mentioned here, to find them a good search key is "write parallel port NT" (since they are most often used for this task).
In general they work by loading a kernel-mode driver (action that requires administrative privileges) and then calling it from usermode every time you call the dll function to perform a read/write.
Notice, however, that most of these libraries do not have any form of access control, so by loading their driver you're actually allowing any application that knows how to use it to read/write on IO ports, and this is quite a security risk.
Of course if you want to go the whole hog you can download Windows Device Driver SDK
User contributions licensed under CC BY-SA 3.0