Linux driver

Interested in integrating USB-UIRT support into an application? Look here!

Moderator: jrhees

Steps?

Postby furry_fool » Wed Nov 12, 2003 12:16 am

If possible can you post some of the steps to make USB-UIRT to run on Linux?
Thanks.
furry_fool
 

Tried but failed

Postby tbdombrosky » Wed Nov 19, 2003 3:39 pm

I tried to get it set up in Redhat with the 2.4.22 kernel. I get it recognized and it's definitely at /dev/ttyUSB0 because when I do a cat the led doesn't blink anymore. It also is recognized as the USB-UIRT in /proc. I have the FTDI driver loaded but can't seem to get any commands recognized by Lirc. I could not get the uirt2 patch to compile in Lirc. Can anyone help with this? The patch doesn't seem to have the right files in the right places (or I may be doing the wrong command)? I issued the patch -i patch.diff but it just put them in the current directory. I've never patched anything before so I may be doing something wrong. Any help would be greatly appreciated. Thanks.

Tom
tbdombrosky
 
Posts: 8
Joined: Tue May 20, 2003 8:05 pm

Postby jrhees » Wed Nov 19, 2003 4:25 pm

Boy, wish I could help, but this [linux] is all greek to me! Sorry!

-Jon
jrhees
Site Admin
 
Posts: 1652
Joined: Tue Jan 28, 2003 11:49 pm

Postby Guest » Thu Nov 20, 2003 6:26 pm

I believe the driver is just generic/raw gateway to talk to the chip inside usb-uirt but someone needs to write software which would know protocol to send/recieve signal. And the protocol depends on firmware which seems to be not finished, and author still works on it. If you are going to write/read that RAW device under Linux, I think you are risking to corrupt firmware and might not be able to fix it yourself, so be carefull.
Guest
 

Postby jrhees » Thu Nov 20, 2003 8:10 pm

The firmware *is* pretty well baked -- especially for the feature set you'd probably use for Lirc. IIRC, Lirc, basically does most of the thinking inside the host PC, so only some basic functionality would actually be used inside the USB-UIRT firmware.

I *do* make periodica changes to the firmware, but most of the time it is bug and compatibility fixes or enhancements.

The processor *is* field-flash-upgradable, but the architecture is such that you cannot really 'accidentally' mess up the part. So, the risk is low. And, even if somehow you overwrote the firmware, the design is such that a 'dead' unit can still be field-programmed by the host PC.

I wish I knew more about the Lirc project, but I'm not a Linux-head and really am out of my element with it. If someone needs help with the internal workings of the Lirc USB-UIRT driver, I can certainly help there...

-Jon
jrhees
Site Admin
 
Posts: 1652
Joined: Tue Jan 28, 2003 11:49 pm

Postby Guest » Thu Nov 20, 2003 9:43 pm

If firmware has stable protocol specs then I guess its matter of time until someone gets it to work. Some guy on LIRC list says he got it to work with UIRT2 driver and small change in source, he refered to baud rate. The LIRC must be compiled from current CVS sources.
Guest
 

Protocol update?

Postby Scott » Sun May 02, 2004 11:09 pm

http://home.earthlink.net/~jrhees/USBUI ... otocol.doc

is there an updated source for the protocol spec that reflects the recent changes? this document (above) appears to be out of date. if not, can i get access to past firmware versions? i'm using non-girder software (misterhouse) that someone wrote a driver for earlier in the year. looks like the protocol change in march broke the driver...

Scott
Scott
 

Postby jrhees » Mon May 03, 2004 1:36 pm

The firmware changes should have no effect on this -- unless I'm mistaken, Misterhouse does *not* talk directly to the USB-UIRT, but rather accesses the API driver. The protocol specification you refer to describes the low-level comm between the device itself and the API driver, and should be invisible to any app using the API interface.

-Jon
jrhees
Site Admin
 
Posts: 1652
Joined: Tue Jan 28, 2003 11:49 pm

thanks for the clarification...

Postby Scott » Mon May 03, 2004 6:41 pm

thanks for the clarification...

you are correct (at least on the windows side - i think the linux version of Misterhouse talks directly to the UIRT). has there been a change in the API with the recent fimware/protocol changes?

scott
Scott
 

Postby jrhees » Mon May 03, 2004 8:10 pm

I'm not aware of any [intentional] change in the protocol. Do you have any specifics on what broke?

-Jon
jrhees
Site Admin
 
Posts: 1652
Joined: Tue Jan 28, 2003 11:49 pm

Postby Guest » Tue Jun 29, 2004 4:24 pm

Can anyone kindly post what needs to be done in lirc? It seems ftdi_sio driver locks baud rate at 312500 and/or maps it to 38400 but changing baud rate in lircs hw_uirt2_raw does not seem to help at all.
Guest
 

Postby kRutOn » Mon Aug 09, 2004 8:49 am

Okay, I must be missing something. I've made some modifications to LIRC to support the USB-UIRT, but so far I've had limited succses in getting it to transmit. I used Girder to receive a IR code and transmit it back to a device and it works fine.

Girder uses this at 4 repeat, 56KHz, zone all:
Code: Select all
R00371781651780A41780A41780A41780A41780A41780A41780A41780A41780A41780A41780A41780A41780A41780A41780A417


I created a LIRC profile that is similar to what Girder thinks it is, and the output to the USB-UIRT is:

Code: Select all
lircd 0.7.0pre7:  36 36 2c 04 00 37 30 17  80 a7 17 80 a7 17 80 a7  17 80 a7 17 63 17 80 a7  17 80 a7 17 80 a7 17 80  a7 17 80 a7 17 80 a7 17  80 a7 17 80 a7 17 80 a7  17 80 a7 17 80 a7 17 ca
lircd 0.7.0pre7: wrote 56
lircd 0.7.0pre7: cmd res 1:
lircd 0.7.0pre7:  21


However, the device doesn't respond to the LIRC command. The only difference is that I chopped off the beginning 178165 code from LIRC because I thought it was spurious.
kRutOn
 
Posts: 4
Joined: Mon Aug 09, 2004 8:43 am
Location: Kansas, USA

Postby jrhees » Mon Aug 09, 2004 12:36 pm

kRutOn,

For the USB-UIRT to respond, you must conform to the low-level protocol specification (located earlier in this thread).

-Jon
jrhees
Site Admin
 
Posts: 1652
Joined: Tue Jan 28, 2003 11:49 pm

Postby Guest » Mon Aug 09, 2004 2:16 pm

For the USB-UIRT to respond, you must conform to the low-level protocol specification (located earlier in this thread).

Sorry, I think I spoke ambiguously. When I said the device doesn't respond, I meant the Dish Network receiver I was trying to control with the infrared code. The USB-UIRT responds with CMDOK (0x21) and the red light comes on momentarily while it transmits.

I can receive commands fine as well. So I was hoping there was something fundamentally flawed with how I translate the R0037... string to an actual command.
Guest
 

Postby jrhees » Mon Aug 09, 2004 11:09 pm

Well,

two comments -- 1) You *dont* want to remove the 178165 header. This is *not* spurious but is the typical IR preamble most IR devices use to set their AGC.

2) What repeat value are you using? Make sure its four or so for starters.

If you email me at support@usbuirt.com, we can work on this a bit more if needed. I can feed commands through the API driver and give you the binary back of what is being sent to the device if needed.

-Jon
jrhees
Site Admin
 
Posts: 1652
Joined: Tue Jan 28, 2003 11:49 pm

PreviousNext

Return to Developers

Who is online

Users browsing this forum: No registered users and 6 guests