PCI-6503 configuration - split port C

[edyoho]

Quite a few years ago I wrote a program that used a DIO-24 to read and write data from a test fixtrue with FIFOs and other junk on it. I could not find a clean way to configre the 8255  in mode 0 with ports A, B, and C_lo_nibble as inputs and C_hi_nibble as output with any of the supplied NI code.

At the time the solution was to use WriteToPhysicalMemory and ReadFromPhysicalMemory as below:

// configure 8255

    Get_DAQ_Device_Info (1, ND_BASE_ADDRESS, &dio24_base);
    dio24_portA=dio24_base;
    dio24_portB=dio24_base+1;
    dio24_portC=dio24_base+2;
    dio24_control=dio24_base+3;
    sb[0]=0x093;    WriteToPhysicalMemory ( dio24_control, sb, 1);
//

Over the years newer similar projects switched to PCI-6503s and all worked fine until a NI security patch removed support for WriteToPhysicalMemory and ReadFromPhysicalMemory and other direct memory access.

See:

<http://digital.ni.com/public.nsf/allkb/A07451671E7263598625792800677970>

The simple DIG_Prt_Config does not seem to support split input/output on the 8255's port C.

Can anyone point me in a relatively simple method of regaining split I/O on port C of the 6503?

Thanks in advance,

Ed Yoho

[Emily-C]

Hi edyoho,

The White Paper on Digital I/O Applications explains how to configure the 8255 to split port C. The Appendix at the bottom of the document shows example code for getting this set up.

I hope this helps!

[edyoho]

Emily,

Thanks for your response. Using "outc()" worked with the old ISA DIO-24, but I don't think it will work with a PCI-6503. From what I remember (and I'm half senile), the port range is 0 to 0x03ff or so.

Using the function:

    Get_DAQ_Device_Info (1, ND_BASE_ADDRESS, &dio24_base);

to determine the PCI-6503's base address returns:

-264126464

example code:

//////////////////////////////////////

 static unsigned long dio24_base=0, dio24_control=0,
            dio24_portA=0, dio24_portB=0, dio24_portC=0;

    dio24_base = 0;

    Get_DAQ_Device_Info (1, ND_BASE_ADDRESS, &dio24_base);

    dio24_portA=dio24_base;
    dio24_portB=dio24_base+1;
    dio24_portC=dio24_base+2;
    dio24_control=dio24_base+3;
 
   outp(dio24_control, 0x093); // set 8255 to Ain, Bin, Clo_nibble_in  (or should)
   outp(dio24_portC, 0x000);
   outp(dio24_portC, 0x010);
   outp(dio24_portC, 0x020);
   outp(dio24_portC, 0x030);
   outp(dio24_portC, 0x040);
   outp(dio24_portC, 0x050);
   outp(dio24_portC, 0x060);
   outp(dio24_portC, 0x070);
   outp(dio24_portC, 0x000);

//////////////////////////////////////

With brealpoints at each line does nothing on the 8255 port C outputs.

As an alternative to using WriteToPhysicalMemory, using WriteToDigitalPort() would work fine as a replacement, except it doesn't seem to allow splitting port C.

Ed Yoho

[Emily-C]

Hi edyoho,

Can you please try setting the mode as well, as shown in the example? The manual also has more information on these settings, starting on page B-17.

Thanks!

[edyoho]

Emily,

The initial refererenced document (Digital I/O Applications) uses the outp() function and then "ors" the required configuration bits to create an eight bit word with the binary value of 10010011 for split port C operation.

The line:

outp(dio24_control, 0x093);

is the configuration statement and is sending an eight bit word with 10010011 in it (Mode 0 Number 11) to the address. as found by:

    Get_DAQ_Device_Info (1, ND_BASE_ADDRESS, &dio24_base);

The problem is "outp()" was designed way back at the beginning of the PC world (8086 / EGA days) and was limited to addresses from 0 through 03FF (or maybe 03F0, I can't remember for sure).

If the module was an ISA based device, this would still work. When using a PCI interfaced device, the module address is well outside the area defined above.

If you look at B-11 "PCI Initialization for the PC", you will be a bit closer. This is close to what I did when switching from the old ISA DIO-24 (that used outp() and inp() functions) to the PCI-6503.

When switching from ISA to PCI quite a few years ago, I discovered the built in configuration functions within Labwindows still did not seem to support splitting port C on 8255s. That is when I started using the WriteToPhysicalMemory and ReadFromPhysicalMemory as direct register write/read.

Unfortunately, National has removed WriteToPhysicalMemory and ReadFromPhysicalMemory and now I am stuck looking for a replacement.

What I am looking for / in need of is a replacement for the two deleted functions that will allow me to directly read/write the 8255. Unfortunately, outp() and inp() won't do it (I tried it with the remote possibility NI had rewritten the functions to work with PCI addresses).

Ed Yoho

[Emily-C]

Hi edyoho,

Have you tried running as an administrator using your original implementation? I'm still looking into it, but it looks like administrative privileges might have to do with the discontinuation.

I'm still doing further research into how else to do register-level programming on the PCI-6503. At this point in time this sounds like an issue that might be better handled through a service request with NI Support. If you have support with us, please consider opening a request to look into this issue further.

Thanks,

[edyoho]

Emily,

I have been running as administrator.

The problem exists because NI removed the two functions in question (WriteToPhysicalMemory and ReadFromMemory). Please see:

<http://digital.ni.com/public.nsf/allkb/A07451671E7263598625792800677970>

There should be (actually needs to be) a replacement for the removed memory read/write functions. Whatever they are called (if they exist), I have not been able to find them.

Or at least a way for users to still use the removed commands with the understanding it could be a security risk.

As it is, all of the ADC test packages I have developed for clients that use PCI/PXI parallel cards are in jeopardy.

I am under a service agreement for LabView, but not LabWindows as I normally do not use it any longer. This problem cropped up as a customer had asked me to make a simple change to a test package they have been using for years that I had developed using LabWindows.

Ed Yoho

[Emily-C]

Hi Ed Yoho,

As long as you have a support contract with us you are able to open a service request. It should be fine to open a service request for this issue even though you technically have support for LabVIEW. 

Please feel free to reference this forum link in the service request so that we can see all the information we've collected so far. 

Thanks!

[edyoho]

Emily,

Thanks for trying to help. I have contacted NI's support system on the phone. Hopefully they will be able to resolve this.

Ed Yoho