April maker challenge 11- IRduino
I like the Arduino as a simple computing platform, but I've mentioned here before that I'd like to offload some of the more basic functions to a co-processor to let the Arduino have more CPU cycles for other stuff.
That's true for many, MANY tasks, and one of the ones I've been fascinated with since college is the capturing and parsing of data from an infrared remote control. Adding IR to your project is a SUPERB way to add very complex I/O.
I'm not sure if the Arduino has a library to read IR from remote controls, nor do I care, because it's likely to suck up an unacceptable number of CPU cycles. Thus, the IRduino: a shield with a small microprocessor (I'll probably use a PIC, since I know how to work those much better than AVRs) which decodes the signals from infrared remotes, packs it into three or four bytes (there are actually a LOT of possible codes out there, due to the number of encoding schemes). There would then be several options for sending this to the Arduino- a semaphore based scheme, a "dump-on-receipt" option, a "hold-until-request" option. Others, perhaps.
That's true for many, MANY tasks, and one of the ones I've been fascinated with since college is the capturing and parsing of data from an infrared remote control. Adding IR to your project is a SUPERB way to add very complex I/O.
I'm not sure if the Arduino has a library to read IR from remote controls, nor do I care, because it's likely to suck up an unacceptable number of CPU cycles. Thus, the IRduino: a shield with a small microprocessor (I'll probably use a PIC, since I know how to work those much better than AVRs) which decodes the signals from infrared remotes, packs it into three or four bytes (there are actually a LOT of possible codes out there, due to the number of encoding schemes). There would then be several options for sending this to the Arduino- a semaphore based scheme, a "dump-on-receipt" option, a "hold-until-request" option. Others, perhaps.
Comments
Post a Comment