Data acquisition Card- How to use with C?

[Walter Roberson]

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.

 

[CBFalconer]

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.

 

[SM Ryan]

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

 

[Ulysses]

Sorry for asking.....but how is all this related to my query about
data acquisition in C?.....

 

[Chris Dollin]

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.

 

[CBFalconer]

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

 

[Eric Sosman]

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

 

[Chris Hills]

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

 

[CBFalconer]

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

 

[Keith Thompson]

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.

 

[Gordon Burditt]

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.

 

[Lew Pitcher]

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>

 

[Chris Dollin]

<offtopic>
You must have a big back yard
</offtopic>

(fx:OT) No -- a big front one.

 

[Chris Hills]

This requires a quibble. Look up "stdio.h" in the C standard. Not
required in dedicated systems only.

Mutter whinge etc

 

[santosh]

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.h> added with TR18015 and TR18037?

 

[Lew Pitcher]

What about <iohw.h> added 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. ------

 

[Keith Thompson]

[...]
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.h> added 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>.