The other issue I see is that sizeof(buff) may or may not
be the expected return.
char buff[1024];
sizeof(buff) = 1024
char *buff;
buff = malloc(1024);
sizeof(buff) = 4 or 8 depending
So I would rework this entire function using poll with a
timeout rather than read which could block indefinitely and
a well defined io mechanism.
Shane
On Tue, Aug 31, 2010 at 04:31:05PM -0400, Trevor Saunders wrote:
> Hi,
>
> > { /*Receive incoming serial data.*/
> > STOP=FALSE;
> > res = 0; /*eventually shows where buffer ends*/
> > sleep(1);
> > /*Force a wait to cause receive buffer to stabilize.*/
> > while (STOP==FALSE) { /* loop for input */
> >
> > res = read(fd,buf,sizeof(buf)); /* returns after sizeof(buf) chars have been inputed or timeoutt */
> >
> >
> > STOP=TRUE;
> > }
> > buf[res]=NULL; /* so we can printf... */
>
> that looks suspect to me, I forget what the spec says NULL means in that
> case, but I'd use '\0' or just 0 instead, but what you do may work. I
> also suspect that if read reads sizeof(buf) bytes and then you set
> buf[sizeof(buf)] = 0 you will possibly touch memory that isn't yours.
>
> Trev
>
>
> > /*That makes sure there is a null to form a strint.*/
> > /*printf("%s\n", buf); */
> > return;
> > } /*Receive incoming serial data.*/
> >
> > The only thing I can adjust in the port setup is a
> > variable that is either kept at 0 so it will time out if no
> > characters are received at all or to, say, 1024 or whatever the
> > buffer is defined as. This really doesn't effect the issue but
> > if set to > 0, the timeout never happens until at least one
> > character is received.
> >
> > Here is the initialization routine. Hardware flow
> > control is not an option as the receiver does not recognize
> > RTS/CTS.
> >
> > #include "headers.h"
> > #include "defs.h"
> > #include "externs.h"
> >
> >
> > void portinit()
> > {
> > struct termios oldtio,newtio;
> >
> > fd = open(MODEMDEVICE, O_RDWR | O_NOCTTY );
> >
> > if (fd <0) {perror(MODEMDEVICE); exit(-1); }
> >
> > tcgetattr(fd,&oldtio); /* save current port settings */
> >
> > /*Clear everything about that port.*/
> > bzero(&newtio, sizeof(newtio));
> >
> > newtio.c_cflag = BAUDRATE | CS8 | CLOCAL | CREAD;
> >
> > newtio.c_iflag = IGNPAR | ICRNL;
> >
> > newtio.c_oflag &= ~OPOST;
> >
> >
> > /* set input mode (non-canonical, no echo,...) */
> >
> > newtio.c_lflag = 0;
> >
> > newtio.c_cc[VTIME] = 20; /* inter-character timer .1 seconds/tick */
> > newtio.c_cc[VMIN] = 0; /*Blocks until VMIN chars or timeout.*/
> >
> >
> > tcflush(fd, TCIFLUSH);
> >
> > tcsetattr(fd,TCSANOW,&newtio);
> >
> > return;
> > }
> >
> > I have tried tcflush at the end of a receive with absolutely no
> > effect on anything.
> > Shane W writes:
> > > Hmm, reading from the ttySx device should never give
> > > duplicatedcharacters so it sounds like something is up with
> > > your buffer. I wouldn't zero it out but just keep note of
> > > the number of bytes read and when to stop. Also, after your
> > > first read returns, don't sleep but rather call poll() on
> > > the device which will return when there is data ready to be
> > > read.
> >
> > Yes. It is like it is already ready to receive data too
> > early.
> >
> > The hardware is a USB-based 8-port adaptor which behaves
> > quite normally when using Kermit or other serial routines.
> >
> > Thanks.
> >
> > _______________________________________________
> > Blinux-list mailing list
> > Blinux-list@xxxxxxxxxx
> > https://www.redhat.com/mailman/listinfo/blinux-list
> _______________________________________________
> Blinux-list mailing list
> Blinux-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/blinux-list
_______________________________________________
Blinux-list mailing list
Blinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/blinux-list