I really appreciate your effort of getting a mcu based ir control to run.
In particular, I like the idea of having a protocol to help a USB
( I'm a happy mac user and serial ports are almost as expensive as a usb
ir controller like the one from keyspan)
I have some experience using microchips pics controllers (16F84, 876,
877). I also tried a national semiconductor usb controller
but failed ( it was in the beginng ... ). It looks like the Philipps USB
controller is used in most devices, e.g.Visor.
I think Atmel even has some mcu with build-in USB.
I spent some time compiling lirc on mac os x. I got it compiled, but I
can't use it as none of the drivers
are suitable for me. I don't think serial port control flags as i/o pins
work over a USB-2-Serial adapter,
the same is with USB-2-Parallel adapters. ( I didn't tried any of those
I tried connecting the IR Receiver to my soundcard. So far, the data
gathered there is good enough
for evaluation and detecting the length of pulses and pauses. I just
didn't continue the decoder. I hope I will soon.
What is with the IrMan, that was on the lirc.org page. it used a simple
mcu and was free to use.
When I had a look at it, I missed the actual source code for the
Concerning the protocol. The assumption of redrat, that there are only a
distinct number of different time lengths
makes sense AFIK. So a packet format that specifies the ir burst
frequency and a nr of timelength could reduce the nr
of transmitted data significant. Then even a long command should fit
into the mcu ram. (the pic 16f84 has 68 bytes.. )
Do you know, how much pulse/pause transitions the longest ir command
Other options, you could use hardware flow control and stick to the
simple run-lenght encoding you used.
This provides a wide flexibility. hardware flow control is available on
almost any uart, works on USB ( I think
the host has to pause somehow.. :( ) or whatever. Maybe you could
reserver one code for transmission of
control data like ir frequency.
So I (morally) support the division between low-level drivers and
high-level signal processing for detection.
But I'm not going to build something in the next time.