Serial port programming problems

2010-05-01 Thread Neil O'Brien
I run OpenBSD 4.6 (i386) on a PCEngines ALIX2c3, as a low power file/web/DHCP server. I would like to have this machine regularly retrieve data from an instrument which communicates over RS-232. I'm using a Prolific USB-RS232 converter (full dmesg for the ALIX below). I have no protocol documenta

Re: Serial port programming problems

2010-05-02 Thread Neil O'Brien
On Sat, May 01, 2010 at 15:30:28 -0700, J.C. Roberts wrote: > > status = tcsetattr(fd, TCSANOW, &options); > > How does it behave if you use "TCSAFLUSH" rather than "TCSANOW" ? I made that substitution and added a #define DEBUG 1 The resulting binary sometimes fails to return and I then have to

Re: Serial port programming problems

2010-05-02 Thread Aaron Mason
On Sun, May 2, 2010 at 5:33 PM, Neil O'Brien wrote: > On Sat, May 01, 2010 at 15:30:28 -0700, J.C. Roberts wrote: >> > status = tcsetattr(fd, TCSANOW, &options); >> >> How does it behave if you use "TCSAFLUSH" rather than "TCSANOW" ? > > I made that substitution and added a > #define DEBUG 1 > >

Re: Serial port programming problems

2010-05-02 Thread Neil O'Brien
On Sun, May 02, 2010 at 20:56:36 +1000, Aaron Mason wrote: > On Sun, May 2, 2010 at 5:33 PM, Neil O'Brien wrote: > > On Sat, May 01, 2010 at 15:30:28 -0700, J.C. Roberts wrote: > >> > status = tcsetattr(fd, TCSANOW, &options); > >> > >> How does it behave if you use "TCSAFLUSH" rather than "TCSA

Re: Serial port programming problems

2010-05-02 Thread J.C. Roberts
On Sun, 2 May 2010 16:45:44 +0100 "Neil O'Brien" wrote: > On Sun, May 02, 2010 at 20:56:36 +1000, Aaron Mason wrote: > > On Sun, May 2, 2010 at 5:33 PM, Neil O'Brien > > wrote: > > > On Sat, May 01, 2010 at 15:30:28 -0700, J.C. Roberts wrote: > > >> > status = tcsetattr(fd, TCSANOW, &options);

Re: Serial port programming problems

2010-05-02 Thread J.C. Roberts
On Sun, 2 May 2010 12:01:59 -0700 "J.C. Roberts" wrote: > The other problem is understanding what is happening. Unless you > specifically configured the descriptor to return immediately, your > read(2) call will sleep until it gets the requested number of bytes > from the descriptor, until an in