ioctl(port, FIONREAD, &bytes) should also let you know the number of
bytes pending.
--- In "Robert Bond" <> wrote:
>
> These are all good questions.
>
> Also, you might try select() as a way to see if data is available.
I've had
> good luck with that approach on a TS-7200. My TTY setup and polling
code is
> available on rgbwireless.com in the download section.
>
> Bob Bond
>
> -----Original Message-----
> From: On
Behalf Of
> Jim Jackson
> Sent: Wednesday, January 02, 2008 2:17 PM
> To:
> Subject: Re: [ts-7000] RS232 Questions/Problems
>
>
>
> Hi,
>
> off the cuff...
>
> You don't show how you read/write to the device. Are you sure you
are not
> doing some flushing before reading? A fast return might get data back
> before a flush, and hence be lost in the flush.
>
> And you are sure the device generates parity? One possibility could be
> that the fast response has wrong parity, while late response happens to
> have right parity?
>
> On Wed, 2 Jan 2008, machv0 wrote:
>
> > Hi,
> >
> > I'm hoping someone out there has some thoughts or suggestions that can
> > help me with a problem I'm having. I'm using a TS7260 connected to 2
> > multi port switching valves on com1 and com3. I'm using RS232
code that
> > I've been using for a while and until now was fairly confident worked
> > well. However what I'm seeing in this case is that if I query the
valves
> > and they don't actually perform any processing they respond pretty
fast,
> > ~1-2ms, and when I attempt to read the com port there is nothing
in the
> > serial buffer. If on the other hand the valves have to do some
> > processing, for instance changing position, the response will be
closer
> > to 20ms and then I receive the data as expected.
> >
> > I know that the response is sent in both cases as I can put a serial
> > sniffer in between the TS7260 and valves and see the response/times as
> > seen by the sniffer. This happens on both com1 and com3, so it's not
> > tied to a specific com. Since it's RS232 I'm thinking response time
> > shouldn't make a difference, assuming the kernel serial driver detects
> > the response and buffers it appropriately, but maybe this is naive
> > thinking.
> >
> > Below are some snippets of code that I use for opening/configuring the
> > ports. One of the things I need to change to see if it makes a
> > difference here is the INPCK parameter. I've always set this in the
> > past, but maybe it is problematic? Due to some unforeseen/unrelated
> > problems I haven't been able to check this and probably won't be
able to
> > for a couple days. Instead I'm posting here.
> >
> > Normally when reading I use ioctl(...) to check for data before
reading
> > to insure that the response has completed, but I've tried both using
> > ioctl(...) and calling read(...) directly with the same results.
> >
> > The valves themselves are TTL devices connected to a 232-ttl
converter.
> > I'm pretty certain that this is at least working to some degree as
> > transmit from the TS7260 to the valves works fine, and responses are
> > fine if the valves response is slower. Also, responses from the valves
> > are seen on the serial sniffer in both cases. Unfortunately I don't
> > think I have the ability to change the valves behavior.
> >
> > I've got a scope that I can hook up and analyze the responses in each
> > case, but unfortunately I'm stuck for the time being waiting on parts.
> > In the meantime I thought I'd check here since I'm a bit perplexed at
> > how to proceed.
> >
> > //////////////////////////////////////
> >
> > if(m_Port==3)
> > sprintf(serialdevice,"/dev/ttyTS0");
> > else
> > sprintf(serialdevice,"/dev/ttyAM%d",m_Port-1);
> >
> > m_CommDev = open(serialdevice, O_RDWR | O_NOCTTY |
O_NONBLOCK);
> > m_Open = (m_CommDev==-1) ? false : true;
> >
> > ...
> >
> > if(m_Open)
> > {
> > tcgetattr(m_CommDev,&m_OldTermIO); //
save
> > current port settings
> > bzero(&m_NewTermIO, sizeof(m_NewTermIO)); //
clear
> > new port settings
> >
> > m_NewTermIO.c_cflag |= (CREAD | CLOCAL);
> > m_NewTermIO.c_cflag |= CS8;
> > m_NewTermIO.c_iflag |= INPCK;
> >
> > switch(m_BaudRate)
> > {
> > case 9600:
> > cfsetispeed(&m_NewTermIO,B9600);
> > cfsetospeed(&m_NewTermIO,B9600);
> > break;
> > case 19200:
> > cfsetispeed(&m_NewTermIO,B19200);
> > cfsetospeed(&m_NewTermIO,B19200);
> > break;
> > case 38400:
> > cfsetispeed(&m_NewTermIO,B38400);
> > cfsetospeed(&m_NewTermIO,B38400);
> > break;
> > case 57600:
> > cfsetispeed(&m_NewTermIO,B57600);
> > cfsetospeed(&m_NewTermIO,B57600);
> > break;
> > case 115200:
> > cfsetispeed(&m_NewTermIO,B115200);
> > cfsetospeed(&m_NewTermIO,B115200);
> > break;
> > }
> >
> > tcflush(m_CommDev, TCIFLUSH);
> > tcsetattr(m_CommDev,TCSANOW,&m_NewTermIO);
> > }
> >
> >
> >
>
>
>
> Yahoo! Groups Links
>
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|