manitou
Member
Here is first cut at porting Arduino IRremote library to Maple. It uses a PWM timer for IR transmits and a 50us timer to sample IR input. Timers work for Maple RET6 -- change for your version of Maple.
https://github.com/manitou48/maple-IRremote
Limited testing with Sony remote/VCR.
Here is blog on Arduino library and current Arduino library
http://www.arcfn.com/2009/08/multi-protocol-infrared-remote-library.html
https://github.com/shirriff/Arduino-IRremote
manitou
Member
This port of IRremote to maple may need further work -- the PWM timer duration for the IR transmit is controlled by delayMicroseconds() which seems to have considerable jitter. A call with 2400 results in a 2900 us delay. Such variations may or may not work with the IR equipment. I'll see if I can figure out effects of systick/USB on jitter.
My initial proof-of-concept hack of the library (single C source file) was able to decode its own transmissions in a loop. But the full library implementation seems to have transmit timings out of tolerance for the decoder portion of the library. I'm still trying to figure that out...
mbolivar
LeafLabs
I think there are bugs in the way delayMicroseconds() works. That code is old and I don't understand it well, but I believe there may be a problem in the way we convert microseconds to busy-loop iterations (using STM32_DELAY_US_MULT in the current libmaple from Git). I seem to recall gbulmer picking apart the cycle timings in a post from a long time ago, so I'll try to dig it up and see if I can't find the bug. If anyone else wants to take a look at this, though, I'd really appreciate it.
manitou
Member
Out of curiousity, would IrDA work for this purpose? Or it's not possible to use it like that?
I think not. I'm not real familiar with IrDA, but I think it is intended as a serial protocol between two IR devices -- baud rates, connections, link control ...
The IR remotes don't have that kind of smarts and are hardwired with mark/space button encodings over 38 to 40 KHz carrier.
manitou
Member
I think there are bugs in the way delayMicroseconds() works. That code is old and I don't understand it well, but I believe there may be a problem in the way we convert microseconds to busy-loop iterations (using STM32_DELAY_US_MULT in the current libmaple from Git). I seem to recall gbulmer picking apart the cycle timings in a post from a long time ago, so I'll try to dig it up and see if I can't find the bug. If anyone else wants to take a look at this, though, I'd really appreciate it.
The problem with a spin-loop for delayMicroseconds() is the jitter introduced by interrupts from systick, USB, and in this (IRremote) case the 50us-timer interrupt. For long delays (2400 us), then there are many cycles stolen from the spin-loop, and actual elapsed time will be longer than requested.
There was another blog about passing 0 to delayMicroseconds() -- IRremote lib does make 0us requests in transmits for some IR devices -- and that is a problem with the delayMicroseconds() implementation because it does a us-- initially to account for function overhead ...
You must log in to post.
