Date: Fri, 27 Oct 2000 23:34:21 +0000 (GMT)
From: Terry Lambert <tlambert@primenet.com>
To: maret@atrada.net (Alexander Maret)
Cc: phk@critter.freebsd.dk ('Poul-Henning Kamp'), msmith@mass.osd.bsdi.com ('msmith@mass.osd.bsdi.com'), freebsd-hackers@FreeBSD.ORG ('freebsd-hackers@freebsd.org')
Subject: Re: Accessing the tty structure of an opened device
Message-ID: <200010272334.QAA01336@usr01.primenet.com>
In-Reply-To: <58A002A02C5ED311812E0050044517F00D2614@erlangen01.atrada.de> from "Alexander Maret" at Oct 27, 2000 03:29:50 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> > You will need to do this in a device driver, there is no way you > > can reliably measure that from userland. > > > > Trust me on this: I've tried. > > That's what I wanted to do. I wanted to write a character device > which on read() passes the last IR-code. > > Well as Mike Smith told me: "you cannot poll the serial line at > anything like a useful speed to perform IR decoding" my hopes are > all gone to get a simple solution. > > Do I have to write my own serial driver to get what I want or > is it possible to use functions of the "build in" serial > device driver? You will have to modify the serial driver somewhat to be able to externalize the interruptable events. Some of these events are handled internally. My personaly suggestion, since you created this dongle on your own, would be to drop uses of DCD, and use CTS/RTS as the signalling method instead. To do this right, you will need to set your FIFO depth on the UART to nothing, so it doesn't delay delivery of interrupts (some FIFO implementations delay signalling of events intentionally to reduce processing overhead, and only deliver when they would deliver data). You will also effectively be using every character as a wakeup character, to avoid queueuing at the tty pseudo device boundary (or would, last time I looked). I would specifically suggest you implement this as a line discipline, since most of what you would need to do is there. If you are not adamant about clock speed on input, this should work in a non-noisy environment. For a noisy environment, you will want to poke the UART at some multiple of your expected frequency to get it to reinterrupt, and then debounce it in software, based on your expected event boundary crossing frequency vs. the (higher) poking frequency. If you plan to implement this as a line discipline, you should look at the SLIP, PPP, and mouse line disciplines; the first two will tell you about the wakeup code, and the second will tell you about FIFO depth. Looking back over all this, it would be useful to have the ability to generalize all serial port data using a line discipline and externalization of all possible interrupt signals... BUT... it would probably be easier for you, in the short run, to just take the serial and IR driver code, and write a custom driver that takes over the serial port, and disable the standard serial driver from grabbing it using kernel configuration options. If I were doing it, I'd probably want to open up the ports for people to hack on every possible little thing they could hack on, but then I don't have a deadline, and I wouldn't really care how much work it would take, and I don't have a specific hack in mind, like you do. Sort of the current parallel port code, applied to serial ports... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200010272334.QAA01336>