Driver development - need advice on approach

[NCLS]

Coming from C++, I would like to find out from the community what would be some right ways to develop 32-bit register-based RS422/485 communication card with DMA controller in LabVIEW 7.x (SuperFastcom card from Commtech, Inc. just in case anyone wants to know the device). The device is working great right now in the NI PXI embedded controller chassis running Windows XP but soon the test environment will be switched over to LabVIEW RT. In reading the "Configuring LabVIEW Real-Time and NI-VISA to Recognize a Third Party Device," I when through the VISA Driver Development Wizard and under MAX the card is being recognized, which allows me to rename with a different alias. However I skipped the "Generates interrupt" checkbox for now because I don't yet have the familiarity the steps to mask/unmask registers. I don't want to develop a general purpose driver, but what I do want is to initialize/reset the card, configure one of the four channels to be able to transmit/receive SDLC protocol via interrupt, and terminates whenever the test application ends. In that regard, will LabVIEW with NI-VISA be the most appropriate approach or do I need to consider LabWindow/CVI since all of the vendor's files are in .c files?

[LoganS]

I would recommend building the vendors .c files into .dlls, and call those functions from LabVIEW. Is this how you are currently controlling the board? If so, keep at it - you can still call .dlls from LabVEIW RT. But this is just my recommendation.

Logan S.

[NCLS]

Well, currently in the test computer the board is running under Windows XP environment thus the low level stuff is being taken care of by its Windows driver and in the C++ test software application there are some registers being set and few driver functions being called. The missing link seems to be what once used to be transparent to user (windows driver) have to be implemented in the LabVIEW RT O/S and there doesn't seem to be a simple way other then to be really intimately knowledgeable with how the card's DMA is implemented and how to correctly setup system memory into descriptor blocks, and probably tons other stuff that I'm missing from the top of my head...

[Shawn B.]

NCLS,

You may be able to write your own driver in C and build it into a DLL, or you could use VISA to perform all of the register level programming. Either way you will have to have in depth knowledge of the board like you mentioned.

You best be might be to buy one of the PXI-8431 boards which is already supported in RT and save yourself some of the hassle.

Shawn B.
National Instruments

[Ben]

I do not think this is a viable solution unless additional hardware is used to convert to SDLC OR the transfer rates are low. I have seen these gizmo's offered by Black Box that will handle transfer rates up to about 100 Kb.

I have not looked into this recently.

I wrote a driver for the "FASTCOM ESCC-PCI Dual channel sync/Async serial interface" about 5 years ago.

If this new board is similar to the one I worked with, then I would recomend using VISA and break out the manual for the chip.

If your trasfer rates are low enough, go with the converter.

Post follow-ups if you think there is more we can offer.

Ben

FYI:
SDLC is a sub-set of HDLC originally devloped by IBM. It uses "bit stuffing" that ensures the sync byte never occurs in the data stream. Doing bit-stuffing in code could be challenging if the transfer rates are high.

Message Edited by Ben on 04-20-2005 07:19 AM

[NCLS]

Yes Ben, the SuperFastcom card uses Infineon chip which is a 32-bit extended version of the ESCC chip on the Fastcom card. The SDLC messaging in our application needs to be at 1Mbps rate. As for bit stuffing, the hardware does it for you once it is configured on any of the 4 ports used for transmission. The learning curve that I'm struggling with is that there is a method that uses VISA via Labwindow/CVI and then there is VISA via Labview. I would prefer to implement the driver in native Labview (graphical programming) but this method is less intuitive to me coming from c++ at the moment. What I'm doing now is going through the motion of implementing a driver in Labview via VISA for a Pickering 16-SPDT relay card and see how things work. It doesn't help me in understanding how to implement low-level stuff like interrupt handling because there is none, but at least it's hands on practice.

[Ben]

OK,

First check with Black Box to see if their hardware has gotten fast enough. I needed to do 2 Mbaud so I had to do the driver thing.

BTW: Every time I have had to do an SDLC project (in this millenium) it involved an organization that started with the letters "Nor".

If this is the case with you, contact me off list at "bar@dsautomation.com" and I may be able to put you in contact with other "Nor" people.

At the very least you maybe able to share the pain with someone else that is going through a similar challenge.

Ben

[marv8]

I am working with a SuperFastcom board also and would be interested if you come up with any driver solutions that are of a Labview flavor. I am a bit new a this, so developing a driver for this seems a bit much at this stage but still interested in discussion and pointers.

Thanks
Marv

[JLS]

Hello,

Just a note: I don't have such a driver but you may try contacting the manufacturer. Otherwise, hopefully our other friends will post with their work for you 🙂

Best Regards,

JLS

[NCLS]

As a side note, National Instrument is interested on what driver to develope, if you all would go to http://www.ni.com/devzone/idnet/ and click on Driver Request and fill in the instrument information regarding SuperFastcom, example info is attached, it would great.