Heres an example of an hw i/o output although note that I’ve wrapped up the
in/out macros into a wrapper class (Reg0_m is just a 16bit private class
member variable)
Am I being paranoid then by mapping the io address in and unmapping it as
part of the function - I noticed that pete said just map it in once in main
or is this down to the individuals taste…
***/
void CNonVolGateArray::ResetExternalModules(void)
{
int port,a;
a=ThreadCtl(_NTO_TCTL_IO,0); // need these two lines here to inform
neutrino that we are going to access something outside of this process’s
address space
port = mmap_device_io(1,NON_VOL_GATE_ARRAY_BASE_ADDR+0); // so we remap the
physical addr into this processes addr space
Reg0_m &= ~EXTERNAL_RESET_BIT;
OIoClass.OutputWord (port, Reg0_m);
munmap_device_io(port,1); // free access to the mapped io area
}
pete@qnx.com wrote in message <8s2atn$3ms$1@nntp.qnx.com>…
J. Scott Franko <> jsfranko@switch.com> > wrote:
I’ve read the migration doc’s and I’ve changed the code to do a
ThreadCtl(_NTO_TCTL_IO, 0);
Good…
and it says I should add an mmap_device_io() but I am unsure of the
parameters. Should it be
mmap_device_io(1,TOGGLE_BASE); ?
Yes, but you should probably map both ports at the same time since
they are right next to each other.
You should also use the uintptr_t that mmap_device_io() returns to
actually pass in to the in*() calls.
Do I need to do this only once for the whole process at the beginning of
main? Why use two addresses to access this parallel port?
Yes… just do this once.
You need two addresses because the port occupies two I/O locations. You
could just get a mmap_device_io() return for the first address, and then
add an offset to it to access the second, providing the size you passed
into mmap_device_io spanned both port locations.
and then it says I should use in8 and out8. They don’t use plain int
parameters anymore. Will the same parameters I use in inp and outp
work?
You should actually use the number returned bu mmap_device_io for the port
location in in* and out*
The reason it’s done this way is so that if you ever port your code to
another processor, all the in and out stuff will just work, even though the
other processors don’t actually have real in and out instructions. On other
platforms, in and out instructions are usually simulated by doing memory
mapped accesses to a special address range. You’ll notice that the numbers
returned by mmap_device_io and in*() and out*() are big enough now to
hold a pointer > 
I’ve changed the outp occurence and it compiles, but I’m now working on
chaning Trigger and Receive (gotta learn how pulses differ from proxies
and how to implemnt) calls that come up in the link of this same
process, so I’m not sure yet if the out8 call is working.
Don’t use port numbers directly in in and out calls. Use the number
returned from the mmap_device_io call.
