Data acquisition Card- How to use with C?

[Ulysses]

Could someone tell me how to go about getting data from a data
acquisition card using C?...<Just general information would also
help........I'm just working on an idea at the moment>.

 

[Lew Pitcher]

Could someone tell me how to go about getting data from a data
acquisition card using C?

No, and yes.

In general, C does not provide device specific support, and no one
here can tell you how to use C to retrieve data from a DAC.

However, should your system and environment be suitably configured,
you may be able to use the C standard fopen()/fread()/fclose()
functions to retrieve data from your device. This, of course, assumes
that your C environment provides an fopen() compatable name for the
DAC, and the underlying system and environment connect that name to
the device. This is possible in some systems (like Unix) where devices
are externalized as files, have filenames, and can be opened and read
like files (i.e. fopen("/dev/ttyS0","r"); )

 

[CBFalconer]

Could someone tell me how to go about getting data from a data
acquisition card using C?...<Just general information would also
help........I'm just working on an idea at the moment>.

In standard C you will need to use file operations. You may need
to build a driver.

 

[Chris Hills]

In standard C you will need to use file operations. You may need
to build a driver.

This is probably incorrect... it depends in what your card does, what
sort of hardware you are plugging your card into which, if any, OS you
are running on your Hw.

You might do it as suggested with files access or you might do it with
direct register access...

 

[CBFalconer]

This is probably incorrect... it depends in what your card does,
what sort of hardware you are plugging your card into which, if
any, OS you are running on your Hw.

You might do it as suggested with files access or you might do it
with direct register access...

Please demonstrate how to set up legal direct register access in
STANDARD C (no extensions). Quote the enabling lines from N869
please.

 

[Chris Dollin]

This is probably incorrect... it depends in what your card does, what
sort of hardware you are plugging your card into which, if any, OS you
are running on your Hw.
Verily.

You might do it as suggested with files access or you might do it with
direct register access...

They're both outside the scope of the [1] standard, though. (File operations
themselves aren't, but connecting a file-like thing to a device is.)

The answer is: it depends on what your local implementation offers. You'll
have to find out.

[1] C90 or C99. Other standards may apply, but I've no idea what they'd
be. Other de-facto conventions may apply; I don't know what those
are either.

 

[Chris Hills]

Please demonstrate how to set up legal direct register access in
STANDARD C (no extensions). Quote the enabling lines from N869
please.

No. Use extensions. We are talking SW engineering not religious
bigotry.

BTW N869 is NOT standard C Standard C is ISO9899:1999

 

[CBFalconer]

No. Use extensions. We are talking SW engineering not religious
bigotry.

You can get away with that in comp.arch.embedded, but not here.
This newsgroup discusses PORTABLE standard C.

 

[Chris Hills]

You can get away with that in comp.arch.embedded, but not here.
This newsgroup discusses PORTABLE standard C.

No we discuss the use of C

If you want to only discuss portable standard C that is up to you... go
find some one else to bug.

 

[Keith Thompson]

No we discuss the use of C

We discuss C, which is defined by one or more standards.

The existence of extensions is entirely topical, and it's likely (but
by no means certain) that some such extensions will be required to
solve the OP's problem.

The details of those extensions are not topical, and should be
discussed in some system-specific newsgroup. (Those details are
likely to be more closely related to the operating system than to the
language.)

 

[Eric Sosman]

You can get away with that in comp.arch.embedded, but not here.
This newsgroup discusses PORTABLE standard C.

That seems to me to restrictive a view. There's no
group charter (the group antedates charters), so topicality
is not subject to hard-and-fast arbitration. But in my
view the subject of the newsgroup is C: its uses, its idioms,
its strengths. Also its abuses, its slang, and its faults.

Portability is a recurring and important theme. IMHO
there is a lot of unportable C that could be made portable
at little if any cost -- but there are also situations where
the Right Answer is to employ a construct that's specific to
one environment (hence non-portable) or to a restricted class
of environments (hence ditto). The Rationale makes explicit
mention of the usefulness of non-portable code, and I don't
see any reason for this newsgroup to shun it.

As I said, a good deal of non-portable code is non-portable
for no good reason, and an important function of c.l.c. is to
point out portable alternatives for gratuitous importabilities.
But when somebody's having trouble with a device I/O register,
the useful response from c.l.c. isn't "not portable, go away"
but "you should probably use `volatile'."

C-as-it-is is a proper topic for the newsgroup. We can
steer towards C-as-it-should-be, but sometimes we must
acknowledge that C-as-it-needs-to-be can be a different animal.

 

[Ulysses]

Thanks a lot for the help...guys...<though i 'm still pretty
confused.....>....Could anyone suggest a good I/O tutorial on the net
for C....?....>...........And someone said that in UNIX...we can open
devices as files.......so is there a standard list of filenames
assigned to various ports.<must be>...and where can i get it?.......

thanking all again.......

 

[Walter Roberson]

And someone said that in UNIX...we can open
devices as files.......so is there a standard list of filenames
assigned to various ports.<must be>...and where can i get it?.......

