ts-7000
[Top] [All Lists]

[ts-7000] Complete lock with RS485 on COM2 and no getty on COM1

To:
Subject: [ts-7000] Complete lock with RS485 on COM2 and no getty on COM1
From: "itguysam" <>
Date: Tue, 26 Aug 2008 18:44:37 -0000
*** As I worked on this email I found the solution but I am still
posting this so that anyone else who finds this problem wont have to
figure this out ***

Hey guys, I have run into a problem that is beyond my linux-fu to fix.
I am trying to use both serial ports at the same time, a Full Duplex
RS485 port on COM2 and a RS232 connection on the COM1 port. We have
been using the RS485 port to talk to our motor controllers for months
so I'm pretty sure that the code is solid. We have been prototyping a
new subsystem that we talk to on the regular COM1 (DB9) port. I knew
from experience with the rs485 port that the getty process that gets
started in inittab needs to be stopped or it will hijack the returned
data. So I turned it off and worked on testing that subsystem by
itself on COM1. When I was finished with testing I went back to my
full program, which uses both COM1 and COM2 and it completely hung the
box. Its so bad that it kills the session, all other attached
sessions, stops all incoming sessions so you can't log back in. Pretty
much the only thing you can do is ping the box. My only resort was to
reset the box (which was a huge PITA since the box in question was
offsite). 

I spent a few hours today looking into the problem and trying to
reproduce the problem here and I eventually found that it was hanging
as I called.

err = ioctl (mFile, TIOC_SBCS485, &mcr);

If I have the "/sbin/getty -L 115200 ttyAM0 &" process running it
worked fine, as soon as that process was turned off it went into this
call and blocked forever. I hooked up a null modem cable and found
that the text "setting FULL duplex" was spat out on the serial port
when the RS485 was enabled. I spent a while looking at this problem
before I finally figured out that the problem was the stupid jumpers.
What I think is that the JP2 jumper is the only flag the kernel looks
at to see if it should be printing debug messages to the serial port
but if a getty process isn't running then nothing ever prints the
buffer and it waits forever. (either that or its seg faulting or
something inside the kernel). Anyway, make sure to remove the JP2
jumper if you are going to disable the getty process on ttyAM0. I
searched the kernel source and there are around 52 thousand calls to
this printk() function and one of them will probably bite you in the end.





------------------------------------

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>
  • [ts-7000] Complete lock with RS485 on COM2 and no getty on COM1, itguysam <=
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