#20 support for Dangerous Prototypes USB IR Toy

[matthew ward]

there is a set of patches available that work on pre-0.9.1 source trees to successfully
build the lirc software that supports the Dangerous Prototypes USB IRToy hardware.

from the latest git version, i see that there have been structural changes in the source to move hardware configuration out of the "setup.dat" scheme and instead have a directory of "configs".

the following patches are designed to create the hardware driver for the usb_irtoy, but it's predicated on the "setup.dat" model. if the information contained in these patches could be incorporated into the main git branch - using the "configs" directory model, that would be wonderful.

patches:

https://github.com/wolfgar/meta-stef/blob/master/recipes-stef/lirc/files/0001-Add-driver-for-USB-Infrared-Toy-in-sample-mode.patch

https://github.com/wolfgar/meta-stef/blob/master/recipes-stef/lirc/files/0002-Add-USB-Infrared-Toy-driver-to-setup-system.patch

and general instruction (that don't work after version 0.9.0) somewhere in this posting:

http://dangerousprototypes.com/forum/viewtopic.php?t=2737

thank you for your consideration

[Alec Leamas]

Hm... If we merge these patches, could you help with testing?

[matthew ward]

Hm... If we merge these patches, could you help with testing?

absolutely. i have my current LIRC on several Raspberry Pi systems (Model
B and new Model B+) and i can test with Mac OS X.

[matthew ward]

protocol question for you: i see this is in the Ticket stream ... as well as here in e-mail.

should i reply in the ticket posting system? or in e-mail? or both?

[Bengt Martensson]

Hmmmm, I would be happy to see this driver integrated, provided it turns out to be good enough :-). The IrToy is an interesting piece of hardware to an attractive price.

The driver API have changed a bit since 0.9.1, see driver-api.html. So what is needed are some small changes to the c file. The patches to the other files are not really of interest.

BTW, I am "Barf" in the DangerousPrototypes forum.

Finally, please no fullquotes, in particularly not at the end!

[Alec Leamas]

[removed the full quotes ]

Probably best to answer in the bug; that gives a bit better control over what quotes you paste :)

OK, I'll see what I can do (and when...) Be prepared that it might be a bumpy road using Darwin, it's not as tested as linux.

EDIT: Note to self: winLIRC has a seemingly working driver. That might be the best starting point.

[Alec Leamas]

I have pushed a new branch named irtoy (sic!) Could you give it a try?

[Alec Leamas]

I have updated the branch with the irtoy.c file (!) + some patches. It should now be possible to run configure directly without having to use the problematic automake/autoconf tools.

[Alec Leamas]

First iteration of the driver added in master [846559]. Kudos: Matt Ward

[matthew ward]

i have run blasting and irrecord tests with the IR Toy 2, versions v22 and v23 firmwares. but i have only run tests on my Raspberry Pi model b+ (debian/raspian). if anyone wants to volunteer to test on an alternate platform, i have a spare IR Toy i could loan to them for a testing period. contact me.

[Bengt Martensson]

First of all, note https://sourceforge.net/p/lirc/tickets/44/ which shows a problem concerning lock files. This problem bites using the current driver. For the rest, I will assume that it is solved.

I did some basic successful tests, but by no means exhaustive, and found only one problem -- if initialization fails, under some circumstances lircd is trying to send, dereferences the pointer dev, whch happens to be NULL -- program goes bellyup.

With this driver, lircd (and mode2) runs happily as non-root -- assuming write access to the locking directory of course.

The usage of IRTOY_LONGSPACE is more "pragmatic" than correct; if the buffer is at 0xFFFF it means a gap that long (around 1.3 seconds) has been received. (This is a fundamental flaw in the desoing of the irtoy firmware, (at least IMHO))

Enclosed patch fixes the problem mentioned, and performs some minor cleanup.

[Bengt Martensson]

The way the dynamic device names /dev/ttyACM0, /dev/ttyACM1, ... are assigned can sometimes cause problems. (Almost makes me think about the drive letters of an operating system I dare not to mention...) So the enclosed patch make the driver first try ttyACM0, then ttyACM1, up to ttyACM9. It can tell the difference between a "good irtoy" and something else; to test I plugged in an Arduino first (became ttyACM0), then an irtoy (became ttyACM1), and the improved driver rejects the Arduino on ttyACM0 and takes the irtroy on ttyACM1.

What this shows is that is is/was possibly not a good design to give the driver the struct driver with field device being const char*

[Alec Leamas]

That pointer is just const char*, not const char* const i. e., it's perfectly OK to replace the pointer (but not to change the data it points to).

[Alec Leamas]

Thanks for review and test! diff2 merged as [d5fcc6].

All looks fine. Closing bug. Big thanks to both of you!

[bam80]

Thank you guys

[matthew ward]

Thank you guys

since this posting, the IRToy appears to me to fully integrated into the
lirc-0.9.2a source.

i just recently re-built a raspberry pi home controller system and used
the git repository to pull the latest source tree. it now builds the
IRToy "plugin" by default. it worked right out of the box by placing the
device and driver ("irtoy") in the lirc_options.conf file.

oh drat - they just released 0.9.3 ... oh well - shouldn't be all THAT bad.

Good Luck!

---

[tickets:#20] support for Dangerous Prototypes USB IR Toy

Status: closed
Milestone: 1.0
Labels: usb_irtoy Dangerous Prototypes
Created: Mon Aug 18, 2014 02:57 PM UTC by matthew ward
Last Updated: Tue Sep 09, 2014 10:23 AM UTC
Owner: nobody

there is a set of patches available that work on pre-0.9.1 source trees to
successfully
build the lirc software that supports the Dangerous Prototypes USB IRToy
hardware.

from the latest git version, i see that there have been structural changes
in the source to move hardware configuration out of the "setup.dat" scheme
and instead have a directory of "configs".

the following patches are designed to create the hardware driver for the
usb_irtoy, but it's predicated on the "setup.dat" model. if the
information contained in these patches could be incorporated into the main
git branch - using the "configs" directory model, that would be wonderful.

patches:

https://github.com/wolfgar/meta-stef/blob/master/recipes-stef/lirc/files/0001-Add-driver-for-USB-Infrared-Toy-in-sample-mode.patch

https://github.com/wolfgar/meta-stef/blob/master/recipes-stef/lirc/files/0002-Add-USB-Infrared-Toy-driver-to-setup-system.patch

and general instruction (that don't work after version 0.9.0) somewhere in
this posting:

http://dangerousprototypes.com/forum/viewtopic.php?t=2737

thank you for your consideration

---

Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/lirc/tickets/20/

To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/

[bam80]

Unfortunately, I can't use it without waking up PC support. Which as I understand IRToy doesn't have..