That's a Unix question, not a C question.

[OT]

The answer is NO, there is no standard list of device names in Unix,
with the exception of a few devices such as /dev/null and /dev/tty
and /dev/tape .

Some particular Unices or Unix-like operating systems have additional
standard device names for their version. But random cards will
seldom have standard names. Unix identifies devices by
device "major" number and device "minor" number, with the "major"
number corresponding to a class of device and the "minor" number
indicating which particular instance it is (and sometimes the
minor device number encodes control information such as tape density.)
There are some "well known" major device numbers specific to
particular operating systems, but when you get into less common
devices types the device numbers become more likely to be arbitrarily
assigned by the system administrator when configuring the kernel.

In short: ask in a newsgroup that specializes in your particular
operating system.

 

[CBFalconer]

Thanks a lot for the help...guys...<though i 'm still pretty
confused.....>....Could anyone suggest a good I/O tutorial on the
net for C....?....>...........And someone said that in UNIX...we
can open devices as files.......so is there a standard list of
filenames assigned to various ports.<must be>...and where can i
get it?.......

You have failed to quote, making the article even more
incomprehensible. The long strings of periods are meaningless.
Try breaking things up into sentences and paragraphs, capitalizing
the first personal pronoun ('I'), etc.

In *IX the only standard files are stdin, stdout, stderr. Others
have whatever name you assigned to them when you stored them.

Notice my use of sentences and paragraphs, and go and do likewise.

 

[Walter Roberson]

In *IX the only standard files are stdin, stdout, stderr. Others
have whatever name you assigned to them when you stored them.

stdin, stdout, and stderr are not the names of files: they are the
names of streams. The poster did ask specifically about
"filenames", not about stream names. My earlier reply gave the
requisite "barely; you need to consult the proper newsgroup" answer.

 

[Keith Thompson]

Thanks a lot for the help...guys...<though i 'm still pretty
confused.....>....Could anyone suggest a good I/O tutorial on the
net for C....?....>...........And someone said that in UNIX...we
can open devices as files.......so is there a standard list of
filenames assigned to various ports.<must be>...and where can i
get it?.......

[snip]

In *IX the only standard files are stdin, stdout, stderr. Others
have whatever name you assigned to them when you stored them.

Those are C streams, not files.

<OT>
Unix has a plethora of standard files, such as /dev/null, /dev/zero,
/etc/passwd, /etc/motd. That's what Ulysses was asking about. I
don't think he'll find what he's looking for, but the place to ask is
comp.unix.programmer.
</OT>

 

[Richard Heathfield]

Walter Roberson said:

stdin, stdout, and stderr are not the names of files: they are the
names of streams.

Not quite. Strictly speaking, they're expressions of type "pointer to
FILE", that point to FILE objects associated with the standard input,
output, and error streams. So the names of the streams, in this case,
are: "standard input stream", "standard output stream", and "standard
error stream".

 

[SM Ryan]

# Please demonstrate how to set up legal direct register access in
# STANDARD C (no extensions). Quote the enabling lines from N869
# please.

On HP2000 it would be something like
int *registerA = (int*)0;
int *registerB = (int*)1;

PDP-11 Unibus registers would be something like
word *status = (word*)0170000;
byte *data = (byte*)0170002;
byte *command = (byte*)0170003;

You're welcome.

 

[Walter Roberson]

CBFalconer <[email protected]> wrote:

# Please demonstrate how to set up legal direct register access in
# STANDARD C (no extensions). Quote the enabling lines from N869
# please.

On HP2000 it would be something like
int *registerA = (int*)0;
int *registerB = (int*)1;

That requires the ability to convert from an integral type to a pointer.
C90 allows implementations to define a meaning for this, but the
behaviour is otherwise unspecified, and the integer provided need not
have any rational connection to the device reached. One thing we
can promise in the first line is that registerA will be the NULL
pointer, even if the NULL pointer has an internal bit representation
that has nothing to do with binary 0s.

As registers are being discussed, it would be -highly- advisable
to qualify the declarations as volatile. Which naturally leads us
into the issue that C doesn't promise it will load all of an int in
one go: the only atomic access promised is for sig_atomic_t (which
could be as small as a char.)

PDP-11 Unibus registers would be something like
word *status = (word*)0170000;
byte *data = (byte*)0170002;
byte *command = (byte*)0170003;

Chuck said "no extensions", but you have used 'word' and 'byte', which
are not standard C entities, except in so far as C -defines- a "byte"
as being the width of a char (even if there is a smaller machine-level
type.)

 

[CBFalconer]

That requires the ability to convert from an integral type to a
pointer. C90 allows implementations to define a meaning for this,
but the behaviour is otherwise unspecified, and the integer
provided need not have any rational connection to the device
reached. One thing we can promise in the first line is that
registerA will be the NULL pointer, even if the NULL pointer
has an internal bit representation that has nothing to do with
binary 0s.

You can't even promise that. Register A may not be able to hold a
pointer. My original point was that you can't do that (register
access) in a portable manner.