I have succeeded in getting DecodeIR to run on the Arduino. The ported code can be found on Github. I plan to submit it to the Arduino library manager.
It turned out that DecodeIR is quite non-portably written. Most importantly, the assumption that int is of (at least) 32 bits of length is prevalent. The main changes necessary were to use the C99 portable types (like uint32_t etc.) instead of the, per definition, non-portable types like int and char. Somewhat simplified, most ints have been replaced by int32_t, unsigned ints by uint32_t, and chars (used as numbers) by uint8_t.
Also the dependence of std::set was taken out: replaced by an own implementation of std::set<float>. That way, the standard C++ library (which is not available on the Arduino) is not needed.
This is not really a "port to Arduino", it is a portability fix, in the sense above. There are no changes that are conflicts to the old functionality. If desired, I will be happy to upload my changes to the Sourceforge repository.
Due to the size of the library, it does not run on the "small" Arduinos (Uno, nano, etc).
DecodeIR ported to Arduino
Moderator: Moderators
-
The Robman
- Site Owner
- Posts: 21923
- Joined: Fri Aug 01, 2003 9:37 am
- Location: Chicago, IL
- Contact:
DecodeIR was written by John Fine, who no longer visits the forum. Would you have any interest in creating a more portable version of it? Better yet would be a version driven by a control .ini type file, rather than using hard code to decode each signal.
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
The more portable version is the one on Github. But it has the Visual studio stuff, the Makefiles and the JNI stuff removed or disabled. I wrote
BTW, the library has been submitted to the Arduino library maganger. This normally takes a few days.
meaning merging in the removed stuff again to Sourceforge again. Problem is, that I am not sure if Graham or Dave would be very happy... (ok, am not sure that they would be unhappy either...). Therefore "if desired".If desired, I will be happy to upload my changes to the Sourceforge repository.
See this. Has been "will be finished next month" for the last 6 months...Better yet would be a version driven by a control .ini type file
BTW, the library has been submitted to the Arduino library maganger. This normally takes a few days.
DecodeIR works with RMIR, IR.exe and IRScope (and possibly other programs I am not aware of). IR.exe is now a legacy program, and others may consider IRScope to be so as well, as I understand IRScrutinizer also works with Widgets though I have never used it. So I suppose it is not of great significance if the current version of DecodeIR is "frozen" but remains available for use with these legacy programs.
This leaves RMIR as, to my knowledge, the only program still under active development that uses DecodeIR. I don't want to stand in the way of progress but would hope that whoever creates a replacement for DecodeIR will also do the necessary editing of RMIR to interface it to this replacement. Both Barf and 3FG are capable of this and I have no objection to them doing it. As for Barf updating the DecodeIR source in SourceForge, I think that is a matter for 3FG alone. I gave up responsibility for DecodeIR a long time ago and am most unlikely to want to work on it again in future.
This leaves RMIR as, to my knowledge, the only program still under active development that uses DecodeIR. I don't want to stand in the way of progress but would hope that whoever creates a replacement for DecodeIR will also do the necessary editing of RMIR to interface it to this replacement. Both Barf and 3FG are capable of this and I have no objection to them doing it. As for Barf updating the DecodeIR source in SourceForge, I think that is a matter for 3FG alone. I gave up responsibility for DecodeIR a long time ago and am most unlikely to want to work on it again in future.
Graham
As I have written before, I don't plan to do any more work with DecodeIR, and I have no special interest in the source code. Furthermore, I'm simply not capable of dealing with C++ code if it is a non-trivial program. Since barf has made some improvements, why not upload them to SF, assuming that the JNI stuff still works after the portability changes.
I have uploaded my merged changes. So all the sources are there, consistent, should anyone feel summoned to create version 2.46
I also have added a small main routine, that makes it possible to invoke from the command line, at least on Linux and the like
I have also reformatted the code (except for the JNI functions), not because I like it better my way, but because it was very inconsistent.
I also have added a small main routine, that makes it possible to invoke from the command line, at least on Linux and the like
Code: Select all
$ decodeir 0000 006C 0022 0002 015B 00AD 0016 0016 0016 0016 0016 0041 0016 0041 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0016 0016 0016 0016 0016 0016 0041 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0041 0016 0041 0016 0016 0016 0016 0016 0041 0016 0041 0016 0041 0016 0016 0016 0016 0016 0016 0016 0041 0016 0041 0016 06A4 015B 0057 0016 0E6C
protocol=NEC1 device=12 subdevice=34 obc=56 hex0=227 hex1=-1 hex2=-1 hex3=-1 misc= error=
I just did some minor improvements to the Arduino DecodeIR, and uploaded it to GitHub as Version 2.45.3. It is already available in the Arduino library manager. Most Interesting is perhaps the InfraredDecoderLCD example, supporting an LCD display and the Infrared4Arduino IrWidget (based on code by MikeT.) This make it possible to make an independent "gadget" consisting of an Arduino Mega (slightly over 10 USD/EUR for a chinese clone) with a LCD display with I2C connection, displaying the decode of the received signal. See image:

(The picture is slightly misleading, since it shows a fairly intricate shield; all that is needed is a (demodulating or non-demodulating) receiver and the connection of the four wires to the I2C bus.)
The USB cable serves as power supply. It can also, optionally, write the decodes on the serial connection the USB establishes. No other support is necessary.

(The picture is slightly misleading, since it shows a fairly intricate shield; all that is needed is a (demodulating or non-demodulating) receiver and the connection of the four wires to the I2C bus.)
The USB cable serves as power supply. It can also, optionally, write the decodes on the serial connection the USB establishes. No other support is necessary.