Data acquisition Card- How to use with C?

Discussion in 'C Programming' started by Ulysses, Jun 20, 2007.

  1. Ulysses

    Ulysses Guest

    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>.
     
    Ulysses, Jun 20, 2007
    #1
    1. Advertising

  2. Ulysses

    Lew Pitcher Guest

    On Jun 20, 7:14 am, Ulysses <> wrote:
    > 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>.
     
    Lew Pitcher, Jun 20, 2007
    #2
    1. Advertising

  3. Ulysses

    CBFalconer Guest

    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
     
    CBFalconer, Jun 20, 2007
    #3
  4. Ulysses

    Chris Hills Guest

    In article <>, CBFalconer
    <> writes
    >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 /\/\/\/\/
    /\/\/ www.phaedsys.org \/\/\
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
     
    Chris Hills, Jun 20, 2007
    #4
  5. Ulysses

    CBFalconer Guest

    Chris Hills wrote:
    > <> writes
    >> 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
     
    CBFalconer, Jun 21, 2007
    #5
  6. Ulysses

    Chris Dollin Guest

    Chris Hills wrote:

    > In article <>, CBFalconer
    > <> writes
    >>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
     
    Chris Dollin, Jun 21, 2007
    #6
  7. Ulysses

    Chris Hills Guest

    In article <>, CBFalconer
    <> writes
    >Chris Hills wrote:
    >> <> writes
    >>> 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 /\/\/\/\/
    /\/\/ www.phaedsys.org \/\/\
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
     
    Chris Hills, Jun 21, 2007
    #7
  8. Ulysses

    CBFalconer Guest

    Chris Hills wrote:
    > <> writes
    >> 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
     
    CBFalconer, Jun 21, 2007
    #8
  9. Ulysses

    Chris Hills Guest

    In article <>, CBFalconer
    <> writes
    >Chris Hills wrote:
    >> <> writes
    >>> 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 /\/\/\/\/
    /\/\/ www.phaedsys.org \/\/\
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
     
    Chris Hills, Jun 21, 2007
    #9
  10. Chris Hills <> writes:
    > In article <>, CBFalconer
    > <> writes
    >>Chris Hills wrote:
    >>> <> writes
    >>>> 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) <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"
     
    Keith Thompson, Jun 22, 2007
    #10
  11. Ulysses

    Eric Sosman Guest

    CBFalconer wrote:
    > Chris Hills wrote:
    >> <> writes
    >>> 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
    lid
     
    Eric Sosman, Jun 22, 2007
    #11
  12. Ulysses

    Ulysses Guest

    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.......
     
    Ulysses, Jun 22, 2007
    #12
  13. In article <>,
    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.<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
     
    Walter Roberson, Jun 22, 2007
    #13
  14. Ulysses

    CBFalconer Guest

    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
     
    CBFalconer, Jun 22, 2007
    #14
  15. In article <>,
    CBFalconer <> wrote:
    >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
     
    Walter Roberson, Jun 22, 2007
    #15
  16. CBFalconer <> writes:
    > 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) <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"
     
    Keith Thompson, Jun 22, 2007
    #16
  17. Walter Roberson said:

    > In article <>,
    > CBFalconer <> wrote:
    >>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
     
    Richard Heathfield, Jun 22, 2007
    #17
  18. Ulysses

    SM Ryan Guest

    CBFalconer <> 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;

    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.
     
    SM Ryan, Jun 24, 2007
    #18
  19. In article <>,
    SM Ryan <> wrote:
    >CBFalconer <> 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.)
    --
    Programming is what happens while you're busy making other plans.
     
    Walter Roberson, Jun 24, 2007
    #19
  20. Ulysses

    CBFalconer Guest

    Walter Roberson wrote:
    > SM Ryan <> wrote:
    >> CBFalconer <> 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.


    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
     
    CBFalconer, Jun 24, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. jude
    Replies:
    7
    Views:
    972
    Brock Allen
    Mar 15, 2005
  2. StepH
    Replies:
    3
    Views:
    466
    Alex Verstraeten
    May 17, 2005
  3. Replies:
    0
    Views:
    373
  4. spintronic

    Data acquisition

    spintronic, Oct 25, 2011, in forum: Python
    Replies:
    10
    Views:
    352
    Dennis Lee Bieber
    Oct 26, 2011
  5. Steven Jenkins
    Replies:
    0
    Views:
    300
    Steven Jenkins
    Jan 19, 2004
Loading...

Share This Page