Your Universal Remote Control Center
RemoteCentral.com
Discrete Code Hunter Forum - View Post
Previous section Next section Up level
Up level
The following page was printed from RemoteCentral.com:

Login:
Pass:
 
 

Topic:
Makehex will not do long function codes.
This thread has 8 replies. Displaying all posts.
Post 1 made on Thursday September 4, 2008 at 03:25
m2mike
Long Time Member
Joined:
Posts:
August 2005
22
I am experimenting with some proprietary infrared formats and I have discovered that I can't get large function codes to work. For example, using a value of 47 in the Form doesn't work like it should.

A simple example:

Form=F:47

That doesn't work. I can explain further if necessary.
Post 2 made on Thursday September 4, 2008 at 08:42
johnsfine
IR Expert
Joined:
Posts:
September 2002
5,159
Sorry I was slow responding to your email. I just did moments ago.

Makehex uses ordinary C++ 32-bit integers for almost everything, including function numbers.

I sent the source code. I guess you could replace a bunch of variable declarations with "long long" to get support for up to 64 bit function numbers etc.
OP | Post 3 made on Thursday September 4, 2008 at 09:45
m2mike
Long Time Member
Joined:
Posts:
August 2005
22
There seems to be an undeclared variable named "floor" in IRP.cpp. Could I get away with declaring this as a global integer? I don't know what that variable was for. Could you take a look at it?
Post 4 made on Thursday September 4, 2008 at 10:46
johnsfine
IR Expert
Joined:
Posts:
September 2002
5,159
floor is a function in the standard C++ headers that I think comes in through math.h, which comes in through the precompiled headers through stdafx.h

What tools are you using?

I used the 1998 version of Microsoft Visual C++

In other projects I have observed that the headers for the above C++ put many symbols in the global namespace that newer C++ header files put in other namespaces such as std. I don't know whether that is the problem in this case. Try
using namespace std;
See if that makes floor visible.
Otherwise, you need to find out where/how floor is declared in the header files for your C++ compiler.
OP | Post 5 made on Thursday September 4, 2008 at 17:34
m2mike
Long Time Member
Joined:
Posts:
August 2005
22
I added #include "math.h" and now it successfully compiles. I will try to modify the code as needed now. Thank you.
OP | Post 6 made on Thursday September 4, 2008 at 21:55
m2mike
Long Time Member
Joined:
Posts:
August 2005
22
So I have started tinkering with the code

In IRP.h I changed the following integers to long long:

long long value0(char *&eq);
long long value1(char *&eq);
long long value2(char *&eq);

I then changed their corresponding values in IRP.cpp

For example:

int IRP::value2(char *&eq)

was changed to

long long IRP::value2(char *&eq)

I am getting different results in the hex file that is produced so that is some progress. I am out of time at the moment. I will keep working this. :)
Post 7 made on Friday September 5, 2008 at 09:14
johnsfine
IR Expert
Joined:
Posts:
September 2002
5,159
I got your next email, which suggested continuing discussion in this forum. That's fine with me, but if you want my answers in the forum you ought to ask the questions here (attached files still require email).

I don't have a lot of time to look at this, so I don't want to redo your source changes and recompile and duplicate your tests.

I haven't looked at the core code in MakeHex in a long time, but I'm pretty sure the main loop that processes the bits is at line 394, where it says
while (--val.m_bits >= 0)
If you were using msb, you can see that would introduce a bunch of extra ways that the code assumes values need no more than 32 bits (inside the reverse function and in code related to calls to reverse).
But since you're not using msb, I can't see why it would go wrong as soon as the third bit. Do you know how to use a debugger? Maybe you need to step through the code starting at line 394.
Clearly the variable Number needs to be long long for this code to work right. But with that wrong it still shouldn't fail as soon as the third bit.
Once Number is right, to process big function numbers you would need m_val to be declared long long and then depending on where the big numbers come from in your .irp file, you would need variables used in computing m_val to be long long.

BTW, you seem to be trying to generate a VERY long Pronto Hex string. MakeHex won't mind, but most programs that import Pronto Hex can't handle a very long Pronto Hex string.
OP | Post 8 made on Saturday September 6, 2008 at 03:20
m2mike
Long Time Member
Joined:
Posts:
August 2005
22
I had to change n_mask from 33 to 65 in both IRP.h and IRP.cpp. Several variables that were declared as int are now declared as long long. There was a 32 that I changed to a 64 near line 394. It seems to be working now. I will do some testing and report back.

Last edited by m2mike on September 6, 2008 03:27.
Post 9 made on Saturday September 6, 2008 at 11:26
johnsfine
IR Expert
Joined:
Posts:
September 2002
5,159
I hope that's good enough for your purposes. Full support of 64 bit fields would take a lot more changes.

That 32 you changed near line 394 interacts with some harder to change things inside the reverse method. If you had left it 32, then the MSB feature of Makehex (which I guess you're not using) would work for fields up to 32 bits. By changing that 32 but not changing reverse, you made the MSB feature entirely broken.

Sorry so much needed to be changed for full support of fields over 32 bits. I really wasn't expecting anyone to need any fields over 32 bits.


Jump to


Protected Feature Before you can reply to a message...
You must first register for a Remote Central user account - it's fast and free! Or, if you already have an account, please login now.

Please read the following: Unsolicited commercial advertisements are absolutely not permitted on this forum. Other private buy & sell messages should be posted to our Marketplace. For information on how to advertise your service or product click here. Remote Central reserves the right to remove or modify any post that is deemed inappropriate.

Hosting Services by ipHouse