From: Adam S. <at...@of...> - 2008-12-29 19:47:55
|
Hi Albert (and lirc-list CCed in case anyone else is interested), I've been playing with your libftdi driver for LIRC. I've updated the patch so that it'll apply to the CVS version of LIRC, and made it a bit more configurable so it'll work with other FTDI devices. My version of the patch is here: http://offog.org/stuff/lirc-ftdi-20081229.diff I've left it using pthreads for now, but since all the other lircd backends that need concurrency use a separate, forked process, it might be worth changing that too at some point. It all seems to work happily. If you've got any thoughts on the patch, I'd be interested to hear them... this seems like a simple enough bit of hardware to build that it'd be worth getting into upstream LIRC. I'm using the FT232R chip on an Arduino NG board (since I had a few of them around anyway) rather than an FTDI cable, but the principle is the same. I've just connected an IR receiver and LED to two of the FT232R's GPIO pins, which are brought out on a header on the board. (This might be the first Arduino application that doesn't involve the AVR chip at all!) http://offog.org/stuff/irduino.jpeg Here's the list of changes I made on top of your patch: commit 99630ecbe8a0ebfcc32a5f1c680b25c11931bce1 Author: Adam Sampson <at...@of...> Date: Mon Dec 29 17:46:10 2008 +0000 Add an option parser, and tidy up the comments. The "device name" can now contain various options, separated by commas, which let you specify the USB device and the input pin to use. This means this driver'll work for more or less any hardware based on the FTDI chip. The defaults match Albert's simple cable; for my hardware, I run: lircd -d serial=A4001doI,input=7 I haven't put an option in to select the output pin, since the driver doesn't use it yet; it'd be easy enough to do, though. commit 3c7c599401c4637133868556353ae1ae186a624c Author: Adam Sampson <at...@of...> Date: Mon Dec 29 17:11:56 2008 +0000 Initial rework to the FTDI driver. Most of this is stylistic changes to match the rest of LIRC's fairly idiosyncratic C style. Other changes: - Change the input and output pins, as a bodge for now for testing; my hardware's different from Albert. - Remove some debugging printfs. - Flatten out hwftdi_thread rather than having it be a bunch of nested ifs. - Call waitfordata() in hwftdi_readdata, which makes irrecord work. commit c5b0e0c0841ead01873c2b90a860ae0a5ef0341a Author: Adam Sampson <at...@of...> Date: Mon Dec 29 17:01:44 2008 +0000 Clean up how the FTDI backend is built to match the other backends. This is mostly making sure that lists that were in alphabetical order originally have the FTDI-related files added in the right place; I've also tweaked some build system messages to match the existing LIRC style. commit e65cf1fcef1caf5779c3f66df56128d234fe675e Author: Adam Sampson <at...@of...> Date: Mon Dec 29 16:50:21 2008 +0000 Link with -lpthread when the FTDI backend is used. I assume something else was pulling it in as a dependency for Albert; on my machine, it failed to link as was. commit 050b3240c5d85793439cc98b35652bbc1d8f13d0 Author: Adam Sampson <at...@of...> Date: Mon Dec 29 16:45:09 2008 +0000 Albert's original patch. I've tweaked this very slightly so it'll apply to lirc CVS -- the way hardware-specific libraries were handled had changed. commit 684435a7c692efd4ffd5f7f021ecbf5ce365ad0e Author: Adam Sampson <at...@of...> Date: Mon Dec 29 16:11:14 2008 +0000 Upstream lirc as of 2008-12-29 16:11. Thanks very much, -- Adam Sampson <at...@of...> <http://offog.org/> |
From: <li...@ba...> - 2008-12-29 20:30:07
|
Hi! Adam Sampson "at...@of..." wrote: [...] > If you've got any thoughts on the patch, I'd be interested to hear > them... this seems like a simple enough bit of hardware to build that > it'd be worth getting into upstream LIRC. - s/4/sizeof(lirc_t) - you probably can remove this set_nonblocking() stuff. I don't see why it should be required (there are systems where O_NONBLOCK is not defined? shiver ;)) - you are leaking the pipe file descriptors, close them - fork instead of thread Christoph |
From: Albert H. <al...@hu...> - 2008-12-29 22:13:13
|
Hello Adam, > I've been playing with your libftdi driver for LIRC. I've updated the > patch [...] > nice to hear that somebody actually managed to get it working ;-) > I've left it using pthreads for now, but since all the other lircd > backends that need concurrency use a separate, forked process, it might > be worth changing that too at some point. There should be no problem to move to a forked process I think. But I'm not a hero when it comes to working with patchfiles etc. Could you give me a hint how to apply your patch to the CVS version? How does your patchfile refer to 'a' and 'b' paths? while typing this reply a mail from Christoph came in with some additional hints too.. - s/4/sizeof(lirc_t) eeh... this indeed is a bit of a hack, and not portable. I think best is to define 'rxctr' to be of type lirc_t and use 'sizeof(lirc_t)' as the record length in the pipe. - you probably can remove this set_nonblocking() stuff. I don't see why it should be required (there are systems where O_NONBLOCK is not defined? shiver ;)) I just copied it somewhere from the net, didn't pay much attention to it. So a simple 'fnct()' call in place is more elegant then. - you are leaking the pipe file descriptors, close them oops - fork instead of thread I'd like to try to implement this, but I can't get Adam's patches to compile for me right now. > It all seems to work happily. > [..] it'd be worth getting into upstream LIRC. > Note that the transmitting part doesn't perform well. I've done some further testing, and there are really big 'gaps' in between the continous stream. This causes the transmitted carrier to contain unwanted pulses :-( When supporting reception only, the bitrate (and therefore the USB traffic) can be descreased significantly. > I'm using the FT232R chip on an Arduino NG board (since I had a few of > [...] http://offog.org/stuff/irduino.jpeg > :-) cool -- __________________________________________________________________ | _______ | | *Albert Huitsing* | | *Huitsing Embedded Systems* | | System Design | /|___|\ Dr. Mondenweg 5 | | al...@hu... | / \ 7831 JA Nw. Weerdinge | | | \ ___ / Phone: +31-(0)591-521222 | | \ \| | |/ Fax: +31-(0)591-522113 | | \______| http://www.huitsing.nl | | | | "/conformity is the uncomfortable feeling of wearing/ | | /somebody else's clothes; even when they don't fit/" | |__________________________________________________________________| |
From: <li...@ba...> - 2008-12-29 23:22:34
|
Hi! Albert Huitsing "al...@hu..." wrote: [...] > - you probably can remove this set_nonblocking() stuff. I don't see why > it should be required (there are systems where O_NONBLOCK is not > defined? shiver ;)) > I just copied it somewhere from the net, didn't pay much attention to > it. So a simple 'fnct()' call in place is more elegant then. No, please remove it altogether. There's no need to make the read end of the pipe non-blocking. Adam's latest patch looks fine otherwise. [...] >> It all seems to work happily. >> [..] it'd be worth getting into upstream LIRC. >> > Note that the transmitting part doesn't perform well. I've done some > further testing, and there are really big 'gaps' in between the > continous stream. This causes the transmitted carrier to contain > unwanted pulses :-( > When supporting reception only, the bitrate (and therefore the USB > traffic) can be descreased significantly. How about switching bitrate on demand? Christoph |
From: Albert H. <al...@hu...> - 2008-12-29 23:52:04
|
Hello all, > No, please remove it altogether. There's no need to make the read end of > the pipe non-blocking. > Adam's latest patch looks fine otherwise. > Adam's latest patch works fine here with my hardware. I've removed the non-blocking code and it still works. So the reader process is doing a select() then? or simply blocks until data available? Christoph: I'll take a look in your code and learn further. Adam: you really tweaked those last steps quickly, wow! Nice solution by the way using the 'usecs' variable, this way it is platform and type safe. > How about switching bitrate on demand? > the 'demand' being a static command line argument, or do you mean dynamically: *) waiting for initial starting edge with low bitrate *) dynamically switching to high bitrate for decoding I think the I/O buffers will ruin this idea, because decoding always lags behind realtime and it's too late in time to switch bitrate when the start-edge was detected. A static commandline argument on the other hand will be feasible though. Albert -- __________________________________________________________________ | _______ | | *Albert Huitsing* | | *Huitsing Embedded Systems* | | System Design | /|___|\ Dr. Mondenweg 5 | | al...@hu... | / \ 7831 JA Nw. Weerdinge | | | \ ___ / Phone: +31-(0)591-521222 | | \ \| | |/ Fax: +31-(0)591-522113 | | \______| http://www.huitsing.nl | | | | "/conformity is the uncomfortable feeling of wearing/ | | /somebody else's clothes; even when they don't fit/" | |__________________________________________________________________| |
From: <li...@ba...> - 2008-12-30 12:13:44
|
Hi! Albert Huitsing "al...@hu..." wrote: [...] > Hello all, >> No, please remove it altogether. There's no need to make the read end of >> the pipe non-blocking. >> Adam's latest patch looks fine otherwise. >> > Adam's latest patch works fine here with my hardware. I've removed the > non-blocking code and it still works. So the reader process is doing a > select() then? or simply blocks until data available? Your problem probably was caused by the missing waitfordata() in the initial code. [...] >> How about switching bitrate on demand? >> > the 'demand' being a static command line argument, or do you mean > dynamically: Change to a high bitrate if you are planning to transmit something and switch back once done. Christoph |
From: Adam S. <at...@of...> - 2008-12-30 13:52:05
|
On Tue, Dec 30, 2008 at 12:19:00AM +0100, Christoph Bartelmus wrote: > No, please remove it altogether. There's no need to make the read end > of the pipe non-blocking. OK; here's another version: http://offog.org/stuff/lirc-ftdi-20081230.diff Changes since the last one: - The pipe's no longer made non-blocking. (Looking at the other drivers, hw_commandir is the other one that does this; presumably that should be fixed too?) - Fixed the sample rate computation, having checked the FT232 datasheet: it should be 16 times the baud rate, not 32. (Albert, you'll need to double the time values in your lircd config -- but it now works with the config files out of the lirc distribution.) - Made the baud rate configurable, and made the default 4800 rather than 4500 since the FT232 can't do 4500 exactly. - Some minor cleanups. Thanks, -- Adam Sampson <at...@of...> <http://offog.org/> |
From: <li...@ba...> - 2008-12-30 21:54:27
|
Hi! Adam Sampson "at...@of..." wrote: > On Tue, Dec 30, 2008 at 12:19:00AM +0100, Christoph Bartelmus wrote: >> No, please remove it altogether. There's no need to make the read end >> of the pipe non-blocking. > OK; here's another version: > http://offog.org/stuff/lirc-ftdi-20081230.diff I've put this into CVS. [...] > - The pipe's no longer made non-blocking. (Looking at the other drivers, > hw_commandir is the other one that does this; presumably that should > be fixed too?) No, this is the child's read pipe, not the parent's. Christoph |
From: Albert H. <al...@hu...> - 2008-12-31 09:00:54
|
Hello, >> OK; here's another version: >> http://offog.org/stuff/lirc-ftdi-20081230.diff >> Adam: nice work, thanks for all your efforts! > I've put this into CVS. > > [...] > Christoph: thanks too! I've update my page at http://www.huitsing.nl/irftdi to reflect the changes. Albert -- __________________________________________________________________ | _______ | | *Albert Huitsing* | | *Huitsing Embedded Systems* | | System Design | /|___|\ Dr. Mondenweg 5 | | al...@hu... | / \ 7831 JA Nw. Weerdinge | | | \ ___ / Phone: +31-(0)591-521222 | | \ \| | |/ Fax: +31-(0)591-522113 | | \______| http://www.huitsing.nl | | | | "/conformity is the uncomfortable feeling of wearing/ | | /somebody else's clothes; even when they don't fit/" | |__________________________________________________________________| |
From: Adam S. <at...@of...> - 2008-12-29 22:43:04
|
On Mon, Dec 29, 2008 at 10:23:34PM +0100, Albert Huitsing wrote: > There should be no problem to move to a forked process I think. OK -- here's an updated version of the patch that uses a forked process, and fixes the other problems Christoph spotted (thanks!): http://offog.org/stuff/lirc-ftdi-20081229a.diff > Could you give me a hint how to apply your patch to the CVS version? > How does your patchfile refer to 'a' and 'b' paths? It's the same as with your patch: change into the source directory, and do "patch -p1 <whatever.diff", where -p1 means to strip the first directory component off all the paths. The reason my patch looks a bit funny ("a/...") is because I used git to generate it, rather than using diff by hand. > Note that the transmitting part doesn't perform well. I've done some > further testing, and there are really big 'gaps' in between the > continous stream. Hm, that's a shame -- I guess building a 38kHz oscillator onto the end of the cable would somewhat defeat the point of it being simple. ;) I haven't tried transmitting yet... Thanks, -- Adam Sampson <at...@of...> <http://offog.org/> |
From: Jon S. <jon...@gm...> - 2008-12-29 23:30:35
|
On Mon, Dec 29, 2008 at 5:42 PM, Adam Sampson <at...@of...> wrote: >> Note that the transmitting part doesn't perform well. I've done some >> further testing, and there are really big 'gaps' in between the >> continous stream. > > Hm, that's a shame -- I guess building a 38kHz oscillator onto the end > of the cable would somewhat defeat the point of it being simple. ;) > I haven't tried transmitting yet... Toggling a GPIO off/on at 38Khz over a USB link is never going to work accurately; the latencies are too high. But, a FTDI chip can send serial streams at up to 6Mb. You can use the serial stream to create 36-40Khz by sending patterns of 1/0. > > Thanks, > > -- > Adam Sampson <at...@of...> <http://offog.org/> > > ------------------------------------------------------------------------------ > -- Jon Smirl jon...@gm... |
From: Adam S. <at...@of...> - 2008-12-29 23:46:36
|
On Mon, Dec 29, 2008 at 06:30:28PM -0500, Jon Smirl wrote: > But, a FTDI chip can send serial streams at up to 6Mb. You can use the > serial stream to create 36-40Khz by sending patterns of 1/0. Yes, that's what Albert's doing: http://www.huitsing.com/irftdi/ -- Adam Sampson <at...@of...> <http://offog.org/> |