ts-7000
[Top] [All Lists]

[ts-7000] Re: RS232 Questions/Problems

To:
Subject: [ts-7000] Re: RS232 Questions/Problems
From: "trucmuch_59" <>
Date: Thu, 03 Jan 2008 15:02:06 -0000
Well 2 things comme to my mind.
First the com3 is not /dev/TTYSo (o as oscar)
but /dev/ttyTS0 (zero)

that's for one,
and for the second port com1, did you remove the getty config /etc/inittab
Don't forget /dev/ttyAM1 is for com2, and I think /dev/ttyAM0 is for com1.

that will fix both problem.
But at least it will be a good idea to check the return of some of
your command (like open), and print the errno code.

regards,
arno


--- In  "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,"/dedv/TTYSo");
>          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

<*> 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/
 

<Prev in Thread] Current Thread [Next in Thread>
Admin

Disclaimer: Neither Andrew Taylor nor the University of NSW School of Computer and Engineering take any responsibility for the contents of this archive. It is purely a compilation of material sent by many people to the birding-aus mailing list. It has not been checked for accuracy nor its content verified in any way. If you wish to get material removed from the archive or have other queries about the archive e-mail Andrew Taylor at this address: andrewt@cse.unsw.EDU.AU