Hi
I'm involved in a project that will be hooking about 16 RS422 channels
into a linux PC. We'll probably be running at about 19.2 or 9600
talking to a piece of equipment which for NDA reasons will have to
remain nameless (and, no it's not a flying bomb with a long serial cable
or other military
Hi
Please cc me or reply directly as I'm not subscribed to linux-serial.
I hope this isn't considered off-topic for linux-serial.
Are there any alternatives to polling the modem control lines to
figure out if they have changed at all? Is it possible to set
something to get say a signal to indica
On Tue, May 16, 2000 at 09:03:40PM -0600, Vern Hoxie wrote:
> On Tue, 16 May 2000, Craig Schlenter wrote:
>
> > Are there any alternatives to polling the modem control lines to
> > figure out if they have changed at all? Is it possible to set
> > something to get sa
On Wed, May 17, 2000 at 10:52:04AM -0700, Michael Harig wrote:
> Craig,
>
> remember that Linux is a multitasking kernel with no (generic) real time
> capabilities. Your process frequently gets interrupted for an unspecified
> amount of time. If a (serial) IRQ occurs then, the signal has to be me
On Wed, May 17, 2000 at 01:15:07PM -0700, Michael Harig wrote:
[snip]
> real-time or not, RTLinux may give you the capability to avoid this. my
> objection is, that linux kernel really should be able to schedule & notify
> a process in about 1 ms if a IRQ occured and the process demanded the
> not
On Tue, May 16, 2000 at 04:06:50PM -0400, [EMAIL PROTECTED] wrote:
> It is a pity you couldn't be bothered to read linux-serial. It is not a
> terribly busy list, but this very question has been asked and answered
> in the last week. Maybe you can find some list archives somewhere.
It's not a q
On Wed, May 17, 2000 at 04:16:24AM -0400, [EMAIL PROTECTED] wrote:
> Well, at a guess, you can wait for me to do a courtesy-call capable
> kernel, which may be a while, and a good while more for it to be
> accepted, or you can do it yourself, or you can solve the problem in a
> totally unexpected
On Wed, May 17, 2000 at 07:28:32AM -0700, Tom Glass wrote:
> What kind of time resolution are you needing? I have an application
> that monitors one serial port for incoming messages in an infinite
> loop. For some of the messages I initiate a child process that
> communicates with a robot, volt
On Wed, May 17, 2000 at 02:49:09PM -0400, Theodore Y. Ts'o wrote:
[SNIP]
> Is the linux-serial archived anywhere? It seems just last week I
> answered the question about using TIOCMIWAIT to allow you a process to
> sleep until a specified set of control lines change. Unfortunately, I
> can't fin
Hi
See attachment for a patch that makes my PCCOM8 "work for me" (TM).
Card is manufactured by decision.com.tw AFAIK. I have no connection
with them other than that I have a few of their serial cards.
Patch is against the 5.01 serial driver. I'm not suggesting it be
included yet, just looking
On Thu, Aug 10, 2000 at 12:15:27PM -0400, Stuart MacDonald wrote:
> From: "Craig Schlenter" <[EMAIL PROTECTED]>
> > 0x0002 should be replaced by PCI_DEVICE_ID_DCI_PCCOM8 with
> > #define PCI_DEVICE_ID_DCI_PCCOM8 0x0002
> > in pci.h (pci_ids.h?) or some
On Thu, Aug 10, 2000 at 02:22:02PM -0400, Theodore Ts'o wrote:
> [me]
> 5.01 wouldn't compile in 2.2.16. Had to change the rs_init thing as
> in patch ... Ted?
>
> I haven't tried to compile a 5.x serial driver into a 2.2 kernel in a
> while. How does it not work? __init
Hi
Attached is my port of decision's serial patch to 2.2.16 as promised. I
have removed some bits out of the original patch (available from
decision.com.tw iirc, against some oldish 2.2.x kernel) that I didn't
think were important. What I know about the serial driver borders on
dangerous so YMMV.
> [Stu]
> > If you didn't explicitly mean the subsystem and subvendor slots
> > to be PCI_ANY_ID, then you should use lspci -v to find out
> > what values those are and use them.
> [me]
> Well spotted. I cut-and-pasted large bits of it from lines above
> and fiddled till it worked. I had a vague s
14 matches
Mail list logo
