By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,987 Members | 1,552 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,987 IT Pros & Developers. It's quick & easy.

Data acquisition Card- How to use with C?

P: n/a
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>.

Jun 20 '07 #1
Share this Question
Share on Google+
36 Replies


P: n/a
On Jun 20, 7:14 am, Ulysses <stallo...@gmail.comwrote:
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"); )
>...<Just general information would also
help........I'm just working on an idea at the moment>.

Jun 20 '07 #2

P: n/a
Ulysses wrote:
>
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.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net
--
Posted via a free Usenet account from http://www.teranews.com

Jun 20 '07 #3

P: n/a
In article <46**************@yahoo.com>, CBFalconer
<cb********@yahoo.comwrites
>Ulysses wrote:
>>
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.
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...

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 20 '07 #4

P: n/a
Chris Hills wrote:
<cb********@yahoo.comwrites
>Ulysses wrote:
>>>
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.

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.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Jun 21 '07 #5

P: n/a
Chris Hills wrote:
In article <46**************@yahoo.com>, CBFalconer
<cb********@yahoo.comwrites
>>Ulysses wrote:
>>>
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.

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 "flat, not hilly" Dollin

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

Jun 21 '07 #6

P: n/a
In article <46***************@yahoo.com>, CBFalconer
<cb********@yahoo.comwrites
>Chris Hills wrote:
><cb********@yahoo.comwrites
>>Ulysses wrote:

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.

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.
No. Use extensions. We are talking SW engineering not religious
bigotry.

BTW N869 is NOT standard C Standard C is ISO9899:1999
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 21 '07 #7

P: n/a
Chris Hills wrote:
<cb********@yahoo.comwrites
>Chris Hills wrote:
.... snip ...
>>
>>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.

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.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Jun 21 '07 #8

P: n/a
In article <46***************@yahoo.com>, CBFalconer
<cb********@yahoo.comwrites
>Chris Hills wrote:
><cb********@yahoo.comwrites
>>Chris Hills wrote:
... snip ...
>>>
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.

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.
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.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 21 '07 #9

P: n/a
Chris Hills <ch***@phaedsys.orgwrites:
In article <46***************@yahoo.com>, CBFalconer
<cb********@yahoo.comwrites
>>Chris Hills wrote:
>><cb********@yahoo.comwrites
Chris Hills wrote:
... snip ...
>>>>
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.

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.

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.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jun 22 '07 #10

P: n/a
CBFalconer wrote:
Chris Hills wrote:
><cb********@yahoo.comwrites
>>Chris Hills wrote:
... snip ...
>>>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.
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.
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.

--
Eric Sosman
es*****@acm-dot-org.invalid
Jun 22 '07 #11

P: n/a
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.......

Jun 22 '07 #12

P: n/a
In article <11**********************@o11g2000prd.googlegroups .com>,
Ulysses <st*******@gmail.comwrote:
>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.
--
I was very young in those days, but I was also rather dim.
-- Christopher Priest
Jun 22 '07 #13

P: n/a
Ulysses wrote:
>
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.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Jun 22 '07 #14

P: n/a
In article <46***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:
>Ulysses wrote:
>And someone said that in UNIX...we
can open devices as files.......so is there a standard list of
filenames assigned to various ports.
>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.
--
Okay, buzzwords only. Two syllables, tops. -- Laurie Anderson
Jun 22 '07 #15

P: n/a
CBFalconer <cb********@yahoo.comwrites:
Ulysses wrote:
>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>

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jun 22 '07 #16

P: n/a
Walter Roberson said:
In article <46***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:
>>Ulysses wrote:
>>And someone said that in UNIX...we
can open devices as files.......so is there a standard list of
filenames assigned to various ports.
>>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.
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".

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jun 22 '07 #17

P: n/a
CBFalconer <cb********@yahoo.comwrote:

# 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.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
But I do believe in this.
Jun 24 '07 #18

P: n/a
In article <13*************@corp.supernews.com>,
SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.orgwrote:
>CBFalconer <cb********@yahoo.comwrote:
># 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.)
--
Programming is what happens while you're busy making other plans.
Jun 24 '07 #19

P: n/a
Walter Roberson wrote:
SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.orgwrote:
>CBFalconer <cb********@yahoo.comwrote:
>># 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.
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.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Jun 24 '07 #20

