Mail Archives: djgpp/1995/02/28/13:20:32
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 <mlee AT heartlab DOT rri DOT uwo DOT ca> 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 <mlee AT heartlab DOT rri DOT uwo DOT ca> 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 <C DOT Davidson AT janus DOT cat DOT csiro DOT au> 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 <R DOT Exler AT jk DOT uni-linz DOT ac DOT at> 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 <jwvm AT umdsun2 DOT umd DOT umich DOT edu> 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
- Raw text -