Devolping a driver for the M-Series cards, documentation is hopelessly out of date

[Joshua.Chambers]

I'm trying to develop a driver for the AO side of the M-series 6529 that will allow me to use the board on an xPC target.  I got the AI side working right away by emulating the old E-series driver.

The register map for the M-series is from 2005 and still says Prelimenary, it is not nearly desciptive enough to be useful on it's own.

The example code is nearly as cryptic when you get down to the lower levels.

Is there any updated documentation hiding somewhere?  Maybe a prerelease version of a real DDK manual???


Thanks

[Jeremy_C]

The preliminary document from 2005 is still the most current documentation.  I realize the existing documentation is not enough on its own, but that document in conjunction with the examples is usually enough to get started.  Any specific questions that aren't answered in the documentation or examples can be posted to this discussion forum.  What specific problems are you experiencing with programming the AO of the 6259?

Message Edited by Jeremy C on 03-13-2007 04:23 PM

[Joshua.Chambers]

Well basically anything that will give me a sign I've got something working would be good.  I architecture for the driver I'm writing is necessarily pretty different from the examples, so I've got a lot of different code mixing together badly.

Is there some quick way I can make sure I've got my base address and my basic direct access read and write functions set up right?

Then I'm a little confused about whether the offsets alway apply to the base address, or whether they apply to some other base or offset in certain situations...
for instance the AO_Waveform_Order offsets start at 0xc2 and the AO_Config_Bank offsets start at 0xC3...there aren't too many ways this make sense to me.


Thanks,

Josh

[Joshua.Chambers]

The xPC code I'm working with uses the old DAQ-STC windowed mode access routines throughout.

Do the M-Series cards require the use of windowed mode?  It doesn't look like it from the examples, but it seems like the M-series have windowed mode functionality.

[Joshua.Chambers]

in the example code scale.cpp

u32 getCalibrationAreaOffset (const u8 *eepromMemory)
{
    return (eepromMemory[kCalibrationAreaOffset] << 😎 | eepromMemory[kCalibrationAreaOffset+1];
}

Should there be extra parentheses, so that the result of the OR is returned?:

u32 getCalibrationAreaOffset (const u8 *eepromMemory)
{
    return ((eepromMemory[kCalibrationAreaOffset] << 😎 | eepromMemory[kCalibrationAreaOffset+1]);
}

[Jeremy_C]

In response to the questions above:

-The offsets for the various registers always refer to BAR1 as the base address.

-M Series do not use windowed mode.  It was determined that direct mode addressing was better for several reasons, so that was implemented for M Series.

-Yes, the result of the OR should be returned. 

I hope this helps.

[Joshua.Chambers]

That helps a bit.  I'm still having a bear of a time seeing anything that actually works.

For instance I seem to be able to get the EEPROM data to show up in memory, but I can't seem to find the gains and offsets I need.  For analog ou

            readEEPROM_m(bar0, bar1, 1024, EEPROMData, 1024);
            caloffset = (EEPROMData[kCalibrationAreaOffset] << 😎 | EEPROMData[kCalibrationAreaOffset+1];

                offset = caloffset + kAoIntervalBlockStart + (0*kAoIntervalBlockSize) + (0*kAoChannelBlockSize);
                printf("%04d %04d\n", offset, offset-caloffset);
                tempf32.b[0] = EEPROMData[offset+0];
                tempf32.b[1] = EEPROMData[offset+1];
                tempf32.b[2] = EEPROMData[offset+2];
                tempf32.b[3] = EEPROMData[offset+3];
                gain[i] = tempf32.f;
                tempf32.b[0] = EEPROMData[offset+4];
                tempf32.b[1] = EEPROMData[offset+5];
                tempf32.b[2] = EEPROMData[offset+6];
                tempf32.b[3] = EEPROMData[offset+7];
                Voffset[i] = tempf32.f;

caloffset shows up as 0x0300, whichs seems strange since this puts the mode and interval blocks for channels 3 and 4 outside the 1024th element of the EEPROM data, according to the offsets in scale.cpp.

Big or little endian make no difference, the floats I get are usually either 0.00e+000 or something like 2.34e+-038.

The read EEPROMdata function is basically identical to the example in scale.cpp.  I'm not entirely sure bar0 and bar1 are being set correctly, but it looked like when the read function wasn't working, almost all of the memory in EEPROMdata was set to FF.

[Jeremy_C]

calOffset should be 0x190 for the 6259.  It's possible that BAR0 and BAR1 are not being set correctly.  Are you using an OS interface that was provided with the MHDDK or are you using a custom one?  Can you tell me more about the OS you are using?

[Joshua.Chambers]

I'm using xPC.   It's a real-time OS used by Matlab and Simulink for running compiled Simulink models on x86 targets.  I haven't delved very far into the details of the xPC PCI routines, but I can take a look and let you know what I find...

Is there anything in particular I could check for right away?  Physical addresses or anything else?

It seems that BAR1 is in the right place, since I can get an AI reading (although the FIFO seems to be behaving a little funny).

One thing I recently realized I've been doing wrong is assuming I can read from the registers the data that I recently wrote to them... Correct me if I still mistaken, but any memory in BAR1 can represent something completely different when I'm reading it versus when I'm writing it.  If a register is not explicitly read/write can I ever expect to read it and find out what I had written there previously?

[Joshua.Chambers]

Alright I'm working on the AI side of things and avoiding the EEPROM for now.  I can confirm that I can write to most of the registers I'm supposed to, and I can read AI_Status_1, and the two Joint_Status registers.

I set everything up just like in aiex1.cpp, but instead of getting data, the scan never finishes.

START_st and START1_st just sit high along with AI_Scan_In_Progress_St, AI_FIFO_Empty_St, AI_EOC_St, and AI_SC_Gate_St.

Can anybody tell me what AI_EOC_st and AI_SC_Gate_st really mean, and whether or not they might be indicating what the problem is?

Any clues about what might cause an infinitely long scan?