Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!samsung!noose.ecn.purdue.edu!root From: picano@perch.ecn.purdue.edu (Silvio Picano) Newsgroups: comp.sys.3b1 Subject: (SUMMARY) (LONG) Logic Analyzer Printouts on a 3b1 Message-ID: <1991Mar22.234527.19120@noose.ecn.purdue.edu> Date: 22 Mar 91 23:45:27 GMT Sender: root@noose.ecn.purdue.edu (ECN System Management) Distribution: usa Organization: Purdue University Engineering Computer Network Lines: 778 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@mthvax.cs.miami.edu adams@ucunix.ecn.purdue.edu dnichols@ceilidh.beartrack.com dave@Galaxia.Newport.RI.US Silvio ########################################################### Return-Path: dnelson@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@en.ecn.purdue.edu); Wed, 27 Feb 91 17:29:33 -0500 Date: Wed, 27 Feb 91 17:29:33 -0500 From: Dru Nelson Message-Id: <9102272229.AA08404@mthvax.cs.miami.edu> To: picano@en.ecn.purdue.edu Subject: Re: Logic Analyzer Printouts on a 3b1 (Please Help) Newsgroups: comp.sys.att References: <1991Feb27.195150.11518@en.ecn.purdue.edu> Hello, Post to comp.sys.3b1; you might find some better help there. -- %% Dru Nelson %% Miami, FL %% Internet: dnelson@mthvax.cs.miami.edu %% ########################################################### Return-Path: adams@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@ucunix.san.uc.EDU (James Warner Adams) Subject: Re: Logic Analyzer Interface to a 3b1 (Please Help) In-Reply-To: <1991Feb27.193918.8982@en.ecn.purdue.edu> To: picano@en.ecn.purdue.edu Message-Id: <9102281841.AA04917@ucunix.san.uc.edu> X-Envelope-To: picano@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@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@ceilidh.beartrack.com (DoN Nichols) Newsgroups: comp.sys.3b1 Subject: Re: Logic Analyzer Printouts via 3b1 (Please Help) Message-ID: <1991Mar1.021654.14620@ceilidh.beartrack.com> Date: 1 Mar 91 02:16:54 GMT Article-I.D.: ceilidh.1991Mar1.021654.14620 References: <1991Feb28.003345.5188@en.ecn.purdue.edu> Distribution: usa Organization: D and D Data, Vienna, VA. Lines: 63 In article <1991Feb28.003345.5188@en.ecn.purdue.edu> picano@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@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: --- Black Holes are where God is dividing by zero --- ########################################################### Return-Path: galaxia!dave@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@Galaxia.Newport.RI.US (David H. Brierley) Message-Id: <9103030253.AA11082@Galaxia.Newport.RI.US> To: picano@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@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@galaxia.newport.ri.us; Work: dhb@quahog.ssd.ray.com Send comp.sources.3b1 submissions to comp-sources-3b1@galaxia.newport.ri.us %% Can I be excused, my brain is full. ** ########################################################### Return-Path: beartrk!dnichols@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@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@ceilidh.beartrack.com In-Reply-To: <9103112027.AA22192@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: --- Black Holes are where God is dividing by zero --- ########################################################### Return-Path: beartrk!ceilidh!dnichols@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@uunet.UU.NET (DoN Nichols) Message-Id: <9103190343.AA06261@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@ceilidh.beartrack.com In-Reply-To: <9103171614.AA01020@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: --- 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 #include #include #include #include /* 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); } }