P: n/a
In article <46***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:
>Walter Roberson wrote:
>SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.orgwrote:
>> int *registerA = (int*)0;
>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.
registerA was declared as int * and if an int * declared variable
cannot hold an int * pointer then the implementation is badly broken.
--
Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us. -- Ecclesiastes
Jun 24 '07 #21

P: n/a
CBFalconer <cb********@yahoo.comwrote:

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

# 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.

Then make your point correctly. Some systems do provide memory
mapped registers and on such systems it's legal to cast the
address (as an integer) to a pointer. Whether this is portable
is different from whether it is ANSI C.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
What kind of convenience store do you run here?
Jun 25 '07 #22

P: n/a
Walter Roberson wrote:
CBFalconer <cb********@maineline.netwrote:
>Walter Roberson wrote:
>>SM Ryan wrote:
>>> int *registerA = (int*)0;
>>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.

registerA was declared as int * and if an int * declared variable
cannot hold an int * pointer then the implementation is badly
broken.
Well, I was reading what I thought was the intent, i.e. RegisterA
is a machine register. If not, then you are absolutely correct.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Jun 25 '07 #23

P: n/a
Sorry for asking.....but how is all this related to my query about
data acquisition in C?.....

Jun 27 '07 #24

P: n/a
Ulysses wrote:
Sorry for asking.....but how is all this related to my query about
data acquisition in C?.....
Because there's no portable access to any data acquisition hardware
in C, we got to off-topically discussing non-portable access to
machine registers. Don't worry, thread drift happens everywhere
(fx:glitch) by the way, are you humans interested in selling your
complete knowledge of /paint/? I have here (fx:rummage) antigravity,
age deferral, and nonlocal communication.

--
Chris "Clifford" Dollin

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

Jun 27 '07 #25

P: n/a
Ulysses wrote:
>
Sorry for asking.....but how is all this related to my query about
data acquisition in C?.....
What, if anything, has this to do with what? It is completely
incomprehensible without adequate quoting. See below:

--
If you want to post a followup via groups.google.com, ensure
you quote enough for the article to make sense. Google is only
an interface to Usenet; it's not Usenet itself. Don't assume
your readers can, or ever will, see any previous articles.
More details at: <http://cfaj.freeshell.org/google/>

--
Posted via a free Usenet account from http://www.teranews.com

Jun 27 '07 #26

P: n/a
Chris Dollin wrote:
Ulysses wrote:
>Sorry for asking.....but how is all this related to my query about
data acquisition in C?.....

Because there's no portable access to any data acquisition hardware
in C, we got to off-topically discussing non-portable access to
machine registers. Don't worry, thread drift happens everywhere
(fx:glitch) by the way, are you humans interested in selling your
complete knowledge of /paint/? I have here (fx:rummage) antigravity,
age deferral, and nonlocal communication.
Lemme go out back and check on something ...

--
Eric Sosman
es*****@acm-dot-org.invalid
Jun 27 '07 #27

P: n/a
In article <11**********************@d30g2000prg.googlegroups .com>,
Ulysses <st*******@gmail.comwrites
>Sorry for asking.....but how is all this related to my query about
data acquisition in C?.....

How is what related?
You need to quote the message you are replying to for context.

The problem is you are using a broken googlegroups interface to Usenet.
Get a proper news reader.

Read The Hitchhikers Guide to the Galaxy. If you don't understand the
answers you have been given you asked either the wrong question or did
not understand the question you did ask.

I think I asked right at the very start for you to clarify the target
system hardware, what sort of ad in card you were on about and what it
did. Also the compilers you intended to use.

As everyone else said there is no IO in standard C

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 27 '07 #28

P: n/a
Chris Hills <ch***@phaedsys.orgwrites:
[...]
As everyone else said there is no IO in standard C
There certain is I/O in standard C (see <stdio.h>), just not the kind
of low-level I/O the OP is looking for.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jun 27 '07 #29

P: n/a
>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>.
Ok, so how do you get data from this data acquisition card using *ANYTHING*?
Some suggested answers:

- Connect the USB cable between the card and your computer.
- Plug the card into a PCI slot in your computer.
- Plug the card into the CAC card reader on your keyboard.
- Get the card within range of a wireless access point on your network.
- Connect the RS232 cable between the card and a serial port on your computer.
- Get the card within range of a Bluetooth dongle on your computer.
- The card already contains an Internet-connected satellite radio; just
give it the IP address of your computer.
- Aim the card at an infrared receiver connected to a serial port on your
computer.

