SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Thu, 20 May 1999 07:07:54 PDT
From:	Peter Skye <pskye@peterskye.com >
Reply-To:	scoug-programming@scoug.com
To:	scoug-programming@scoug.com
Subject:	SCOUG-Programming: #5

Content Type: text/plain

Hi Ben, :)

Benedict G Archer wrote:
>
> ... plug-in ADC and digital IO cards to sample and
> collect data (analog or video line) and contorl
> devices (e.g., shutters, flash lamps, pulsed lasers,
> galvo-scanners, array sensors such as a linear diode
> array or ccd). The cards have been various, ...

You need to decide _which_ cards you want drivers for. It's okay to
have a long list, but the drivers do need to know what they're
controlling - you can't start without the list. :)

> ... all with DOS drivers and usually with a
> library of functions (supplied with the card) ...

Ask the vendor if the source code for the DOS drivers is available.
Steve's correct that the device control code is the same.

> ... a little graphics for simple real time data
> display ...

This will be done outside of the driver.

> Until recently most of the post acquisition data
> analysis has been in OS/2 ...

Excellent choice. :) But what happened "recently"?

> ... The cards have programmable timer chips which
> enable one-shots, programmable gates etc.

This is why you need the specification sheets for the cards (see my
original note). When you say "programmable gates", you're inferring
that you have to send information to the card. Is this a simple setup
procedure that's done once at power-on, is always the same, and can be
embedded in the driver? Or is it necessary to change the programming of
the gates during operation (requiring some "I/O Control"
functionality)? And, if the programming must be changed during
operation, must the changes be based on the programmable timer chips
(i.e., every 150 milliseconds you want to switch the inputs using an
on-board multiplexor and you want to stretch your timing samples so you
sample at 5, 15, 50, 150 milliseconds)? (If you're _really_ into this,
I made the first sample at 5 milliseconds so the input could settle
after switching.)

Also, you said in paragraph 1 that you were sampling a video line (is
this a 1-by-x sensor array or an NTSC video feed?) -- are you using the
on-board timers to signal when the card should do data capture?

> My naivete must be obvious, ...

Ben, you and I are fellow Mathematicians. There ain't nuthin' a
mathematician can't do. :))

> I'm anticipating Peter's tutorial as a start towards
> understanding what the task I'm contemplating entails.

It's _not_ that difficult. I'd recommend you not write a _video_ _card_
driver during your lifetime, but the rest of the world is easy to
control.

> More and more of the available cards are PCI rather
> than ISA

Shouldn't make any difference. The ISA bus is stubbed off of the PCI
bus these days (the "south bridge" chip).

Okay, here are some considerations:

-- When the driver loads, it can look at command line switches you set
(which means you have to modify CONFIG.SYS if you change cards) or it
can look around and see what cards you've got in the machine in which
case you'll need the spec sheets for the cards so you know how to
identify a card (often done by reading some ports and seeing if you get
back some expected values).

-- If the card is a smart card it will have a buffer that stores its
samples (or it will do DMA) and you can just check "every once in a
while" and see what's there. If it's a stupid card it will issue an
interrupt every time it's got a sample ready and your driver will handle
the interrupt.

-- If the card _does_ do DMA your driver has to ask the OS/2 kernel for
a DMA channel. Make sure you know which kind of DMA the card does.

-- That bain of programming, the FLOWCHART, comes in handy when you're
trying to understand what you're doing (or explain it to others).
Timing diagrams (if you don't know what they are don't worry) are also
helpful if you're using the on-board timers.

-- Most of the work is done up front, before you write the code. You
have to understand how your card works, how you want to communicate with
it, what card functions you want to support, what (if any) error
recovery you want to implement (for example, if a timer goes off a
second time before it's serviced the card might give you an alert).
"Once you know what you want to do", writing the code is (almost)
trivial.

- Peter Skye

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 20 | May | 1999 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.