(SUMMARY) (LONG) Logic Analyzer Printouts on a 3b1
Silvio Picano
picano at perch.ecn.purdue.edu
Sat Mar 23 09:45:27 AEST 1991
Here is the SUMMARY to my original posting.
Contained are:
1. email responces directed to me
2. a desciption file of the whole project
3. C code implemented
Thanks to all who responded!!
dnelson at mthvax.cs.miami.edu
adams at ucunix.ecn.purdue.edu
dnichols at ceilidh.beartrack.com
dave at Galaxia.Newport.RI.US
Silvio
###########################################################
Return-Path: dnelson at mthvax.cs.miami.edu
Received: from en.ecn.purdue.edu by ei.ecn.purdue.edu (5.65/1.30jrs)
id AA13438; Wed, 27 Feb 91 17:30:04 -0500
Received: from mthvax.cs.miami.edu by en.ecn.purdue.edu (5.65/1.30jrs)
id AA10539; Wed, 27 Feb 91 17:29:54 -0500
Received: by mthvax.cs.miami.edu id AA08404
(5.65+/IDA-1.3.4 for picano at en.ecn.purdue.edu); Wed, 27 Feb 91 17:29:33 -0500
Date: Wed, 27 Feb 91 17:29:33 -0500
From: Dru Nelson <dnelson at mthvax.cs.miami.edu>
Message-Id: <9102272229.AA08404 at mthvax.cs.miami.edu>
To: picano at en.ecn.purdue.edu
Subject: Re: Logic Analyzer Printouts on a 3b1 (Please Help)
Newsgroups: comp.sys.att
References: <1991Feb27.195150.11518 at en.ecn.purdue.edu>
Hello,
Post to comp.sys.3b1; you might find some better help there.
--
%% Dru Nelson %% Miami, FL %% Internet: dnelson at mthvax.cs.miami.edu %%
###########################################################
Return-Path: adams at ucunix.ecn.purdue.edu
Received: from en.ecn.purdue.edu by ei.ecn.purdue.edu (5.65/1.30jrs)
id AA07313; Thu, 28 Feb 91 13:42:41 -0500
Received: from ucbeh.san.uc.edu by en.ecn.purdue.edu (5.65/1.30jrs)
id AA06212; Thu, 28 Feb 91 13:42:35 -0500
Received: from ucunix.san.uc.edu by UCBEH.SAN.UC.EDU with PMDF#10429; Thu, 28
Feb 1991 13:42 EST
Received: by ucunix.san.uc.edu (5.57/Ultrix3.0-C) id AA04917; Thu, 28 Feb 91
13:41:16 -0500
Date: Thu, 28 Feb 91 13:41:16 -0500
From: adams at ucunix.san.uc.EDU (James Warner Adams)
Subject: Re: Logic Analyzer Interface to a 3b1 (Please Help)
In-Reply-To: <1991Feb27.193918.8982 at en.ecn.purdue.edu>
To: picano at en.ecn.purdue.edu
Message-Id: <9102281841.AA04917 at ucunix.san.uc.edu>
X-Envelope-To: picano at en.ecn.purdue.EDU
Newsgroups: comp.sys.att
Organization: University of Cincinnati
Why do you need a driver to do this? (Sorry if I misunderstood you,
but I assume you mean a device driver.) It seems to me you could just
use the existing one and write a small C program that sleeps until it
sees input on the port and then wakes up and copies to the printer.
Look at the termio(7) man page under 'ICANON' to see how this can be
done.
If the printer is not dedicated to this application, then the situation
is a little more complex. You need to store the data until you receive
either a full raster or whatever the H-P sends to end the raster page.
Then just dump the page to the spooler.
The only way you would need a device driver would be to control a
non-standard interface protocol (e.g., bidirectional hardware flow
control).
--
Jim Adams Department of Physiology and Biophysics
adams at ucunix.san.uc.edu University of Cincinnati College of Medicine
Anatidaephobia: The fear that somewhere, somehow, a duck is watching you.
###########################################################
>From noose.ecn.purdue.edu!news.cs.indiana.edu!news.nd.edu!spool.mu.edu!uunet!beartrk!ceilidh!dnichols Fri Mar 1 20:28:35 EST 1991
Article: 553 of comp.sys.3b1
Path: en.ecn.purdue.edu!noose.ecn.purdue.edu!news.cs.indiana.edu!news.nd.edu!spool.mu.edu!uunet!beartrk!ceilidh!dnichols
From: dnichols at ceilidh.beartrack.com (DoN Nichols)
Newsgroups: comp.sys.3b1
Subject: Re: Logic Analyzer Printouts via 3b1 (Please Help)
Message-ID: <1991Mar1.021654.14620 at ceilidh.beartrack.com>
Date: 1 Mar 91 02:16:54 GMT
Article-I.D.: ceilidh.1991Mar1.021654.14620
References: <1991Feb28.003345.5188 at en.ecn.purdue.edu>
Distribution: usa
Organization: D and D Data, Vienna, VA.
Lines: 63
In article <1991Feb28.003345.5188 at en.ecn.purdue.edu> picano at en.ecn.purdue.edu (Silvio Picano) writes:
>
>Hi, I am hoping someone may have done the following or
>could point me in the right direction.
>
>I am trying to connect an HP logic analyzer to my AT&T PC
>to get analyzer printouts of the screen. Now the analyzer
>has an RS232C port and can be configured to use several
>handshaking protocols (e.g., Xon/Xoff). My major concern
>is the difficultly(ies) in accessing the serial port and
>writing the 'data-collecting driver routine'.
>
>The ideal operation(?) is,
> 1. HP analyzer sends data (already suited for Epson prints)
> 2. the AT&T collects ALL the data (in the background,
> interrupt driven)
You won't be able to AVOID having the input interrupt driven. Since
the analyzer understands xon/xoff, it should be simple to activate it for
the serial port. You don't say which version of the operating system you
are using, but I would suggest that if possible you should have the 3.51
version of the os, and get from osu-cis the FIXDISK2.0+IN.Z, uncompress it,
put it in /usr/spool/uucppublic, and use the 'install software from e-mail'
option in the admin/software-setup portion of the menus under the 'install'
login.
> 3. then, the AT&T sends the (raw) data to the printer
[ ... diagram deleted ... ]
>My documentation is scarse and not at a 'low enough' level
>to accomplish this 'data-collection driver'. I am hoping
>someone may have done something similar (maybe some code??)
>and can provide useful hints on doing the above.
If you don't have the 'development system' software, you don't have
the tools you need, and if you do, you should have the manuals, but just not
know what parts to use.
Look in section 7 of the Unix System V user's manual Vol I under
'termio'. See the 'c_iflag' section, and note the 'IXON' flag. Also, the
'c_cflag' section allows selection of baudrate. You will need to use the
'ioctl' system call to set these. You should use it first to get the
existing settings, then modify the flags in the parts you are interested in,
and then re-write the struct back to the system.
I won't try to give more details, since it has been a while since I
last had to do this sort of thing, and I wouldn't want to give wrong
advice. I'd suggest you get a good book on this sort of thing, and keep the
man pages handy.
>Thanks In Advance
>Silvio picano at ecn.purdue.edu
Good Luck
DoN.
--
Donald Nichols (DoN.) | Voice (Days): (703) 664-1585
D&D Data | Voice (Eves): (703) 938-4564
Disclaimer: from here - None | Email: <dnichols at ceilidh.beartrack.com>
--- Black Holes are where God is dividing by zero ---
###########################################################
Return-Path: galaxia!dave at cis.ohio-state.edu
Received: from en.ecn.purdue.edu by ei.ecn.purdue.edu (5.65/1.30jrs)
id AA28734; Mon, 4 Mar 91 17:24:10 -0500
Received: from saqqara.cis.ohio-state.edu by en.ecn.purdue.edu (5.65/1.30jrs)
id AA05876; Mon, 4 Mar 91 17:24:04 -0500
Received: by saqqara.cis.ohio-state.edu (5.61-kk/5.910301)
id AA20212; Mon, 4 Mar 91 17:23:59 -0500
Received: by Galaxia.Newport.RI.US (5.64/smail2.5/09-28-87)
id AA11082; Sat, 2 Mar 91 21:53:38 -0500
Date: Sat, 2 Mar 91 21:53:38 -0500
From: dave at Galaxia.Newport.RI.US (David H. Brierley)
Message-Id: <9103030253.AA11082 at Galaxia.Newport.RI.US>
To: picano at en.ecn.purdue.edu
News-Path: rayssd!uunet!samsung!noose.ecn.purdue.edu!en.ecn.purdue.edu!picano
Subject: Re: (REPOST) Logic Analyzer Printouts on a 3b1 (Please Help)
Newsgroups: comp.sys.att
In-Reply-To: <1991Feb27.195150.11518 at en.ecn.purdue.edu>
Status: O
>The ideal operation(?) is,
> 1. HP analyzer sends data (already suited for Epson prints)
> 2. the AT&T collects ALL the data (in the background,
> interrupt driven)
> 3. then, the AT&T sends the (raw) data to the printer
This is easy enough to do. All you have to do is a write a program that
will read data from the serial port, store it unmodified in a disk file,
and then send the file to the printer using the name "Epson_R" (assuming
that the name your printer is configured with is "Epson"). The "_R"
suffix on the printer name specifies that you want "raw" access to the
printer. i.e. you have formatted Epson graphics that you want to print.
The only difficult part is recognizing when the HP has finished sending
the data. If the HP sends some kind of an EOF marker you can can for
that, otherwise you could simply use a timer based scheme (i.e. if you
dont get any data for N seconds then you assume the print is complete).
I hope this helps.
--
David H. Brierley
Home: dave at galaxia.newport.ri.us; Work: dhb at quahog.ssd.ray.com
Send comp.sources.3b1 submissions to comp-sources-3b1 at galaxia.newport.ri.us
%% Can I be excused, my brain is full. **
###########################################################
Return-Path: beartrk!dnichols at uunet.UU.NET
Received: from bank.ecn.purdue.edu by ei.ecn.purdue.edu (5.65/1.30jrs)
id AA04183; Mon, 11 Mar 91 21:27:34 -0500
Received: from uunet.UU.NET by bank.ecn.purdue.edu (5.65/1.30jrs)
id AA29308; Mon, 11 Mar 91 21:27:29 -0500
Received: from beartrk.UUCP by uunet.uu.net with UUCP
(5.61/UUNET-primary-gateway) id AA12437; Mon, 11 Mar 91 21:27:25 -0500
Received: by beartrk.beartrack.com (smail2.5/AIX 2.2)
id AA11353; 11 Mar 91 21:16:18 EST (Mon)
Received: by (4.12/2.4S)
id AA20027; Mon, 11 Mar 91 20:31:35 est
From: !dnichols at uunet.uu.net (DoN Nichols)
Message-Id: <9103120131.AA20027@>
Subject: Re: Thanks for the response
To: @beartrk.UUCP:uunet!ecn.purdue.edu!picano (Silvio Picano)
Date: Mon, 11 Mar 91 20:31:17 EST
Reply-To: dnichols at ceilidh.beartrack.com
In-Reply-To: <9103112027.AA22192 at ei.ecn.purdue.edu>; from "Silvio Picano" at Mar 11, 91 3:27 pm
X-Mailer: ELM [version 2.3 PL2]
"Silvio Picano says:"
>
>
> Subject: Re: Logic Analyzer Printouts via 3b1 (Please Help)
[ ... ]
>
> Thanks for the reply to my post...
>
> If I could get a few more hints, I would much appreciate it?
> (OS 3.0, with Development Software, and Expansion Ports)
I don't have either the 3.0 version or the manuals for it. You
probably should grab the next offer of version 3.51 for the 3B1 that comes
on the net, and then get FIXDISK2.0 to have the most current version of the
OS, since I understand that there are more bugs in the earlier versions of
UNIX for this box. That and the termio info from section 7 are your best
bet.
> These are the steps I would (??) consider:
>
> 1. I have an init program that initializes the serial
> port (baud rate, Xon/Xoff, etc) run in the rc boot
> file (once upon system startup) ?
Don't trust this to permanently set the baudrate. If you don't
prevent UNIX from considering it a possible login port, it will change
everytime getty grabs hold of it. (Although you could set the values in the
/etc/inittab to select the baudrate, getty would keep fighting you for the
data. (Your logic analyzer would keep attempting to login, and failing, as
far as the computer was concerned.) You should put the initialization code
(termio/ioctls) in the initialization function of the code that actually
copies the data from serial port to disk.
> 2. My interrupt routine reads data from port and stores it
> into a file (any type of file descriptor?? using
> open or fopen)??
>
> 3. How do I put my interrupt routine into the interrupt
> chain?? (I have been reading the drivers(7) entry
> in the UNIX V User's Manual.) Are the SAMPLE init,
> release, and interrupt service routines in this section
> 'somewhat accurate' for me to implement?
DONT! I don't have the device drivers writers guide, and couldn't
guess how far off the sample code might be, but YOU DON'T WANT TO WRITE
DEVICE DRIVERS if you can help it. It is far from a trivial task in a
multi-tasking environment.
WHY do it this way???? There is already a set of interrupt-driven
routines present in the kernel, and any attempt to write another would only
wind up fighting the system for who controls the built-in serial port. (For
add-on serial ports, you could not load the driver for the combo, and in its
place load your custom driver, but again WHY, when the existing driver is
already interrupt driven, and also knows about different forms of
handshaking, such as XON/XOFF, RTS/CTS, etc.
If you want to write interrupt-driven routines yourself, DON'T do it
in the middle of a multi-tasking operating system which depends on
interrupts for its very life, and can die if interrupts are masked at the
wrong time. Take the hardware, and write your own (non-multi-tasking) os
for it. You can't just stuff extra junk in the interrupt processing chain
without knowing a lot more than I do. (And I have written device drivers
for another multitasking operating system, OS-9). You don't just put in an
interrupt-handler, you put in a whole set of callable functions which the os
expects to behave in a specific way. Even if you managed to get your
interrupt service routine onto the chain, you would have the data gathered
in a section of the KERNEL's memory, which NO USER PROCESS can reach. You
need the other calls to pass that information out to the user process, and
at that point, IT IS DOING JUST WHAT THE EXISTING DRIVER IS DESIGNED TO DO.
If you DO want to interface to the logic analyzer in UNIX, do it the
UNIX way, use the tools that UNIX provides for handling I/O. If you don't
want to do it the UNIX way, don't do it in UNIX! I again include the key
information from my previous response:
>> Look in section 7 of the Unix System V user's manual Vol I under
>> 'termio'. See the 'c_iflag' section, and note the 'IXON' flag. Also, the
>> 'c_cflag' section allows selection of baudrate. You will need to use the
>> 'ioctl' system call to set these. You should use it first to get the
>> existing settings, then modify the flags in the parts you are interested in,
>> and then re-write the struct back to the system.
>>
The IXON flag in 'c_iflag' allows you to turn on XON/XOFF
handshaking for your port of choice, the 'c_cflag' section allows you to set
the baudrate IN THE PROGRAM THAT IS USING THE PORT, so when you start the
program, you KNOW it is set right.
Since the logic analyzer understands the XON/XOFF handshaking,
nothing should be lost, and there is nothing to gain by writing your own
interrupt service routines, (unlike MS-DOS, where if an application wants
interrupt-driven I/O in a serial port, IT has to supply the
interrupt-handling routines.)
> Thanks for the help
> Silvio
I can't help you do what you SAY you want to do, but if you'd read
what I say, it could help you do what you NEED to do.
Good Luck
DoN.
--
Donald Nichols (DoN.) | Voice (Days): (703) 664-1585
D&D Data | Voice (Eves): (703) 938-4564
Disclaimer: from here - None | Email: <dnichols at ceilidh.beartrack.com>
--- Black Holes are where God is dividing by zero ---
###########################################################
Return-Path: beartrk!ceilidh!dnichols at uunet.UU.NET
Received: from bank.ecn.purdue.edu by ei.ecn.purdue.edu (5.65/1.30jrs)
id AA20017; Mon, 18 Mar 91 23:27:53 -0500
Received: from uunet.UU.NET by bank.ecn.purdue.edu (5.65/1.30jrs)
id AA28463; Mon, 18 Mar 91 23:27:47 -0500
Received: from beartrk.UUCP by uunet.uu.net with UUCP
(5.61/UUNET-primary-gateway) id AA24438; Mon, 18 Mar 91 23:27:43 -0500
Received: by beartrk.beartrack.com (smail2.5/AIX 2.2)
id AA29445; 18 Mar 91 23:15:49 EST (Mon)
Received: by ceilidh (4.12/2.4S)
id AA06261; Mon, 18 Mar 91 22:43:04 est
From: ceilidh!dnichols at uunet.UU.NET (DoN Nichols)
Message-Id: <9103190343.AA06261 at ceilidh>
Subject: Re: Logic Analyzer interface
To: @beartrk.UUCP:uunet!ecn.purdue.edu!picano (Silvio Picano)
Date: Mon, 18 Mar 91 22:42:43 EST
Reply-To: dnichols at ceilidh.beartrack.com
In-Reply-To: <9103171614.AA01020 at ei.ecn.purdue.edu>; from "Silvio Picano" at Mar 17, 91 11:14 am
X-Mailer: ELM [version 2.3 PL2]
Status: O
"Silvio Picano says:"
>
>
> Thanks for the additional info.
> Now, I understand what you were originally saying.
>
> I have the code partially working...The only problem left is
> the failure in reading the EOF character sent by the logic
> analyzer. My read() call is not recognizing the EOF and continues
> awaiting more serial data.
From /usr/include/sys/termio.h:
/* control characters */
#define VINTR 0
#define VQUIT 1
#define VERASE 2
#define VKILL 3
#define VEOF 4 ***** HERE *****
#define VEOL 5
/*----- LOTS DELETED BETWEEN THESE -----*/
/*
* Ioctl control packet
*/
struct termio {
unsigned short c_iflag; /* input modes */
unsigned short c_oflag; /* output modes */
unsigned short c_cflag; /* control modes */
unsigned short c_lflag; /* line discipline modes */
char c_line; /* line discipline */
unsigned char c_cc[NCC]; /* control chars */ AND HERE
};
Once you have the rest of your structure built, assuming that you
have named your termio structure 'packet':
packet.c_cc[VEOF] = 026;
or, whatever your eof character actually is, instead of 026, then write it
back to the system. If there is more than one character in the EOF
sequence, pick the one which is least likely to appear in valid data, since
there are no provisions for a multi-character EOF sequence.
Note that the default EOF character CEOF is defined as 04 (^d)
This should finish your input needs.
Good Luck.
> The only solution I can come up with is using non-blocking
> read() calls and a software timeout loop.
Only if there is no other option!!! There IS a better way! The
options for handling serial port I/O in sysV are quite powerful, it's just hard
to find good programming hints.
> Thanks
You're welcome.
--
Donald Nichols (DoN.) | Voice (Days): (703) 664-1585
D&D Data | Voice (Eves): (703) 938-4564
Disclaimer: from here - None | Email: <dnichols at ceilidh.beartrack.com>
--- Black Holes are where God is dividing by zero ---
###########################################################
###########################################################
###########################################################
Silvio Picano (3/14/91)
Files:
HPprintREADME (this file)
HPprintdaemo.c (C source code)
Originally stored in ei:~/Admin/SYSTEMV/ subdirectory
###########################################################
HP Brief Overview:
HP logic analyzer (DTE) 'screen dumps' (via RS232C) to
AT&T PC (DTE), which collects all the data to a file.
The AT&T PC then sends the file to an Epson printer
in 'raw' mode (i.e., HP outputs in Epson mode already,
so the data does not need to be 'worked on')
###########################################################
Wiring Details:
A single 'NULL Modem' cable is necessary between the
RS232 ports of the HP Logic Analyzer and the AT&T PC.
A NULL Modem configuration is necessary because both
devices are considered DTE (i.e., data terminal
equipment). The following schematic represents the
standard NULL Modem cable:
DB-25 Male Pin Assignment DB-25 Male Pin Assignment
------------------------- -------------------------
Protective Protective
Ground 1 <-------------------------------> 1 Ground
TxD 2 <-------------------------------> 3 RxD
RxD 3 <-------------------------------> 2 TxD
Signal Signal
Ground 7 <-------------------------------> 7 Ground
RTS 4 <---| |---> 4 RTS
CTS 5 <---| |---> 5 CTS
DSR 6 <---| |---> 6 DSR
CD 8 <---| |---> 8 CD
DTR 20 <---| |---> 20 DTR
This cable MUST be wired to the AT&T, combo-expansion
board, port #2 (i.e., tty002) because the program
explicity looks for serial input on this port.
Physically, port #2 is located on the extreme bottom
right corner on the back of the PC.
###########################################################
HP Logic Analyzer Setup:
Two of the default HP RS232 port's paramemters MUST
be changed. In the "I/O MENU", select the "RS-232C
Configuration" sub-menu to alter the following
paramemters:
1. Change "Printer" to "Alternate" mode.
(This configures the HP to transmit data in Epson
Format. Otherwise, the data sent to the port will be
HP's own raster format for ThinkJet printers (which
will print 'garbage' to the Epson.)
2. Change "Paper width" to "13.5inch"
(This will properly allow the correct Form Feed when
the printout is completed.)
The other parameters MUST not be changed:
Protocol Xon/Xoff
Data Bits 8
Stop Bits 1
Parity None
Baud Rate 9600
(Ref: HP 1650A/1651A Logic Analyzers Reference Manual,
Chapter 11: Making Hardcopy Prints)
###########################################################
Printer Setup:
The only requirement here is that the printer used must
supports graphics. The current Epson fx-286 printer
does support graphics.
If a different line printer is desired, it MUST support
Epson mode definitions AND Epson graphics.
The Epson output could be enlarged by turning OFF
compressed mode (compressed mode is the default).
To do this requires changing the DIP switches inside
the printer or by programming the 3 keys on top of the
printer.
###########################################################
AT&T PC Setup:
1. The cable MUST be wired to port #2 (tty002) of the AT&T
PC combo-expansion board (See WIRING section above).
2. The "HPprintdaemon" is the background process that
awaits input on the serial port and prints the
screen dump when the transmission from the HP logic
analyzer is complete. ("ps -e" should show the
running process.)
3. Using the 'install' login, you MUST disable the 'getty'
process from tty002 (this is done so that the 'getty'
process and the 'HPprintdaemon' do not 'battle' to read
the single serial input data).
Dive into the 'Administration' menu, dive into the
'Hardware Setup' menu, dive into 'RS232 Expansion'
menu, dive into "Port2", and change the type (from
"None" or "Terminal") to "None". This will kill the
getty process on tty002 (port 2). Now, my program
has full control over tty002.
4. "HPprintdaemon" resides in /etc/ and is
automatically started when the system is rebooted
(in the rc and/or rcgood file). To see if it is
running, simply perform a "ps -e" at the prompt.
###########################################################
"HPprintdaemon" Background Operation:
The background process (called "HPprintdaemon") awaits
data on tty002 and logs all valid data to the file
"/tmp/HPlogic". When a software timeout occurs (HP
finishes it's data transmission), the "/tmp/HPlogic"
file is piped directly to the "raw" line printer
(i.e., "cat /tmp/HPlogic > /dev/rawlp"). When this
is completed, the file /tmp/HPlogic is wiped clean
and awaits the next screen dump.
The next screen dump CANNOT begin until the current
(physical) printout is completed. Otherwise, only a
partial screen dump will be logged in /tmp/HPlogic.
(A warning could be sent to all users (i.e., "wall
instruction) but I do not envision a problem here.)
###########################################################
"HPprintdaemon" Sample Usage:
To use, simply 'dive' into the "I/O Submenu" on the HP
logic analyzer, select the "Print" or the "Print All"
options. The screen dump takes approxiamtely 35
seconds, then the printer will require about 30 seconds
to print.
Do not begin another screen dump until the current
printout from the printer is completed, otherwise,
only a partial screen dump will be accumulated.
###########################################################
###########################################################
###########################################################
/* Silvio Picano (3/14/91)
HP logic analyzer (DTE) 'screen dumps' (via RS232C) to
AT&T PC (DTE), which collects all the data to a file.
The AT&T PC then sends the file to an Epson printer
in 'raw' mode (i.e., HP outputs in Epson mode already,
so the data does not need to be 'worked on')
See HPprintREADME file for complete information.
To compile:
$ cc HPprintdaemo.c -o HPprintdaemon
*/
#include <stdio.h>
#include <fcntl.h>
#include <string.h>
#include <termio.h>
#include <errno.h>
/* when we get the 'NULL_LIMIT' number of characters read(), we
are done accepting the current screen dump from the HP */
#define NULL_LIMIT 3000
main() {
char *tmp_file= "/tmp/HPlogic",
*command= "cat /tmp/HPlogic > /dev/rawlp",
buf; /* holds single character */
int portfpB, /* 'blocking' file pointer to serial port */
portfpN, /* 'non-blocking' file pointer to serial port */
file_fp; /* file pointer to data file */
int NULL_count, /* EndOfFile counter */
forkvalue,
bytes;
unsigned nbytes=1; /* receieve one byte at a time */
struct termio B_HPanalyzer; /* define a 'blocking' port */
struct termio N_HPanalyzer; /* define a 'non-blocking' port */
void SerialPort(), Openfile();
if( (forkvalue= fork()) == -1 ) {
perror("\nfork() failed.");
exit(0);
}
/* force parent process to exit */
else if(forkvalue != 0)
exit(0);
/* child process continues (in the background) */
/* initialize 'blocking' & 'non-blocking' ports */
SerialPort(&portfpB,&B_HPanalyzer,(int) O_RDONLY);
SerialPort(&portfpN,&N_HPanalyzer,(int) (O_RDONLY|O_NDELAY));
while(1) {
/* try to open the target data file */
Openfile(tmp_file,&file_fp);
/* read 1st datum on serial port and write into file.
read() will 'block' till data is available */
if( (bytes= read(portfpB,&buf,nbytes)) < 0) {
perror("\nmain: 1st read() from port failed");
exit(0);
}
if(write(file_fp,&buf,bytes) < 0) {
perror("\nmain: 1st write to target data file failed");
exit(0);
}
NULL_count= 0; /* reset the EOF counter */
/* until we get a long period of no character input */
while(NULL_count < NULL_LIMIT) {
if( (bytes= read(portfpN,&buf,nbytes)) < 0) {
/* non-blocking read()'s */
perror("\nmain: 2nd read() from port failed");
exit(0);
}
else if(bytes == 0) {
/* no character available: increment EOF counter */
NULL_count = NULL_count + 1;
}
else if(bytes == nbytes) {
/* valid character input */
if(write(file_fp,&buf,nbytes) < 0) {
perror("\nmain: 2nd write to target data file failed");
exit(0);
}
NULL_count= 0; /* reset EOF counter */
}
else {
/* unknown return value from read() */
perror("\nmain: non-blocking read return value");
exit(0);
}
}
/* escape to shell and print */
system(command);
}
} /* end main */
/* Reference: termio(7) and ioctl(2) of the AT&T SYSTEM V
User's Manual */
void SerialPort(port_fp,port_struct,port_modes)
int *port_fp;
struct termio *port_struct;
int port_modes;
{
/* connect the HP RS232 port ONLY to the
combo-expansion board, serial port #2 */
char *portname= "/dev/tty002";
/* open file pointer to serial port */
if( (*port_fp= open(portname,port_modes)) < 0 ) {
perror("\nSerialPort: Port cannot be opened");
exit(0);
}
/* The current terminal parameters are fetched and
stored in a termio structure */
if( ioctl(*port_fp, TCGETA, port_struct) < 0 ) {
perror("\nSerialPort: get structure error");
exit(0);
}
port_struct->c_iflag= IXOFF; /* Enable input Xon/Xoff control */
port_struct->c_oflag= 0; /* output treatment off */
/* Hardware control of terminal:
9600 baud, 8 bits, Enable receiver,
Local line: else dial-up */
port_struct->c_cflag= B9600 | CS8 | CREAD | CLOCAL;
port_struct->c_lflag= 0; /* line discipline off */
/* Those terminal parameters that can be stored in a
termio structure are set from the values stored
in that structure. The change is immediate. */
if( ioctl(*port_fp, TCSETA, port_struct) < 0 ) {
perror("\nSerialPort: set structure error");
exit(0);
}
/* flush the input queue */
if( ioctl(*port_fp, TCFLSH, (int) 0) < 0 ) {
perror("\nSerialPort: Flushing error");
exit(0);
}
}
void Openfile(filename,fp)
char *filename;
int *fp;
{
int oflag;
/* data file flags: read/write file, return immediately,
wipe out file on creation, append after each write,
create if it does not exist */
oflag= O_RDWR | O_NDELAY | O_TRUNC | O_APPEND | O_CREAT;
if( (*fp= open(filename,oflag)) < 0 ) {
perror("\nOpenfile: Could not open filename");
exit(0);
}
}
More information about the Comp.sys.3b1
mailing list