Direct I/O port access
Jason Spence
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)
CEDDK.H and link to CEDDK.LIB
--
Steve Maillet (eMVP)
EmbeddedFusion
smaillet_AT_EmbeddedFusion_DOT_com
Michael Schwab
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
"Steve Maillet (eMVP)" <nos...@EntelechyConsulting.com> wrote in message
news:uX28m64L...@tk2msftngp13.phx.gbl...
Michael Schwab
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
"Michael Schwab" <michael...@cobecv.com> wrote in message
news:e241BeiM...@TK2MSFTNGP12.phx.gbl...
Dean Ramsier
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
"Michael Schwab" <michael...@cobecv.com> wrote in message
news:uod6FqiM...@TK2MSFTNGP12.phx.gbl...
Steve Maillet (eMVP)
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
> EmbeddedFusion
> smaillet_AT_EmbeddedFusion_DOT_com
>
Can the CEDDK functions READ_PORT_UCHAR and WRITE_PORT_UCHAR, etc... be used
with Windows CE 5.0? What about Windows CE 6.0?
Thanks,
David