From: Karl B. <ka...@tu...> - 2002-05-22 16:06:33
|
Hi IR fans, Heres some more of my notes. Hopefully it explains what I am trying to do with micros better. The neat thing about microprocessor based is that it has the capability to do a lot of things. It is flexible. Most users they would not want to mess with programming AVR's, but you don't need an external programmer and it costs virtually nothing to make it programmable from the serial port. AVR's need 3 control signals to program it, all available from the PC(DTR,RTS,CTS). I just think it would be a wonderful toy for the hardware/software hobbiest. You might as well bring these control lines over to the PC anyway. That's how I program AVR's is just hooking them right up to printer port lines(5 wires). Other people have done it on RS232 lines. There are existing IR-control micro designs that draw power from the serial port. This limits the things you can do with it same as the home-brew. USB has power, and this micro-implementation would make a full implementation of LIRC over USB possible. When I say full implementation, I mean it can "learn"(return the raw signal). This is in comparison to the pre-processed codes available from most commercial smart hardware. And it will be cheap. If we can get the protocol down to a small frame, then a $2.00 microprocessor can be used. The micro-implentation tries to formalize a compact protocol suitable for routing over simple communication pipes. Once it is implemented on a serial port it could be easily transferred to USB, Ethernet, Firewire, I2C, whatever. I want hardware that gives the "real" raw signals. I can go buy a smart Logitech unit with remote-control on Ebay for $10-$15. But, it gives me only pre-processed codes for that remote. That may be fine for a lot of people, but I really value the ability to record actual signals. Kernel driver not required. - This allows for a portable design. Without messy kernel stuff, it could be compiled on BSD/Solaris/Windows as easy as Linux. LIRC has this split personality. Half of it is kernel driver based, the other half is user-mode applications. Personally, I think it might be best to split the two up so that the average user does not have to know how to compile their kernel or the user mode stuff could be used on other platforms. If we every want the drivers to be accepted into the Linux kernel base then it should be arranged this way. The kernel base does not include all the user-mode stuff, but it does include drivers. Karl. |