From: perkel AT slice DOT etho DOT caltech DOT edu (David J. Perkel) Subject: Data acquisition under DJGPP (SUMMARY) To: djgpp AT sun DOT soe DOT clarkson DOT edu Date: Tue, 28 Feb 1995 10:04:38 -0800 (PST) Hi DJGPPers, A while back I posted a question about data acquisition under DJGPP. I got some helpful answers, but have not yet posted a summary. Here it is, following an update on where I am with my goal, and a request for further help. I have managed to get some code to work for the Tecmar (Scientific Solutions) Labmaster AD. Raw analog and digital input and ouput work. My sticking point is with DMA. Following the example in the sblaster.zip package, I have successfully allocated a DMA buffer, but data transferred by DMA do not find their way to that buffer. Sometimes the machine hangs, suggesting that I'm either not sending the DMA address to the right place and some uninitialized value for the location is being used or that I'm sending the wrong value. Fundamentally I guess I don't understand how DMA transfers work. The tech support person at Tecmar couldn't help with protected mode, but he did say that the peripheral never gets the address; rather, we pass the DMA transfer address to the DMA controller on the mother board. Is that correct? Is there more recent sound card code that might give me a clearer idea of how to do this? Pointers to information on this type of thing? Books or articles on the net? (Remember, a summary follows. Thanks to all who replied.) Thanks in advance for your help. -- David J. Perkel perkel AT slice DOT etho DOT caltech DOT edu Division of Biology, 216-76 California Institute of Technology Pasadena, CA 91125 Tel: (818) 395-6816 FAX: (818) 449-0679 ------------------------- Summary ------------------------- First the original query: > Has anybody tried using djgpp to control one of the popular data > acquisition cards (Nat. Inst.; Scientific Solutions/Tecmar; Metrabyte > ...)? How hard would it be to convert C libraries written for bcc that > control the cards? Obviously one would need to handle different-sized > data types, but I'm wondering whether there's some particularly nasty > sticking point. Piet=Mertens%users%LW AT cc3 DOT kuleuven DOT ac DOT be mentioned having some code for the Metrabyte DASH-16. The code uses polling and achieves acquisition rates of 20-40 kHz, depending on CPU speed. Works under DJGPP 1.11m5. He would also me interested in code for the Tecmar Labmaster or Data-Translation DT2821. jordi AT phyast DOT pitt DOT edu (Jordi Ignes) would be interested in code for the Labmaster . Mark Lee requested source code from Metrabyte, and was able to get it to compile with DJGPP. However, only the polling mode worked. DMA or interrupt modes made the whole computer lock up. Sample rates: 2-4 kHz on a 386DX-33, 3-5 kHz on a 486 DX66. craig AT pot DOT noao DOT edu (Craig Gullixson) wrote: I've just finished with converting two of the libraries from a Symmetric Research DSP board. The libraries were set up to be compiled using bcc and msc. Besides the should an int become a short question, I found most of the conversion to be pretty straight forward. He doesn't mention whether he's using DMA, and I haven't followed up yet. (Comments, Craig??) Mark Lee wrote: I asked the same question a while back about controlling a Metrabyte DAS50 A/D board. I tried it with the native C libraries that came with the board and it works with Scan mode only. If you tried DMA or Interrupt acqusition, (which requires you to specify a segment/offest address for the buffer) and passed the _go32_dpmi_allocate_dos_memory memory addresses to the board, the board works sometimes but most often it hangs. I haven't found a fix to this problem yet but another guy here with a DAS16 board has the same problems. It might be a kludge unique to the Metrabyte boards. Cameron Davidson wrote I use GCC and libgrx for a/d conversion on ComputerBoards cards (Metrabyte look-alike DAS-08s and DAS1600s I think). I wrote a library (all in C) originally for MS-C 5.1 and with a few changes it works with GCC: i.e. int to short and port i/o routines having different names (they might be the same between BCC and DJGCC). However, I do not do anything fancy. It just uses polled port i/o, no DMA. Roland Exler wrote: We are writing code for the Nat.Inst.GPIB and an AD/DA-Card right now and as far as we checked the code coming with the cards we'll rewrite most of the assembler-parts in C/C++. The C-Code itself seems to be converted straight forward. john miller provided an intriguing suggestion: "The approach described in the following two programs is an attempt to allow 32 bit programs compiled with DJ's gcc dos port to work with 16 bit libraries. This may only be of interest for users who wish to acquire image data using frame grabbers or linear camera interfaces although others may find the following technique useful. "The basic technique here is to create a 16 bit program that will link with libraries provided for some given hardware and pass parameters to a 32 bit program using a system command. In effect, the 16 bit program becomes a pseudo TSR but without the problems that are frequently encountered with TSRs. The 32 bit program calls the required 16 bit function using the appropriate dpmi function (_go32_dpmi_simulate_fcall_iret) and memory is read using the dosmemget function. In a similar fashion, data could be written using dosmemput. "By any standard this approach is kludgy but it is relatively simple and foolproof and uses a minimun of specialized coding. Anyone wishing to make improvements to the following code is encouraged to do so with a request to share the improvements with the list. Special thanks are due to DJ and Charles Sandmann for their expert help and suggestions. [Example programs deleted] I have tried this and the basic concept works. However, the scheme did not work for my libraries. I have not figured out why not. Possibly this is due to some blunder on my part or to some real incompatibility between the 16-bit libraries that I have and this approach. Don't know, but would like to find out, because this approach would work with binary-only libraries from companies that don't want to release source code. Thanks to all who replied!!! -- David J. Perkel perkel AT slice DOT etho DOT caltech DOT edu Division of Biology, 216-76 California Institute of Technology Pasadena, CA 91125 Tel: (818) 395-6816 FAX: (818) 449-0679