None of this is portable in C, but the nature of the connection and
details of your OS will likely determine whether you've got a device
name that looks and smells like a file name, or whether it looks
like another device on a network, or it injects input through the
keyboard (anyone remember the CueCat?), or it's accessed like a
communication link where you send a character at a time.

Jun 28 '07 #30

P: n/a
Chris Hills wrote:
>
.... snip ...
>
As everyone else said there is no IO in standard C
This requires a quibble. Look up "stdio.h" in the C standard. Not
required in dedicated systems only.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Jun 28 '07 #31

P: n/a
On Jun 27, 5:55 am, Chris Dollin <chris.dol...@hp.comwrote:
[snip]
Don't worry, thread drift happens everywhere
(fx:glitch) by the way, are you humans interested in selling your
complete knowledge of /paint/? I have here (fx:rummage) antigravity,
age deferral, and nonlocal communication.
<offtopic>
You must have a big back yard
</offtopic>
Jun 28 '07 #32

P: n/a
Lew Pitcher wrote:
On Jun 27, 5:55 am, Chris Dollin <chris.dol...@hp.comwrote:
[snip]
>Don't worry, thread drift happens everywhere
(fx:glitch) by the way, are you humans interested in selling your
complete knowledge of /paint/? I have here (fx:rummage) antigravity,
age deferral, and nonlocal communication.

<offtopic>
You must have a big back yard
</offtopic>
(fx:OT) No -- a big front one.

--
Chris "more of a wilderness, really" Dollin

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

Jun 28 '07 #33

P: n/a
In article <46***************@yahoo.com>, CBFalconer
<cb********@yahoo.comwrites
>Chris Hills wrote:
>>
... snip ...
>>
As everyone else said there is no IO in standard C

This requires a quibble. Look up "stdio.h" in the C standard. Not
required in dedicated systems only.
Mutter whinge etc :-)

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Jun 28 '07 #34

P: n/a

Keith Thompson wrote:
Chris Hills <ch***@phaedsys.orgwrites:
[...]
As everyone else said there is no IO in standard C

There certain is I/O in standard C (see <stdio.h>), just not the kind
of low-level I/O the OP is looking for.
What about <iohw.hadded with TR18015 and TR18037?

Jun 29 '07 #35

P: n/a
santosh wrote:
Keith Thompson wrote:
>Chris Hills <ch***@phaedsys.orgwrites:
[...]
>>As everyone else said there is no IO in standard C
There certain is I/O in standard C (see <stdio.h>), just not the kind
of low-level I/O the OP is looking for.

What about <iohw.hadded with TR18015 and TR18037?
I'm not quite certain what a Technical Report on C++ Performance (TR18015) has
to do with the subject matter of comp.lang.c. It certainly has nothing to do
with the C language

OTOH. TR18037 seems to relate to C extensions for embedded systems. /But/,
AFAICT, it hasn't been accepted as a part of the current C standard.

So, either you are talking about a different language (C++) or you are talking
about extensions outside the realm of standard C (Embedded C).

--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------

Jun 29 '07 #36

P: n/a
Lew Pitcher <lp******@teksavvy.comwrites:
santosh wrote:
>Keith Thompson wrote:
>>Chris Hills <ch***@phaedsys.orgwrites:
[...]
As everyone else said there is no IO in standard C
There certain is I/O in standard C (see <stdio.h>), just not the kind
of low-level I/O the OP is looking for.

What about <iohw.hadded with TR18015 and TR18037?

I'm not quite certain what a Technical Report on C++ Performance
(TR18015) has to do with the subject matter of comp.lang.c. It
certainly has nothing to do with the C language

OTOH. TR18037 seems to relate to C extensions for embedded
systems. /But/, AFAICT, it hasn't been accepted as a part of the
current C standard.

So, either you are talking about a different language (C++) or you
are talking about extensions outside the realm of standard C
(Embedded C).
C++ extensions certainly aren't topical here, but I suggest that
TR18037, since it's issued by the C standard committee, should be
considered topical here in comp.lang.c (as long as the discussion
makes it clear that it's not part of the standard itself).

I'm not familiar with it myself, and ANSI wants
$160 for the PDF, so I'm not likely to be getting a
copy from them, but the latest draft is available at
<http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1169.pdf>.

Other projects are described at
<http://www.open-std.org/JTC1/SC22/WG14/www/projects>.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jun 29 '07 #37

This discussion thread is closed

Replies have been disabled for this discussion.