Direct I/O port access

[Jason Spence]

Hi -

I'm investigating a port of some old DOS-based code to Windows CE.Net
version 5. The code currently does a lot of direct I/O port access and I'm
kind of concerned that we'll have to write a full driver for the device for
our user code to interface with it. What I'd really like would be to bypass
all the I/O port protection in the I/O protection bitmap, but I have no idea
where information about how that works is located in the MSDN docs; a search
doesn't turn anything up.

As an example, I'd like to be able to do things like this from a userland
binary in the OS image:

BYTE input;

_asm {
mov dx, 0x100
in al, dx
mov input, al
}

Normally, this causes an AV. Any ideas?

[Steve Maillet (eMVP)]

Use the CEDDK functions READ_PORT_UCHAR and WRITE_PORT_UCHAR, etc... include
CEDDK.H and link to CEDDK.LIB

[Michael Schwab]

Hmm, maybe I misunderstood you before.

Can you use the CEDDK calls from a regular program (not just a driver)?

I experimentally tried compiling it, and for some reason ceddk.h was in the
SDK from Advantech, but I could only find ceddk.lib under Platform Builder:
GEODEPAD\WINCE420\Geode\cesysgen\oak\lib\x86\retail. When I linked to that,
it compiled and built OK. I don't know yet if it actually talks to the
hardware or not.

If these calls do actually read/write my hardware I/O ports, does that mean
that Advantech supplied these calls?

Are there 16-bit versions of these calls? (Nevermind - I'm off to help to
answer that one).

Michael Schwab

Post by Steve Maillet (eMVP)
Use the CEDDK functions READ_PORT_UCHAR and WRITE_PORT_UCHAR, etc... include
CEDDK.H and link to CEDDK.LIB
--
Steve Maillet (eMVP)
EmbeddedFusion
smaillet_AT_EmbeddedFusion_DOT_com

[Michael Schwab]

Answered my own questions.

OK, Steve, you're right.

I replaced the _asm macro stuff in my inpw/outpw routines with lines like
this:
WRITE_PORT_USHORT((unsigned short *)addr,data);
included ceddk.h, and copied ceddk.lib from PB to my SDKs library area, and
it works like a champ!

Since I don't have a ceddk.lib for CE 3.0, I probably won't be able to get
this to compile under 3.0, but that's no great loss.

Why is this better, now? These calls are somehow platform independent? How
do they handle the differences between processors that do or do not have
special I/O access instructions?

Michael Schwab

Post by Michael Schwab
Hmm, maybe I misunderstood you before.
Can you use the CEDDK calls from a regular program (not just a driver)?
I experimentally tried compiling it, and for some reason ceddk.h was in the
GEODEPAD\WINCE420\Geode\cesysgen\oak\lib\x86\retail. When I linked to that,
it compiled and built OK. I don't know yet if it actually talks to the
hardware or not.
If these calls do actually read/write my hardware I/O ports, does that mean
that Advantech supplied these calls?
Are there 16-bit versions of these calls? (Nevermind - I'm off to help to
answer that one).
Michael Schwab

Post by Steve Maillet (eMVP)
Use the CEDDK functions READ_PORT_UCHAR and WRITE_PORT_UCHAR, etc...

include

Post by Steve Maillet (eMVP)
CEDDK.H and link to CEDDK.LIB
--
Steve Maillet (eMVP)
EmbeddedFusion
smaillet_AT_EmbeddedFusion_DOT_com

[Dean Ramsier]

This makes it source code compatible, these commands are available in every
ceddk implementation regardless of processor. You won't have to modify your
code as you move from platform to platform. You'll still have to recompile
for every target, as every target supplies it's own ceddk.lib to link
against.
--
Dean Ramsier - eMVP
Accelent Systems
http://www.accelent.com

Post by Michael Schwab
Answered my own questions.
OK, Steve, you're right.
I replaced the _asm macro stuff in my inpw/outpw routines with lines like
WRITE_PORT_USHORT((unsigned short *)addr,data);
included ceddk.h, and copied ceddk.lib from PB to my SDKs library area, and
it works like a champ!
Since I don't have a ceddk.lib for CE 3.0, I probably won't be able to get
this to compile under 3.0, but that's no great loss.
Why is this better, now? These calls are somehow platform independent?

How

Post by Michael Schwab
do they handle the differences between processors that do or do not have
special I/O access instructions?
Michael Schwab

Post by Michael Schwab
Hmm, maybe I misunderstood you before.
Can you use the CEDDK calls from a regular program (not just a driver)?
I experimentally tried compiling it, and for some reason ceddk.h was in

the

Post by Michael Schwab
SDK from Advantech, but I could only find ceddk.lib under Platform
GEODEPAD\WINCE420\Geode\cesysgen\oak\lib\x86\retail. When I linked to

that,

Post by Michael Schwab
it compiled and built OK. I don't know yet if it actually talks to the
hardware or not.
If these calls do actually read/write my hardware I/O ports, does that

mean

Post by Michael Schwab
that Advantech supplied these calls?
Are there 16-bit versions of these calls? (Nevermind - I'm off to help to
answer that one).
Michael Schwab

Post by Steve Maillet (eMVP)
Use the CEDDK functions READ_PORT_UCHAR and WRITE_PORT_UCHAR, etc...

include

Post by Steve Maillet (eMVP)
CEDDK.H and link to CEDDK.LIB
--
Steve Maillet (eMVP)
EmbeddedFusion
smaillet_AT_EmbeddedFusion_DOT_com

[Steve Maillet (eMVP)]

The implementation of CEDDK is platform specific. Most of the time platform
developers using Platform Builder simply use the standard CPU specific
versions from MS. Ultimately to be the most portable you combine the port
and register functions with TansBusAddressToVirtual() to handle any platform
specific bus location mapping. Consider a device with 2 PC/104 connectors
and a PCI bus. Perhaps the second PC/104 is actually memory mapped even for
I/O accesses and the hardware handles the timing differences to allow for
independent buses. TransBusAddressToVirtual will take care of that and you
use the port functions the same in either case. You just need to know if you
have to unmap the memory addresses with MmUnmapIoSace afterwards.
While it may not matter on just one device. Getting into the habit of
writing your device access code in a platform neutral fashion will save you
troubles in the long term as you work on other devices. (e.g. don't limit
yourself to one platform unless you have no other choice)

[bigwave]

Steve Maillet (eMVP) wrote on 05/06/2004 12:03 ET

Post by Steve Maillet (eMVP)
The implementation of CEDDK is platform specific. Most of the time platfor
developers using Platform Builder simply use the standard CPU specifi
versions from MS. Ultimately to be the most portable you combine the por
and register functions with TansBusAddressToVirtual() to handle any platfor
specific bus location mapping. Consider a device with 2 PC/104 connector
and a PCI bus. Perhaps the second PC/104 is actually memory mapped even fo
I/O accesses and the hardware handles the timing differences to allow fo
independent buses. TransBusAddressToVirtual will take care of that and yo
use the port functions the same in either case. You just need to know if yo
have to unmap the memory addresses with MmUnmapIoSace afterwards
While it may not matter on just one device. Getting into the habit o
writing your device access code in a platform neutral fashion will save yo
troubles in the long term as you work on other devices. (e.g. don't limi
yourself to one platform unless you have no other choice
Steve Maillet (eMVP
EmbeddedFusio
smaillet_AT_EmbeddedFusion_DOT_co

Hi

Can the CEDDK functions READ_PORT_UCHAR and WRITE_PORT_UCHAR, etc... be use
with Windows CE 5.0? What about Windows CE 6.0

Thanks

David